4 ms·
I fully agree one should own their own keys. I suppose in the case of my phone I feel I can't let perfect be the enemy of good.
by steelframe 2y ago
I fully agree one should own their own keys. I suppose in the case of my phone I feel I can't let perfect be the enemy of good.
- strcat 2y agoSee https://news.ycombinator.com/item?id=42536302 https://news.ycombinator.com/item?id=42536302 for an official response to the claims in that repository. Many of the features listed there are officially planned features, although not necessarily in the way they imagine them. We want to give users a choice about things like secure activities blocking potentially accidental screenshots and apps detecting screenshots so those will have toggles. GrapheneOS is heavily focused on privacy and security. That means we're not going to add massive attack surface or poke huge holes in the security model for very niche things that are not going to benefit the vast majority of users. We provide official support for userdebug builds with ADB root access for people building the OS. Official support includes helping people with their builds in our development room, with the hope that people end up contributing back. People making userdebug builds for production usage should enable ro.adb.secure=1 unlike a regular development build. They should be aware of the security downsides and it's their responsibility to secure the computer(s) they're using for builds, signing and ADB access. ADB access can also be used on the device itself via network ADB which is non-persistent for security reasons. GrapheneOS is an open source project. Modifying the official binary releases is not the intended way of making changes to GrapheneOS. People are intended to modify the sources and build it themselves. The whole process is only a few commands and can be trivially scripted if people only want production builds signed with their keys. GrapheneOS even has fully reproducible builds for the OS and we have a community member that's reproducing each OS release successfully. There's only one known issue specific to 8th gen Pixels which has been worked around by them doing the 8th gen Pixel Linux kernel build from a specific path. It should be resolved already by Android 15 QPR2 that's currently in Beta due to it moving to the 6.1 kernel used for 9th gen Pixels for 6th/7th/8th gen Pixels too.