252 karma · joined April 28, 2021
It doesn't have anything directly to do with GrapheneOS, and would have enabled custom OS support of any Android distribution.
GrapheneOS also heavily promote the use of open source Android apps. What they refuse is having app stores that reuse app package names, centralise the signing of app packages, perform reproducible builds on outdated infrastructure, significantly delay app updates et cetera.
I cannot deny your opinion, but just want to suggest that from my understanding GrapheneOS are not against microG and F-Droid as concepts, just against their current implementations.
https://github.com/flawedworld for example as part of GrapheneOS organisation and has interviewed for GrapheneOS in the past (https://www.youtube.com/watch?v=WkQ_OCzuLNg).
>preventing basically nation state attackers who either compromise or compel a CA
I don't think the compromising, self-compromise or compelling of a Certificate Authority is a feat reserved for state-level attackers. I am not sure why it would exclude any malware that gains enough privileges, or existing campus-enterprise mobility management apps/parental control/antivirus that get compromised or hijacked. But really it comes back to one of the original points which was that GrapheneOS are comfortable recommending and promoting solutions with a high level of security/privacy as a general rule.
>The second ticket
Yeah, I believe I confused the 'frosting metadata' part with the important whole APK Signing Block. The part I wanted which the app store client should verify would be the signing certificate hash which you compare to what the server says the package should give you. As far as TOFU mainstream users basically trust in Google's Play Security & reviews process instead of developer signing certificates/keys because most developers do not publish that out-of-band somewhere they individually control. Widget on Dev's Socials/Site + Publishing hurdles + Developer Console auth + Google security/review add up to a non-zero chance the listing is good. When you get the app you have the benefit of certificate pinning and app signature verification to make sure that non-zero isn't majorly reduced in distribution/transit.
GrapheneOS don't even recommend getting apps from Play anyway if you can verify and source the apps directly from the developer.
>very common among GrapheneOS users btw
Can't say anything for your experiences, but of course I only speak for myself. I can say though that the GrapheneOS developers themselves will never tell you the OS is specifically for high-risk oppressed journalists and whistle-blowers. Another big disconnect is that GrapheneOS believe things need to be much more attack/abuse-resistant for the 99% than they are now, so asking them to aim a little lower than current standards will cause a lot of misunderstandings: https://xcancel.com/GrapheneOS/status/2044440381803069778#m
>You still have to be wary of what you download, deny it internet access if applicable, etc. Aurora at least lets you filter on apps that don't have GMS listed as a dependency, and works with Exodus to show other trackers, making this process a lot easier than via Google Play
I agree mostly with this, but I think you can see it would be a bit painful and tedious for GrapheneOS to say "We can't endorse violating Google's TOS but Aurora Store is an option under specific circumstances and technical conditions. Apps from Play/Aurora may not contain any Google libraries, GMS dependencies or involve sending data to Google as potentially stated in their privacy policy but there is no accessible way to determine this per-app at a glance." every time they need to talk about Aurora Store.
>Do you happen to have a link for that, or remember where they wrote that?
Recent examples: https://xcancel.com/GrapheneOS/status/2093353794247467344#m https://news.ycombinator.com/item?id=49548219
GrapheneOS will never be closed source/proprietary because they believe code freedom (and user freedom by extension) is paramount. They have repeatedly said they don't have the resources to build a ChromeOS-esque firmware authentication and warning flow for ephemeral user-accessible root and support those builds alongside the existing production environment. They have NOT said it is something they have no interest in even discussing. They have also repeatedly said that where the utility is clearly demonstrated and can be architected in a maintainable way, they are open to contributions (and continued maintenance) that properly enable functions that people unnecessarily need to abuse root privileges for.
The main goal of their project is a system that can protect your personal thoughts, associations and memories to the best of its ability (against thieves, attackers, surveillance etc.) while preserving your interaction with the world. Current OSes (including GrapheneOS and iOS) are already far behind where they should be given the wealth of privacy enhancing technology, computer hardware security, systems engineering and OS design knowledge that has existed for decades- so their work is cut out for them and they are putting everything they have into leading the industry. Their hands are already full. For clear use cases the path of least resistance would be to contribute and commit to maintaining features everyone would benefit from.
If it is a feature/function someone understands they would benefit from personally but do not see the value to impose on others, we can circle back to the original fact which is that GrapheneOS is open source and can be bent/built to your will.
It's more accurate to say they suggest improvements not vehemently oppose. The community/project have opened issues with the Aurora Store project to get them closer to that goal of making sure the app downloads cannot be intercepted https://gitlab.com/AuroraOSS/AuroraStore/-/work_items/697 and mitigating the TOFU problem by ensuring the first install is definitely the one the developer distributed via Play https://gitlab.com/AuroraOSS/AuroraStore/-/work_items/1177 This is what I meant by standards. They only suggest Play Store because it is an existing solution that already meets those standards.
>Again mixing up threat models and equating it to privacy. My threat model, and many other people's, includes Google tracking me.
GrapheneOS are very conscious of avoiding sending data to Google where unnecessary. The evidence of that is in the link previously shared, but also in third-party reviews like https://www.kuketz-blog.de/grapheneos-der-goldstandard-unter... They also do advise that if you want to avoid Google's gaze you should explore non-Play Store apps if they can meet all your needs because Play Store apps are extremely likely to include Google libraries and dependencies that expose even more data to Google. Apps on your phone may be able to determine your locality, and can definitely fingerprint you uniquely, so it is not enough to download an app via Aurora Store. I believe that from their perspective it takes a lot of careful consideration and planning to avoid exposing data to Google. This consideration and planning would never end with just Aurora Store so hopefully you can understand why they would not recommend it as a well thread-modelled privacy solution for Google. Instead they do suggest Aurora Store as a last resort in special cases where the Play Store prevents you from getting the app nonsensically. Does my explanation make sense?
>... like those tables on vendor websites that show their product as the only one that does virtually everything to perfection with everyone else far behind, by measuring and including only the metrics they focus on. ...that's assuming that the sheer number of checkmarks is evidence of anything. Depending on what your threat model is, each one can outweigh all others
I agree. Checklists are a bad way of conveying verified information and importance of each feature, and I do think the table can be improved. Thankfully it is open to contributions from Github account owners.
They are also completely against Play Integrity as implemented on principle.
They said they don't want to do it because it would stop working in the future when Google move to enforcing hardware-based attestation and it is not sustainable.
The GrapheneOS team understand full well that in cases where the Play Store does not allow installing an app on your device due to device or georestrictive rules you may have no choice. I have seen them mention this and acknowledge it first hand. What they do not want is for people to become satisfied with subpar solutions instead of striving for bare minimum privacy/security standards. They want a Play Store alternative front end to at least be able to guarantee you are receiving the right app you want instead of being a substitution attack risk. I don't think that is unreasonable.
>The official website has an install guide for google's background services, saying it's fine because it's in their security model.
The context is that before sandboxed-play-services were introduced people were sourcing APKs in unsafe/via unverified routes and having all sorts of problems with app compatibility because since GrapheneOS is a privacy project that do not accept sending copious amounts of data to one party with a mediocre privacy policy they included no Google services at all. sandboxed-play-services is a specific solution to the problem of apps being dependent on Google Mobile Services for functionality, and in that sense it is entirely optional. It was the best way for them to provide compatibility without destroying the privacy of their platform by introducing a privileged Google binary that can glean and abuse your production environment. It's reduced to the same level as any other app the user might choose to install themselves (which GrapheneOS want absolutely no say over as a user freedom protecting project).
GrapheneOS do not bundle any Google services in their official installation. They do not endorse Google's data collection and service practices. They do not believe Google tracking is fine in anyway, and the evidence is here: https://eylenburg.github.io/android_comparison.htm What they have done is provide a workaround for people who have no alternative, while making sure it does not violate the device owners device in a special way compared to any other app they might install.
They are staunchly against authoritarianism and mechanisms that are vulnerable to government coercion which is why they promote Android IAR and criticise Play App Signing for being mandatory.
I have understood their position to be that software is not automatically secure because it is open source, but being open source is one of the best ways to ensure to maximise attack resiliency (they believe in kerchoff's principle, shallow bugs, collaboration as a pragmatic help to get there not taken for granted or a guarantee). You'd probably be interested to know the founder once proclaimed publicly that they would never work on proprietary software.
Don't pay too much heed to how community members frame things, they are human and get things wrong in service of trying to reduce conversation to specific facts and technical assurances instead of discussing the bigger picture.
I believe nothing prevents other individuals and organisations from building what you're suggesting with GrapheneOS code and ideas.