> 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.