@weyoun.six: Thank you for that! My counter-recommendation here would be to push for better Heads documentation, as a community, so that users can take their own power back and replicate the setup for themselves.
Doing one laptop at a time, I fear, didn’t serve this goal as much as I wanted this to become, and all the supply chain complications (even more since Covid) made me reconsider my own desire to be a hardware+support provider, which I think is more beneficial here (through forum and main documentation improvements) than on a 1:1 basis, for the whole community.
On my side, I slowed production dramatically in the past months, to the point where I am now taking a pause from selling altogether. Doing one laptop at a time is not helping the whole community as I wish it had.
Doing research and development, as you might know, requires concentration, time and energies which I find more productive for the whole community, and doing both at the same time requires additional management toll (supply chain, import, reprogramming, OEM disk image maintainership, flashing, tamper seals, pictures, customer secure communication handling, secret sharing, shipping, support for re-ownership and then one on one support request handling) which is counterproductive for research and development goals.
So my present goal is to go back more into research and development, where doing laptops was initially aimed to funding my research and development efforts. I found that the two are not compatible and that my interest is more into research and development than into providing hardware and direct 1:1 support for users instead of organizations.
The whole goal of Heads and its OEM Factory Reset/Re-Ownership wizard is to provide anti-interdiction mechanisms and in-transit tamper evidence. As a side effect of this, this enables companies like Insurgo/Nitrokey/Purism/Hardenedvault to provide such services as well.
But if a user flashes and installs Qubes OS himself, then there is no need for shipping anti-interdiction mechanisms: the user controls the whole process, where heads offers the same tamper-evidence mechanisms when roaming around; when the device is left unattended, when combined with Glitter - Trammell Hudson's Projects and Blink Comparison | F-Droid - Free and Open Source Android App Repository ideas.
The next goal is to make this easier for all, not just customers. And I hope the actual Heads community and enthusiasts will merge efforts into facilitating accessibility for others, and that is through documentation improvements, on which I will of course participate, just like I do right now, but answering to direct needs instead of reacting to unfulfilled needs.
This is an old dream of mine. I started this in the goal of facilitating decentralized and accessible, reasonably secure hardware. I also made a presentation exactly about that at FOSDEM 2 years ago FOSDEM 2020 - Heads OEM device ownership/reownership : A tamper evident approach to remote integrity attestation. The ideal would be for the hardware to be locally reprogrammed, with shipping being out of the question. Just like people are flashing coreboot as a service around the globe, the ideal would be for local repair shop to offer that as a service. With Heads maximized builds, a user could flash internally a firmware image prior of installing Qubes, making sure that the firmware is trustable, without even having to trust the repair shop which simply “unlocked” the machine to be user-owned.
I personally encourage this kind of offered service @weyoun.six. Buying hardware second hand should be the way to go, with Heads being flashed as a service being the real benefit here. After that, my recommendation as of today is to push for better defaults inside of Qubes OS. Better and easier software installation methods to make Qubes more accessible as well.
But pre-installing Qubes OS like I do, maintaining the OEM disk image and customizations (with/without Windows, with/without signal. Replicate with all softwares possible. People complain when something is there that they didn’t want preinstalled; when it’s not there but would have wanted it…) comes with a lot of liabilities and complications I am not really interested in dealing with anymore. The solution there is to ease those things to the point people are not scared of doing it themselves, following simple documentation, updated upstream. And I prefer orienting my energies into resolving those issues upstream then having to deal with them on a 1:1 basis, with users believing I have to resolve those issues for them/with them.
As of today, I still believe the best is for the user to install Qubes OS himself and understand the process. Otherwise, when comes the time to reinstall (Qubes 4.1 required that), the end user is still scared by the process. And to flash Heads updates (which Qubes 4.1 also required).
The ideal is to have users aware of the backup/restore/update/upgrades processes and be able to do so between Qubes OS releases and templates becoming EOL, otherwise I am not sure of the real benefit of the process other than to be able to ship a laptop internationally, with anti-interdiction mechanisms in place. But there is no need for anti-interdiction if the user can do that himself, or if there are firmware flashing as a service.
I am also convinced that organizations would benefit into flashing those devices themselves for their users, and that would be beneficial to both Qubes OS project and oganization’s users, where the organization is better placed to take a stance on the liabilities involved into choosing to deploy certain software packages and repositories, while also maintaining their own OEM disk images for their users. That was always my goal, and I would definitely would love to participate into those movements more directly, be engaged as a consultant for such organizations.
But I currently doubt that doing one laptop at a time is serving completely its intended purpose and my own. And I hope this reply clarifies my position on the matter.
Well, that was from HOPE conference, which explains the “hackyness” of the picture.
Opening an issue for all the images to be changed would be an important step forward. Better would be to replace those images in a GitHub Pull Request!
Think HOPE image good for threat model section.
What wrong with all the images?
Solomon1732 say don’t desire to learn how to flash BIOS. Try to be helpful and recommend certified laptops.
Major benefit and huge credit to you. Thank you!
Not really complicated. Qubes currently certifies a single other company that sells the same hardware family of Heads supported laptops x230/t430. This is the easy thing to find on Qubes website directly Certified hardware | Qubes OS
Other sellers will come sooner than later. More performant, more recent, but fuller of Intel FSP/ME AMD AGESA/PSP blobs to widen hardware offer on x86, which is the only possible Qubes OS supported architecture for the moment
Sorry for the sarcasm notes. I really wish the x86 blobs situation changed, but it hasn’t for newer hardware. So the users will need to choose for themselves on what they trust, what blobs they decide to rely on in exchange for newer and more performant hardware, which is the subject of so many other threads on this forum alone.
I don’t mind reading documentation at all. Neither do I mind installing Qubes or any other OS. Flashing BIOS scares me since I can brick my computer – I don’t have money to spare in such a case. I also don’t always notice where I lay my hands or other house utensiles. Therefore I can easily knock something off and screw something. Theoretically, if I could buy flashing as a local service I would – at least the first time
Forgot to mention: I do read various documentations from time to time. And I succeeded installing Qubes and a few Linux distros. Hardware? It’s a whole new world.
Nothing wrong with other images, but console access can scare a lot of users, where console access is not needed since a really long while under Heads unless recovery actions are needed. This is more representative of current Heads UX:
This is not Heads related thread though. A lot of other threads exist on the subject. I just wanted to post in that thread that Heads, on non-bootguard locked hardware, is totally possible, where “states” can be measured, where stateless from Johanna’s paper relates more to externalizing the states, which as far as I am aware, had no progress for the moment and where Heads and coreboot’s measured boot (which is what Heads depends and extends) is an interesting alternative to UEFI for coreboot supported platforms. I wish to see more of those, with clearer statements on which blobs are required to initialize and keep functional the platforms in question.
Just posted there to reference here:
So much there. How to inform interested users of real choices? You more than doing your part, asking for a friend
This require much education. Your posts help.
Returning to stateless laptop progress topic, does @pietrushnic saying
still depend on
Presume yes but happy to be confused.
Some needed clarifications:
All are deploying Heads or Heads derivatives/forks of Heads.
Pureboot, Vaultboot add some features, such as all forks normally do in the open source world. Forks are a normal outcome (while not always desired) in open source project, being normally the result of needed differences to accomplish different, or specialized, goals.
One embracing the mission of comparing codebases will see differences in “boot policies”, mostly. From the differences in codebase, outside of Heads core changes that have not yet been picked up in the forks today, the interested would see changes that apply to servers more specifically, or to PureOS.
Autoboot from Vaultboot, Restricted mode from Purism. Vaultboot implemented TPM2 support and chipset locking on their supported plarforms. Pureboot implemented root filesystem tamper detection for PureOS. Vaultboot created automatic release of TPM disk encryption key for their server. Vaultboot also deploys authentication to access recovery shell.
Some of those changes were suggested in pull requests, but the user base and use cases being so different didn’t permit generalization and inclusion under Heads codebase directly, Heads not being directly linked to consistent support channels in case of “I lost my USB dongle and now I cannot boot the machine nor go into recovery shell and my machine collects dust, I cannot externally flash my device nor buy a new USB Security dongle…” kinda problems…
Ideally, commonly used code should be merged upstream when goals of projects matches, since this also reduce forks rebasing efforts and also facilitate collaboration upstream. While lowering codebase maintainership costs across forks.
This is true and is HOTP variants of the boards when available. See https://osresearch.net and search for HOTP. Note that you can download firmware images directly and that the process is also documented.
Purism’s contributions to Heads are massive, including an early partnership to have HOTP supported into Heads with their Librem Key (being a fork of the Nitrokey Pro open hardware design), and their efforts to bring whiptail and fbwhiptail (a beautiful graphic alternative (gui-init) that has now replaced original generic-init from early Heads days (that was console based and some documentation artifacts still letting users think that Heads is for experienced users only)).
That’s it for my facts correction on all posts above related to Heads.
To go back on topic: advancements on stateless laptop.
The starting point of this discussion should point to the origin of the idea
- blog post State considered harmful - A proposal for a stateless laptop (new paper) | The Invisible Things
- paper https://blog.invisiblethings.org/papers/2015/state_harmful.pdf
- conference Schedule 32. Chaos Communication Congress
- minimize firmware
- centralize firmware (Everything in one flash image)
- externalize flash to be read from external media
- do we agree that states should be externalized?
- would we not prefer to have all its firmware parts internally measured and attested?
- we want an unbootable (brick) platform without externalized firmware available?
I’ll state here the obvious, even though it is tangential. I simply feel it is worth mentioning.
State always exists and has to. Hardware is not a static mathematical starting point and function. Rather it itself is a state; the external world—a stateful world—affects the hardware. Therefore the question becomes “where do we desire state to be?” and “how do we handle it?” I know not the answers for myself, much less for others, and moreso for projects.