Collaboration happened under wyng-backups so that sparse and sparse-write operations on restoration are now optimized enough to be used efficiently over network mode, where compression over SSH helps hidden onion latency and where restoration of states over cloned Qubes permits only delta to efficiently consume bandwidth at the cost of more local CPU calculations, resulting in only diff consuming precious and sometimes costly mobile data to reset into trusted states when needed.

Wyng-backup now works for backup/restoration of disk states over a Qube, over a Qube+SSH or directly from SSH (inapplicable for QubesOS use case, but could be for Heads!). A reminder that wyng-backups efficiently deduplicates remote storage needs. This means that wyng-backups computes locally shared data blocks among Qubes, meaning that clones of templates, or shared block level duplicated blocks are not consuming duplicated compressed storage in the backups themselves. This practically means that only the differences across templates, Qubes and clones are consuming backup space on the backup storage space. A practical example of this for all is Whonix templates for Workstation/Gateway: those two templates duplicate most of consumed space on the installer media and on installed system. But on backup storage, only a third of that template is different; therefore the backup footprint is only shared data block + delta. Cloning and specializing templates only consumes the delta of installed packages and nothing else.

For organizations: these clean states as firmware service could mean that abroad/endangered users (think journalists) could cross borders without any state on their disk/no disk at all: no data to protect!

Those could buy NVMe/SSD devices abroad if needed (otherwise boot directly from Tails?) and boot into a provisioning environment from their tethered smartphone WIFI/data connection and pull trusted persistent disk states from the network in a matter of minutes, and then boot directly into a clean, trusted system whenever needed. And reset to a clean state prior to doing any work session, limiting persistence of untrusted disk states to the bare minimal or to none at all, depending on the organization's needed policy.

If existing states pre-exist, thanks to QubesOS, only relevant delta could be pulled from network and be applied directly to disk, reducing provisioning of trusted disk states to a matter of minutes at most and guaranteeing that endangered users can rely on the trustworthiness of the whole boot chain up to the OS state and do what matters to them. Plug and play would mean something completely new. This would be ideal for SecureDrop Workstation, organization image management and maintenance, centralizing image security and trust of used disk states, even for QubesOS if they decide to offer such service to deploy safe states effortlessly from the firmware, as a subscription service.

Now. How do we collaborate together to make that dream come true?

SecureDrop Workstation just left their beta stage on July 15th 2024. What if we collaborated on making QubesOS SecureDrop Workstation deployable reproducibly for all journalists, with secure disk states pulled directly from the Freedom of the Press Foundation infrastructure? What if QubesOS hosted wyng ready to restore states, directly from mirrored SSH servers from partners so that secure restorable states could be offered as a firmware service for all? This could become a reality.

But... What do we need to go there? What do we miss to get there?