/e/OS community talking about it: https://community.e.foundation/t/article-from-grapheneos-abo...

And then maybe this: https://eylenburg.github.io/android_comparison.htm

Hope that helps.

Sure they have hardened everything but realistically, that's not the main threat for your average user.

Their top contribution to android is the sandboxed Google Play, by far.

GrapheneOS does care about both, quite obviously. And GrapheneOS tends to say that if your security is bad, then it is affecting your privacy too. Whereas others say "sure, we break the Android security model by unlocking the bootloader and signing our system with the Google test keys, but your apps will contact Google through microG instead of the Play Services, so it's more private". Which is worth what it is worth...

I'm not sure Cyanogenmod had a marketing team that convinced me of anything when I first installed their rom in 2013 and explored my phone's capabilities with root. Accessing the sensor devices, inspecting what the different apps do, what the OS is doing, installing Xprivacy to provide fake data to tracking apps... none of that is possible on GrapheneOS, you can only use the Android APIs, same as on stock

Am I brainwashed by marketing?!

My point is that

1. If you care about privacy, you should care about security. If your email server is compromised and your emails leak in the public internet, then they are not private anymore.

2. GrapheneOS does care about both security and privacy.

> explored my phone's capabilities with root. Accessing the sensor devices, inspecting what the different apps do, what the OS is doing, installing Xprivacy to provide fake data to tracking apps... none of that is possible on GrapheneOS

I think you're talking about something like "freedom", here. GrapheneOS doesn't claim to give you the freedom to do whatever you want. In fact, part of the Android security model is to limit your freedom.

Which is not to say that you should not want the freedom to have root access on your phone. But if that's what you want, GrapheneOS is probably not it.

You can invert your logic as well: Why care about security without privacy? If your apps are leaking everything to the internet, what's there to keep secure. One could argue this is the essential dependency, not the other way around, since security depends on the threat model but, without privacy, there's no more secrets

> I think you're talking about something like "freedom", here

In part, as well as a means to an end, yes. (GrapheneOS uses this as well, since without the freedom to bring your own OS, they couldn't run on Google's devices. I would think we all enjoy having the freedom to do what we want with our own hardware.) Note also the part where it says "provide fake data to tracking apps": that's privacy which GOS doesn't offer but a user root device / any desktop OS would

That's EXACTLY my point here. GrapheneOS cares about both, because GrapheneOS considers that they go together.

People come and say "GrapheneOS doesn't understand that people care about privacy and not security, therefore people are happier with less secure systems like /e/OS because /e/OS doesn't care much about security but cares about privacy".

My point is that I care about both, and I am therefore happier with GrapheneOS because GrapheneOS cares about both.

> Note also the part where it says "provide fake data to tracking apps": that's privacy which GOS

GrapheneOS offers such privacy features (like giving a permission to the app but telling the system to feed it dummy data). But yeah, maybe it's not exactly doing what you want (actually it sounds more like you just don't know what GrapheneOS can do, but it's not stopping you), therefore you can probably go around and claim that "GrapheneOS doesn't provide privacy", because why not?

Reminds me of https://xkcd.com/1200/

They don't recommend you to do that. They tell people that if people want to install apps, Google Play Store is a secure and easy way to get apps. They inform people about this because some have the misconception that using the Play Store defeats the whole purpose of GOS (which it doesn't) or that the Play Store is highly problematic (it's better than most alternatives). But, the user itself is free to decide what they do. If you look at project members of GrapheneOS, some say they use Play, some say they don't.

> The sandbox doesn't matter if all the private data is in the same sandbox!

That's not how sandboxing works. The sandbox is around the app. Each app is in the sandbox. On GrapheneOS even the componenents of Google Play (Play Store, Play Services and on older installs Play Services Framework) are sandboxed. On Android OSes that bundle Google Mobile Services (GMS), Play gets an exception and is a priviliged app. On GrapheneOS they are regular apps. They are each put in their own sandbox. The access of each is controlled by their own set of fine-grained run-time permissions.

With all due respect, you fundamentally misunderstand how sandboxing works, even on Android in general. I recommend reading this to understand sandboxing in the AOSP: https://source.android.com/docs/security/app-sandbox . On GrapheneOS the sandbox is hardened a bit, but that's not the most significant feature of the OS at all, and Play is forced to run sandboxed if users choose to install it.

When you run an app on Android, it runs in a sandbox. Meaning that your social media app cannot access the files of your banking app by default. They are "sandboxed".

On a normal Android, the Play Services are installed as a system app. It is privileged app that has "system" access. A system app is not sandboxed.

GrapheneOS allows you to install the Play Services and the Play Store as "sandboxed" apps in that they run unprivileged, just like WhatsApp or TikTok or your banking app.

So running the proprietary Google apps in the sandbox is obviously more private than running them as system apps, wouldn't you say?

I agree there's some marginal benefit that sandboxed GApps need to prompt the user for permissions (rather than having privileged system level access) but at the end of the day, Google Maps will get GPS perms and Google will know everywhere your phone goes.

Sure, but that's the same if you run TikTok with microG (which will relay your data to the Google servers just like the Play Services) or in waydroid on a Mobile Linux. But you can't blame the system for what the apps are allowed to do by the user.

Take your Google Maps example: if the user wants to run Google Maps, obviously they will be sharing data with Google. It's very weird to blame the system for that.

What the sandbox brings is that for users who want to run the Play Services (because they want to run TikTok, knowing that it will share data with some servers, including but not limited to the Google servers through the Play Services), then at least the Play Services are not root on their OS. So then instead of running microG, you can run the Play Services and have the same kind of benefits.

Now if you don't want your apps to contact Google, then by all means, don't install the Play Services! But don't install microG either! And don't install Google Maps!

It's all about trade-offs, it's not an all or nothing situation. Sandboxed Play Services is better than privileged Play Services.

You're of course correct that we can't blame the system for choices made by users, but I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps: https://grapheneos.org/usage#sandboxed-google-play

Also, it's not a better option to use MicroG. MicroG is in most OSes where it's bundled running priviliged and still connects to Google. Moreover, their reimpementation isn't complete and also not as well odne as Google's.

> encouraging users to install sandboxed GApps

What you link isn't an encouragement at all. It's offered as an option, because there is a demand for it in order to keep compatability with apps high. It's a usability feature (compatability) that's implemented much more securely and privately than on other OSes because it runs in the sandbox. Users are not forced at all to use it nor are they pushed to it.

Not all GrapheneOS project members (devs and moderators) even use Google Play, so how would they be "lulling us into complacency".

> focusing on the security angle only

The app sandbox isn't only a security feature, it's a privacy feature. Access to your data is gated behind permissions due to the sandbox. This is privacy.

microG still forwards the requests to the Google servers. Not sure what you mean by "tracking APIs"? microG is a reverse-engineered, open source implementation of a subset of Play Services, right? It's not obviously a better option: for instance, some things that are supported in Play Services are not supported in microG, and microG sometimes breaks (because of changes in the API).

> allows you to select alternative Location Providers

GOS does that, too.

> I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps

I don't get that. It does not encourage them to install Play Services, it makes it available. Because for many (most?) users, it is important to have it.

I am not sure what you are trying to say: is your opinion that there is no point in using an alternative OS (like GOS, /e/OS, LineageOS, IodeOS, ...) or are you trying to say that GOS is not the most secure/private alternative OS?

My opinion is that GOS is very successful at its own stated goal of having an extremely secure mobile OS that rolls out patch updates quickly. I think it's far less successful at protecting user privacy because — as you even admit, many/most of them will find their phones unusable with vanilla GOS and immediately follow the GOS user guide to install Google Play and help them securely upload their personal data to the world's biggest adtech firm.

I think iodéOS and /e/OS are more in line with what I want from a mobile OS.

I installed the Play Services right away, just like I installed microG right away on a LineageOS system (I don't know about iodeOS, but /e/OS comes with microG by default). In terms of privacy, I don't think it is very different: microG is an open source implementation of the Play Services, that also contacts the Google servers. Many will use something like the Aurora store, which is a client for the Play Store. Etc.

GrapheneOS has proxies, e.g. for the location service. They are doing a lot for privacy, that's very clear.

> I think iodéOS and /e/OS are more in line with what I want from a mobile OS.

And that's your right. I think that GrapheneOS is more secure, and not less private than those. Actually in my experience with /e/OS, it was less secure than Stock Android (though more private, admittedly).

That's not really true. In fact, the way you are presenting it, as if they were seperate is doing a disservice to the reality and therefore to the users.

You can't have privacy without security. Security is what enforces the privacy. If your system is insecure, privacy controls can be bypassed.

> My opinion is that GOS is very successful at its own stated goal of having an extremely secure mobile OS that rolls out patch updates quickly.

GOS' "own stated goal" is privacy, security and usability. The main reason the project is made is to give people privacy, and the reality is that in order to give privacy you need strong security. Usability is also striven for by trying to match other mobile OSes in app compatability and accessibility features (the latter being a current work in progress with TTS and STT coming soon).

> I think it's far less successful at protecting user privacy because — as you even admit, many/most of them will find their phones unusable with vanilla GOS and immediately follow the GOS user guide to install Google Play and help them securely upload their personal data to the world's biggest adtech firm.

Many people are able to use their phone fine without installing Google Play. It depends on choices people make. If you use a different set of apps not relying on Play, it's perfectly possible to use it. If you care so much, just change the apps you use. Also installing Google Play doesn't equate to "securely uploaidng their personal data to the world's biggest adtech firm". Again totally misunderstanding how the app sandbox works.

> I think iodéOS and /e/OS are more in line with what I want from a mobile OS.

Unclear what you want. If you want something aligning to your vibes and ideology, probably. If you want privacy, not really.

Again, this is an obtuse perspective. A system that doesn't collect or store private data never needs to concern itself with securing that data.

I am concerned with reducing casual data exposure to the adtech industry. I am not worried about being targeted by nation state actors.

Sandboxed-Google-Play is not encouraged or promoted. It is suggested if you need apps only accessible via Google Play or needing Google services purely because it provides the maximum compatibility. GrapheneOS have always said that Android's strnegth is a large wealth of open source apps (many of which do not need Google). If more everyday apps (media streaming, taxi, food delivery & rewards, banking, government, social media) did not depend on Google, GrapheneOS would not spend the time, resources and effort that they have on sandboxed-google-play.

If you just grant Google Maps location permission and don't give it to Play Services and keep your sandboxed google play settings to the default, the location requests are rerouted through the GrapheneOS servers. If you want to use network location to get quicker location locks and location indoors, you can also use GrapheneOS network location, so you don't need to use the Google implementation for that.

And, even if you would decide to use Google directly for the location, you can perfectly avoid giving permanent location access. You can hand it over only once or only when the app is in use. So Google doesn't know everywhere your phone goes, at all.

It's a misconception that GrapheneOS is focused on security over privacy. It heavily works on privacy features and the work on security features is entirely to protect privacy. There's widespread use of commercial exploit tools and GrapheneOS is proven to provide far better real world protection against those. Most alternate operating systems reduce privacy from AOSP and massively reduce security while GrapheneOS is preserving the baseline and heavily improving both side by side.

GrapheneOS is also very focused on usability and app compatibility, making sure to preserve those with the major privacy and security enhancements.

The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.

I feel like you can't really fix android anyways, the design is just broken and if you care about security / privacy, you should just use everything in a browser or a Linux distribution.

Sure the work GrapheneOS does is valuable but it's like removing water from a lake with a bucket.

I feel like shielding the mess that Android is into something like an improved Waydroid with a mindset of "yeah let's keep it there and the sane stack for the rest" sounds a better approach to me.

Content filtering is built into the browser. GrapheneOS have always maintained that you cannot prevent an app from exfiltrating data, especially if it has internet access. Enumerating badness is an unsustainable approach they don't want to encourage. Instead they attack the heart of the issue with Storage Scopes/Contact Scopes/Network Permission/Sensors Permission etc. They allow aps to think they have full access when they do not, so you can control exactly what data they get in the first place. Maybe all of the other AOSP projects could contribute App Communication Scopes/Enhanced Clipboard Privacy and other things because this approach makes a lot of sense to me. Like preventing an illness instead of wasting energy treating symptoms.

>The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.

Something similar was addressed some years ago as a feature request for GrapheneOS https://github.com/GrapheneOS/os-issue-tracker/issues/284. To summarise there was no way to do this without an unacceptable security cost to the OS, but this is sort of doable if you run your own userdebug build which you have the power to do.

It's badness enumeration which is an unworkable approach to providing strong privacy. It fundamentally can't provide it, only weak case-by-case improvements which are very fragile and trivially bypassed. It can also be done by modifying APKs instead of having a hooking framework within the OS heavily compromising security. You don't need the OS providing anything to use arbitrarily modified APKs. We also don't want to give apps a legitimate reason to ban GrapheneOS as opposed to being able to convince the tiny number of apps enforcing Google certification to allow it.

I think you said the truth out loud, a rom which tries too much to fight for your privacy would just be banned. (And I do agree with that)

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.

> GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.

Enumerating badness by trying to list domains which are solely used for advertising, telemetry, etc. doesn't address any of the main privacy invasive behavior by apps which is done through their own services and server side contact with third parties.

uBlock Origin has the same problems in the browser but the rules within a browser are a lot more flexible than the extreme limitations of domain-based blocking whether any useful purpose of the domain results in blocklists not being able to include it or apps would break. Domain-based filtering is also far less usable in practice and is typically not per-app either.

RethinkDNS on GrapheneOS works far better than the domain blocklist in /e/ but it's not a strong approach to privacy and does not address much.

Apps can easily work around it and prevent the filtering, as can the SDKs. One way is doing server-side connections and another is using DNS-over-HTTPS for DNS resolution. Facebook has fallback IPs and DNS resolution in a growing number of their apps and can do it in their SDKs too.

Using a fundamentally unworkable approach that's increasingly becoming less useful is not how GrapheneOS approaches privacy.

> The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.

This is another fundamentally unworkable enumerating badness approach which is not how GrapheneOS approaches privacy. GrapheneOS avoids apps getting access to sensitive data rather than trying to stop them sending it to specific places.

> I feel like you can't really fix android anyways, the design is just broken and if you care about security / privacy, you should just use everything in a browser or a Linux distribution.

GrapheneOS is a Linux distribution. Desktop Linux distributions have far worse privacy and security than GrapheneOS. The ports of desktop Linux distributions to mobile are largely losing even more security. That's a huge setback for privacy and security, not progress. They don't have similar privacy protections, don't have a similarly strict approach to privacy for default services and lack security to keep privacy intact. Using mostly or only open source software doesn't mean you don't need privacy and security protections. Aside from that, the open source mobile app ecosystem for Android and GrapheneOS is far better than it is for those operating systems.

> Sure the work GrapheneOS does is valuable but it's like removing water from a lake with a bucket.

GrapheneOS provides drastically better privacy and security than the desktop operating you think are better. It has a great open source app ecosystem available with lots of high quality apps. You're portraying it as if people must use privacy invasive apps but that's not at all the case. Plenty of desktop users are using apps like Discord where they can access the entirety of their data as opposed to GrapheneOS where it's a heavily sandboxed app with lots of user control along with prevention of coercion to get access via the scopes features we add for pretending to grant permissions while actually granting access to no files/media/contacts by default where it simply appears there are none until users explicitly opt-in to adding them.

> I feel like shielding the mess that Android is into something like an improved Waydroid with a mindset of "yeah let's keep it there and the sane stack for the rest" sounds a better approach to me.

Waydroid has far worse privacy and security from Android apps than running them on AOSP or especially GrapheneOS. It loses the Android app sandbox and permission model. It uses a very outdated fork of AOSP and breaks the privacy/security model through how it's implemented. It runs on top of a far less secure host OS with worse isolation for the apps inside it from the rest of the OS than exists on Android itself. Moving to a drastically less private/secure host OS while running Android apps in a much less private/secure way is hardly progress.

I feel like we agree on the premises but not the conclusion then.

If there's no way to make a Revanced on steroids system work on Android, it means that Android's security model is fundamentally broken for me and beyond repair.

Fundamentally, Android is built with untrusted as its core value. Google doesn't trust Qualcomm, which doesn't trust the manufacturer, which doesn't trust app makers, which doesn't trust the user. It's a chain of untrusted parties all the way to the user. With one single exception, in your average phone, the user has to trust all the the above. So the user is the one trusting everybody blindly and nobody else has to do it.

The only way to make this untrusted chain model work is to go one step further, make the user not trust all of the above with a heavily modified system, including dynamic patching and that's almost impossible.

The reason why it works differently on a Linux distribution is it's built on the opposite values. The maintainers trust contributors which trust app makers ... all the way to the user. If one of them breaks that trust, they are out for good, they know they have one chance and this makes the stack fundamentally less hostile.

You can't easily fix a broken social contract like in Android with just tech.

Brave has the best anti-fingerprinting on Android right now but it's not all implemented in a good way and they have a lot of features with privacy and security downsides too. Vanadium is gradually working towards having stronger anti-fingerprinting than it. It will take time. In general, our approach is focusing on doing things properly with the long term in mind. It takes longer but the end results will be better as can be seen for what we ship in many areas. Our network-based location implementation is a nice example among many others.

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.

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.

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.

As far as I know none of these projects have tackled the JS fingerprinting problem. The most earnest attempts seem to be Brave and Firefox with the Arkenfox user.js, but they have their own problems. The basic issue is that JS gives websites far too much control over the user's device. The JS spec should have never allowed websites control over the clipboard (e.g. to disable paste), to know if the user is active, when the mouse is being moved, etc. Since it is too late now, short of disabling JS entirely, there will be usability tradeoffs, but I think these are necessary (at least optionally) in an OS like Graphene.

Unfortunately, browsers have often done too little, too late when it comes to privacy. For example, until recently, most browsers allowed third party cookies by default.

And sandboxed Google Play services serve both goals -- it runs the service as a regular android service, not an exceptional one that has a bunch of extra permissions. So you can allow/restrict it as you seem fit, while not "getting behind" on features/apps that mandate it.

But how would you "rate" for example desktop "GNU/Linux" with this in mind? Quite clearly privacy is important here and none of the major components leak/store unnecessary personal data. But the security story is quite sad, everything runs as the same user so a random `npm install` can just do whatever it wants with my browser caches, ssh keys, etc. I would say that GNU/Linux is privacy-friendly, but has terrible security. Would you not agree here? How does this fit with the "privacy and security are not separate things" part? Genuinely curious about your opinion here, not arguing for the sake of it, they are just not as closely connected in my mind. For example Google has a good track record of having safe practices regarding data storage -- but privacy is not their strong suit/hard to define what it means for a company to begin with.

Any privacy you have on a system is reliant on no one tampering with that system and on software behaving itself. Without security, you can't trust the system to implement any privacy.

You can't fix a lack of trust like you have in Android with technical solutions. The flaw in Android is fundamentally a social problem.

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.

In that it doesn't really exist. Sure, linux has all the capabilities to do it properly, but defaults matter in security so the way it currently works, basically every program has access to everything actually important (personal files, photos, ssh keys, etc). It just can't upgrade your GPU driver.

I trust my Linux distribution because there's a chain of trust, from the maintainers, the contributors down to the user to make sure that the software is respecting the user.

You can't fix the lack of trust you have on Android with just sandboxing.

As has been shown, it's almost trivial to get malicious code merged into open source projects, so not really sure where your "trust" comes from. It's not trust, it's naiveness.

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.

Nope, that's not actually how it works. In reality, there's little to no review of what's being packaged. The distribution packagers are additional trusted parties. You're also trusting the upstream developers and their dependencies which are largely not very interested in privacy and especially security. There's extremely little systemic work on privacy and security in desktop Linux operating systems which is why they still haven't fully deployed basic exploit protections from the early 2000s, let alone providing a strong privacy and security model with strong defenses throughout the OS.

> You can't fix the lack of trust you have on Android with just sandboxing.

Contrary to what you keep saying, Android has a large open source app ecosystem. Those open source apps run in a sandbox avoiding them being a single point of failure for the entirety of privacy and security of the OS. The vast majority of open source developers are not writing privacy and security focused software. Security is extremely neglected in the vast majority of open source projects and many do privacy invasive things. Open source does not provide privacy and security itself. Publishing sources under an open source license doesn't make software more private or secure itself. Most open source projects aren't getting significant privacy and security benefits from doing so since little of it gets deeply reviewed. Most projects do not get a lot of external contributions to the code. Open source code doesn't mean the developers aren't heavily trusted and only theoretically provides the ability to check everything extremely thoroughly which simply doesn't happen. If it worked the way you believe, there wouldn't be an endless stream of vulnerabilities being fixed which have often been present for a long time including years or decades. See https://lore.kernel.org/linux-cve-announce/ for a major example.

If you want something backed by objective data, my phone has an advertising ID built in the OS and my laptop doesn't. My phone had 100s of privacy scandals and my laptop doesn't have one.

I do applaud GrapheneOS don't get me wrong but I have a feeling that they are fighting a losing battle.

GrapheneOS provides far better privacy and security than a desktop OS. There's no such thing as an advertising ID built into GrapheneOS so it's a strange thing to bring up. There are plenty of privacy invasive things built into desktop operating systems and applications, including open source ones. They nearly entirely lack the ability to protect against apps and services being privacy invasive in the first place. They also have far weaker protection against exploitation.

You can find hardware identifiers exposed by Linux distributions more than by Android itself. That Google adds a nice sauce on top... yeah that's a sorry state of affairs, but an optional layer if you don't use the stock OS if it ships with Google Play

edit: but I appreciate looking it up nonetheless! I wasn't completely sure that I hadn't missed that Android (AOSP) includes this now as well

Even EOS and GrapheneOS realized that themselves.

https://en.wikipedia.org/wiki/Agreement_on_Reciprocal%2C_Fai...

Do you happen to know where does the narration by Andy Serkis come from? Is it a game? An audiobook?

@TeamYouTube responds later that they will reconsider:

> Really appreciate your response, and can see how sorting by upload date is helpful when tracking breaking news. We're sharing this feedback live with our product team

- how important YouTube is in the real world and

- how disconnected the "Product Team" is, by inference from this reply.

A semi-random recent example from someone else, Samsung changed contacts list in recent update, so now recently added contacts is above favorite contacts, and it's done in such a way I now have to scroll to get to my favorites... like WTF.

Samsung aren't unique though. Microsoft for example has spent the first few years if each release of their OS usable since Vista, with the exception of Windows 7.

"the market moves faster than the tech" and in this case the tech is not evolved (e.g. to protect the fact YOU want your favorites at the top) because the PMs may never prioritize it.