Joanna Rutkowska

The same can be said about a "trusted" OS like say Qubes OS, with untrusted hardware, like Intel's. Actually, that's what the developers of Qubes OS and other "free" operating systems have said as well.

http://blog.invisiblethings.org/2015/10/27/x86_harmful.html

https://www.fsf.org/blogs/licensing/intel-me-and-why-we-should-get-rid-of-me

If anything, I'm more frustrated with the Signal team that the app doesn't have as good call quality/performance as WhatsApp, nor does it have video call support, and that the Chrome desktop "app" doesn't seem to import my phone contacts for some reason - all of which is making me continue to mostly use less secure and less trusted alternatives.

My point is we should aim for getting things "more secure" constantly, and I think we have in the past few years. So rather than just say "what's the point?", we should say "let's put more pressure on X company to open source/prove their system is secure" and hope that in time enough pressure is built that those companies actually agree to do those things.

And since I was talking about putting pressure on companies, let me start:

Where the hell is Google's End-to-End tool? It hasn't had any commits in over half an year, and we already know NSA's bestie, Yahoo, has given up on it. Should we start drawing some conclusions about the Google/NSA relationship, too? Did Google abandon the project?

https://github.com/google/end-to-end

There - who's next?

Qubes is not just an abstraction. Its isolation allows to overcome the problem of fundamentally insecure software. For example, my passwords are stored in an offline VM (where I don't run any apps) and my random internet browsing occurs in a disposable VM (which is reset every time).

Yes, Qubes does not solve the problems like Spectre and Meltdown. Yes, you must trust your hardware to use it. If you are looking to solve such problem, then you might be interested in a stateless laptop: https://blog.invisiblethings.org/papers/2015/state_harmful.pdf.

Apart from that, I believe, the best computing paradigm is free software and free hardware, but it does not seem too widespread now unfortunately. This would be the actual solution. The "behemoth companies" are not trying to solve computer security. They are trying to get as much profit as possible, and it goes against security of the users. This is why they are not supporting free software.

My current "good enough" solutions are disabled and neutralized ME in a laptop and Librem 5 phone.

The problem with laptops is that UEFI is a shadow operating system that keeps running after boot, with a bunch of security vulnerabilities. Furthermore all Intel / AMD chips have a microprocessor state called SMF which if you trigger it basically gives you carte blanche to do whatever you want.

"Trusted Boot" is a meme on x86. If you really want something like that you need to do what Oxide Computer is doing and rip out UEFI for good and implement your own secure boot chain.

Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of.

So I understand why the GrapheneOS folks do what they do.

See also: "X86 considered harmful" by the founder of Qubes OS (posted in 2015!)

https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

> - ME can't actually be disabled completely according to Qubes OS founder Joanna.

In case you're referring to her article titled "Intel x86 considered harmful"[1] it's worth noting that she only speculated the following:

> A large part of the ME firmware is stored on an SPI flash chip, which admittedly could be reprogrammed using a standard EEPROM programming device to wipe all the ME partition from the flash. But this approach does not have a good chance of succeeding. This is because the processor itself contains an internal boot ROM [37] which is tasked with loading and verifying the rest of the ME code. In case the bootloader is not able to find or verify the signature on the ME firmware, the platform will shutdown.

However, if I understand correctly, that's exactly what Youness Alaoui[1] at Purism did.

[1] https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
[2] https://puri.sm/posts/deep-dive-into-intel-me-disablement/

In this case the same submitter posted two versions of the story:

http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

http://blog.invisiblethings.org/2015/10/27/x86_harmful.html

Not a great approach; one ought just to pick the better of the two, which in this case is the html, because it gives more background, loads faster, and links to the pdf.

General remark: I doubt that we'll make the dupe detector sophisticated enough to catch a case like this, but I do think we'll add software support for users to identify dupes when they see them. That's what happens informally already (as you all did in this thread, and by flagging the other post) so the shortest path to better deduplication for HN seems to be: write software to make community contribution easy. Also I kind of like the idea of giving a karma point to the first user who correctly links a given pair of posts.

It's a shame that ME can't be removed or disabled on modern Intel CPU's. Same goes for AMD and maybe companies that implement something like ME in ARM. OpenSPARC is quite dead, sadly enough.

Highly recommended read about x86 security: http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

The author of this paper is also the developer of Qubes OS. They recently added another requirement to laptops who are 'Qubes certified': they must run Coreboot. It's not Libreboot yet, but that is a huge leap forward for x86 security. Hopefully this will trigger vendors to make their hardware Coreboot compatibile. It won't do anything about Intel ME, but it is a step in the right direction.

I ordered a Thinkpad x200 to flash it with Libreboot last week, just to have at least one device without any malware (in RMS sense)