Notices by GrapheneOS (grapheneos@grapheneos.social), page 2

@SecurityWriter @neurovagrant @mttaggart @tris @Viss Google has a similar rewards program for Pixels:

https://bughunters.google.com/about/rules/android-friends/6171833274204160/android-and-google-devices-security-reward-program-rules

Both Apple and Google pay substantially less than people get selling their exploits to exploit vendors. Cellebrite, NSO, etc. appear to largely do vulnerability discovery and exploit development themselves anyway. It was apparent from many of the Linux kernel USB driver vulnerabilities they were caught using that they likely extended with better USB support. syzkaller

@SecurityWriter @neurovagrant @mttaggart @tris @Viss

> Majority of law enforcement ‘successes’ are against outdated, poorly secured devices with owners with terrible OpSec.

Cellebrite Premium can usually exploit current iOS and Android versions on the vast majority of devices. If the device is in the After First Unlock state, it can usually get the data. Pixel 6 and later / iPhone 12 and later will usually prevent getting data if it's in Before First Unlock state.

@dalias @lispi314 @maumau @fluffery @kkarhan @BryanGreyson A smartphone where none of the firmware or OS can be updated at all complies with those incredibly arbitrary FSF rules. They do actually say that themselves by specifically saying having entirely proprietary devices which do not have software that can be replaced/updated is fine. They seem to not consider the fact that phones, laptops and desktops could in fact be made that way. It's hard to see how that would be more freedom for users.

@dalias @lispi314 @maumau @fluffery @kkarhan @BryanGreyson That's what Pixels do for the OS but the line has to be drawn somewhere about where to implement it. It could be implemented earlier in the boot chain and it could be possible to replace some of the secure element code, but there has to be something which implements this in a secure way which cannot be feasibly worked around with tampering. There are other examples of products implementing a similar approach at different points.

@dalias @lispi314 @maumau @fluffery @kkarhan @BryanGreyson It's 100% possible to implement this in a way that the components implementing it cannot be updated, but why is that better than having the same code implementing it with the option to do signed updates? We simply don't buy into the idea that not being able to update a component is better.

The exact same design but with the early boot chain and secure element code being impossible to update at all complies with FSF rules...

@dalias @lispi314 @maumau @fluffery @kkarhan @BryanGreyson Requiring destroying the keys to modify it where you can't realistically work around it with hardware tampering is describing secure element features which exist but require having a secure element. It's entirely possible to do that where updates of the early firmware and secure element firmware are blocked but then vulnerabilities can't be fixed via updates and it can't be improved. If you allow updates, that's already how it works.

@dalias @lispi314 @maumau @fluffery @kkarhan @BryanGreyson We don't think disallowing updates of firmware makes it into hardware. If it could have been possible to update it, it should have been possible. We don't agree with the premise that hard-wiring things by blocking updates is somehow increasing openness or freedom. We would much rather have the option to ship updates to firmware than not having it.

YubiKeys are an example of a secure element product with no updates. It does not go well.

@dalias @lispi314 @maumau @fluffery @kkarhan @BryanGreyson Defending against data extraction with physical access is one of the main things people expect us to protect against.

Also can't have features like throttling unlock attempts beyond a key derivation work factor if it's not permitted to have a secure element with verified boot. Physical attack vector is a huge part of what a secure element is meant to help protect against. Most users won't set strong passphrases and can't be expected to.

@fluffery @maumau @kkarhan @BryanGreyson @fairphone Our hardware security requirements are very reasonable, industry standard requirements. Pixels and iPhones are much more secure than other smartphones, but particularly devices like Fairphones. Our requirements do not lock us into Pixels and it's not particularly hard for major OEMs to clean up their act by providing the security patches on time for 5 years and the standard ARM / Android security features which are listed as requirements.

@fluffery @maumau @kkarhan @BryanGreyson @fairphone Fairphones are closed source hardware with closed source firmware. They're not more open source than Pixels. There are no open source ARM or x86_64 devices. Free Software Foundation is focused on free software (open source software), not hardware and firmware. They do not consider it a problem to have closed source hardware and firmware as long as the OS doesn't have to load firmware. They consider it best if that firmware can't be updated...

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson Preventing shipping firmware security patches provides assurance of insecurity. Pretending it does not exist and ignoring the need to apply microcode/firmware security patches does not mean it stopped existing. Blocking updating it doesn't make it stop existing. It's still there, is still closed source firmware and has publicly known vulnerabilities unable to be patched. This is not solving real problems but rather creating bigger problems.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson It is still closed source firmware if it can't be updated, and closed source hardware doesn't actually matter any less than closed source firmware. It's very arbitrary to claim that not being able to update it due to blocking the update mechanism makes it hardware rather than firmware. It's often possible to undo how it was blocked and still update it anyway. Librem 5 has certain components unable to be updated via OS but they can be flashed.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson Shipping closed source hardware and closed source firmware with updates blocked takes away a user choice and provides assurance of insecurity. That's not progress and is the opposite of it. Choosing much less secure components with baked in firmware and state which are far less transparent is not progress towards openness either, but yet that is what Purism does with their devices and what the FSF guidelines encourage. It's the wrong direction.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson If you take a look at the Pixel firmware, you'll find it's not obfuscated and that you can read the code when disassembled. How would it be better to have the code baked into components and inaccessible to users? Open source would be better but having access to unobfuscated closed source code is useful and better than nothing. Requiring the OS to load the code at boot for hardware to function is good for multiple reasons including security.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson It's not possible to externally improve most of it on a whether or not it's open due to verified boot and signature checks. On a reasonably secure device, the only way you can do that is if there are device variants sold where efuses are not yet burned and you can burn your own signing keys into them or use it in development mode without those security checks, which wouldn't be something we would do on a production device.

@lispi314 @maumau @fluffery @kkarhan @BryanGreyson That requires selling variants of devices with efuses not burned which users can choose to deal with as they want. Selling regular devices to non-technical people that way would be problematic since it implies not having verified boot and other related security features. Also, it's a huge responsibility to have control over those fuses. Do you want to be locked in to using someone's 3rd party builds? Managing keys/builds is beyond most people.

Many companies and individuals are trying to mislead people about the future of GrapheneOS to promote their insecure products and services. GrapheneOS is not going anywhere. We've made it clear we're shipping Android 16 soon and that the supported devices will remain supported.

@lxo @SuperDicq @toatrika @Starkimarm @tris linux-libre removes warnings about outdated microcode. The warnings exist due to known security patches. Nothing about that is misinformation. Many of the security vulnerabilities are public knowledge and that includes ways to exploit them, so it's possible to test for whether they are patched or not separately from microcode versions. Not shipping microcode/firmware updates means not patching vulnerabilities. Removing warnings about it is hiding that.

@jeffcliff @SuperDicq @lxo Open source software is in fact a black box to most people. Even for software developers, they're still trusting the people making it. You're conflating different things together.

The idea that preventing people updating firmware or even preventing replacing it with different firmware is somehow more free is nonsensical. Taking away a capability from users to use as they wish is not giving them freedom. Taking it away doesn't make it freedom respecting or open.

@jeffcliff @Starkimarm @tris @SuperDicq @toatrika @lxo If you want us to respect your views on it, start being consistent by not drawing an arbitrary line where blocking updating firmware/software makes it not count. If you stop doing that the focus could be on making actually open and freedom respecting hardware instead of playing games pretending hardware/firmware isn't proprietary if it can't be updated or that it's not relevant in the same ways. As is it's just unserious and downright silly.