GrapheneOS – Break Free from Google and Apple

> The (desktop) Linux security model is different.

Desktop Linux distributions lack a viable privacy and security model for applications and far more. They don't have comparable protections against exploitation or comparable privacy protection as a systemic part of the OS either. The approaches are very incomplete and apps generally aren't contained unless they're run in another OS in a virtual machine such as the approach in QubesOS which is not really a Linux distribution but rather a Xen distribution acting as a meta-Linux-distribution. It can use Windows too.

> user accounts

This isn't an application sandbox and doesn't provide similar isolation for desktops.

> containers

Containers do not directly work for sandboxing desktop applications. It still requires that the UI and application layer of the OS provides sandboxing. Containers can be used to isolate things at the filesystem level, etc. as part of a sandbox but are not a sandbox for desktop applications on their own.

> VMs to protect personal information

GrapheneOS has hardware accelerated virtualization on all supported devices. Running a separate OS in a VM is a much different thing from providing a working privacy and security model within the OS. Using virtualization as part of an app sandbox that's integrated into the OS itself with a separate VM for each app is a far different thing than just running another OS in a VM.

> The Android security model makes sense in the context of laypeople using mostly commercial malware on the stock OS however.

Android has a far larger open source app ecosystem for mobile than those operating systems. Open source applications still need to be sandboxed to provide reasonable privacy and security. Otherwise, you're not only trusting those applications and their supply chains to not do anything privacy invasive which does happen extremely frequently but also to avoid having vulnerabilities. The vast majority of applications do not take privacy and security very seriously so an OS not containing them and protecting them against exploits with modern exploit protections won't provide good privacy and security itself. Application vulnerabilities are the main attack vector for remote attacks. Open source software as an overall ecosystem is also not nearly as privacy respecting as you make it out to be. Most is not focused on privacy or security, which means they regularly do things which are privacy invasive to provide functionality and also aren't providing strong privacy or security protections at all.

> The proof is in the pudding at the end of the day, how many privacy scandals Debian had vs how many privacy scandals Android had? One model seems to clearly work better than the other. Talk is cheap, I like to see the results.

You're drawing completely false equivalences between a specific OS and an entire ecosystem with tens of thousands of operating systems. For some reason you're including apps like Discord as part of your evaluation for the OS for Android but not desktop Linux. On desktop Linux, Discord gets access to everything. On Android, it's a sandboxed app. On GrapheneOS, it's a much stronger app sandbox with far better user control including features to avoid apps coercing giving access to files/media and contacts, etc.

> And to answer your question, of course they can't check everything, that's why it's a model based on trust and not a model based on verify.

Distributions aren't doing any significant review of what they package in practice. Debian ended up with backdoored sshd not because their review missed something in xz but because they don't review it in the first place.

Open source software very regularly has privacy invasive services and practices. It's very common and not at all rare. Actual backdoors and malware is rare but the same goes for proprietary software from reputable companies. Privacy invasive behavior is more common for proprietary apps. You're portraying it as if Android doesn't have a large open source app ecosystem when it absolutely does and as if proprietary software doesn't exist for desktop Linux when it absolutely does. The basis of all your arguments about this are these false premises.

> What would happen if let's say VLC would upload your user documents in the background? They would get nuked out of the repository and never be seen again. That's why apps do not tend to do that.

VLC is available as an Android app. VLC is not a privacy or security focused app. It doesn't provide strong protection against exploitation from maliciously crafted media files or malicious services. Running it on an OS with strong exploit protections for apps and a sandbox around it not giving it access to everything is very valuable. VLC on GrapheneOS has far stronger exploit protections including hardware memory tagging along with being in a very good sandbox. Users don't need to grant it access to most of their files and generally won't since they can use it without granting access to any files, grant access to specific indexed files types, specific directories or do it on a case-by-case basis.

> I'm not against sandboxing and a strong technical model myself, it's just that if I have to pick between a trust model and technical features, well the trust model wins hands down 10 times out of 10 as it has a better proven track record.

GrapheneOS has a large open source app ecosystem far bigger than what's available for non-AOSP Linux distributions on mobile. It has a strong app sandbox with a permission model that's getting increasing good both from upstream AOSP improvements and our growing privacy protections. Our Contact Scopes and Storage Scopes features are an approach we're taking for other permissions too to gradually phase out permissions where an app either works or doesn't work based on granting a specific permission even though it doesn't need to be that way. We took care of the main ones already but there's a lot more to do. This is very useful even for open source apps which rarely focus on privacy and usually doesn't care much about security. It's extremely valuable to avoid giving open source apps access to more than they need. You brought up VLC as an example which has atrocious security and is a great example of an app heavily benefit from sandboxing even if you fully trust not only the VLC developers but also the developers of the large dependency graph.

> Tor Browser seems to be a project that requires multiple full time developers. I don't think GrapheneOS have the resources right now to do this alongside their OS development, device support and app overhaul plans.

We're in the process of hiring a bunch of full time developers and will have more people working on Vanadium soon. The bottleneck isn't money but rather building out the organization and hiring people. We get a lot of donations and are going to be greatly expanding the project, particularly with the funding being offered by Vitalik Buterin for hiring 5 more full time developers.

> Also please don't take this as any criticism of your suggestion, but there have been multiple 'privacy' browser projects based on Chromium for Android. It's a little frustrating that they couldn't collaborate some base like this to the open source community.

Many aren't using permissive licensing and a lot of it is a mess that's not possible to include in Vanadium rather than making our own implementation that's more focused on correctness and maintainability. GrapheneOS is going to have an increasingly large amount of resources so we wouldn't get much from working with tiny projects. We could hire people to work on Vanadium instead. Working with Brave would be compelling but not much else. Brave has a lot of stuff we want but usually it's quite messy and complex compared to what we want to have. We're using work from Microsoft on Chromium hardening that's not used in Chrome / Chromium such as the WebAssembly interpreter.

GrapheneOS has a lot planned for Vanadium. It could become a project almost as large as the core OS project. We're going to be greatly expanding our team and that needs to happen before Vanadium can have substantially more changes than it currently does. Full state partitioning including for cookies is a much better approach than disabling third party cookies. Vanadium does disable third party cookies but that doesn't really do as much as you'd think because the way third party cookies are defined and what disabling them means is not intuitive. Third party cookies would not be a significant issue if cookies were fully partitioned by the top level site. Chromium has implemented state partitioning for the vast majority of the state but specifically not cookies by default where it's opt-in, so we need to handle that ourselves. They do support partitioned cookies but it's opt-in. Strictly partitioning cookies breaks a lot of cross-site functionality so no mainstream browser is doing it but rather they use heuristics to support cases like cross-site login and their partitioning is easy to bypass through that.

Protecting strong privacy conflicts with the kind of hooking features unable to actually protect privacy without being easily bypassed. The reason apps would ban doing that is due to compromising the privacy and security model for applications, not protecting user privacy.

Nearly the only thing which would potentially result in the OS being banned which is a legitimate privacy feature would be hiding that the Mock Location feature is enabled which is pretty much pointless since apps can ban the OS as a whole instead of only banning using them when Mock Location being enabled. Our planned per-app Location Scopes feature doesn't necessarily need to say that Mock Location is enabled but it should be possible for apps to detect so they don't have an excuse to ban GrapheneOS as a whole. It's far better that they ban using Location Scopes than banning using GrapheneOS at all. We could make our own API for detecting it's enabled so that apps detecting Mock Location work but apps aware of GrapheneOS can choose to ban Location Scopes rather than banning GrapheneOS. We aren't going to do something which simply hurts users should reducing the apps they can use for no actual benefit.