Other way around, actually. It's possible to make concessions to privacy, like providing crash reports, or running applications in sandboxes which limits what they can harvest, while keeping the platform secure.
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.
I also disagree with that, I trust my Linux distribution to behave well much more than I trust any Android platform and it doesn't even have much app sandboxing at all.
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.
There's a massive open source app ecosystem for Android which is far larger than the subset available in F-Droid. Open source does not imply private or trustworthy. Completely trusting applications with access to all your data with no insight in to what they're accessing or sending to services means you wouldn't know if your privacy is being violating anyway.
The (desktop) Linux security model is different. You trust the distro maintainers in the same way you trust the GOS devs, and instead of "app sandboxing" you use user accounts, containers or VMs to protect personal information. The Android security model makes sense in the context of laypeople using mostly commercial malware on the stock OS however.
> 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.
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.
I do trust the Linux distro maintainers that they don't have nefarious purposes. But they can't and won't verify third party projects' code, nor the huge number of contributors that come and go on any of these projects, or their transitive dependencies.
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.
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.
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.
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.
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.
> 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.
> 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.
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.
That's the difference between trusted computing (Linux distribution) and untrusted computing (Android).
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.
There's a huge open source app ecosystem available for Android. The distinction you're trying to draw is inaccurate. Open source apps also very open do privacy invasive things. On Android, people can see that many open source privacy even including Signal include dark patterns such as repeatedly asking for access to contacts when it works without it. On a desktop OS, the apps and services will simply have access to nearly everything by default so you aren't aware of it happening for the most part.
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're linking to Google Play's documentation, not Android code itself that GrapheneOS etc. are built upon
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
You can't really use Android without the Google Play anyways so that's a moot point, none of the popular apps will work. Google Play is very much a core part of the Android OS.
You can perfectly fine use it without, many people do.
If you can tell us what issues you exactly bump into when trying to use the phone without Play, feel free to share, we might be able to suggest you some apps or workflows to work around the issues you are having.
> CachyOS or Bazzite would have provided a smoother Steam experience. But it’s also illustrative of the problem. Saying you use Linux is almost meaningless because there are so many different flavors.
"Saying you like PCs is meaningless because there's so many different options" is an equally stupid thing to say with about as much justification for it. This article is just the author trying to rationalize a bunch of poor choices.
Microsoft test on and make considerations for Proton for a bunch of their releases. Sony do too. Cyberpunk has specific graphics presets, Baldurs Gate 3 has a native executable, indie games often do too.
There's outliers, it'd be fair to say EA don't give a damn. But a lot do and you can't handwave away Microsoft and Sony as small fish either.
It isn't equivelent in the sense that the progressive scanout on CRTs resulted in near-zero latency and with minimal image persistance, versus flat panels which are global refresh adding latency and worsening motion clarity. So it isn't really a "but", it's a "made even better by being rendered only one pixel/dot at a time".
Motion clarity yes, but it's zero latency in the least useful way possible, only true when you're rendering the top and bottom of the screen at different points in time. And scanout like that isn't unique to CRTs, many flat panels can do it too.
When rendering a full frame at once and then displaying it, a modern screen is not only able to be more consistent in timing, it might be able to display the full frame faster than a CRT. Let's say 60Hz, and the frame is rendered just in time to start displaying. A CRT will take 16 milliseconds to do scanout. But if you get a screen that supports Quick Frame Transport, it might send over the frame data in only 3 milliseconds, and have the entire thing displayed by millisecond 4.
If you install a distro that uses KDE Plasma, you're already most of the way there. Not just because of it's design similarities to Windows but it's the desktop environment that's been getting the most financial support lately and has seen the most rapid improvement.
I personally prefer it at this point. Dolphin blows away explorer, window management is more slick and more flexible out of the box and it also happens to be deeply customizable.
I'm in a few Linux communities and they have grown somewhat over the last couple years. There's definitely been a swell of users moving over, if not a wave.
You're fairly significantly downplaying their contributions. They have a substantial amount of FOSS developers under contract working on SDL, DXVK, VKD3D and there's over a dozen people on working on KDE on Valve's dime alone. Proton isn't a fork of Wine, it's a Codeweavers managed project funded by Valve that packages Wine, virtually everything useful ends up going upstream given Codeweavers are also the main contributors to Wine. AMDGPU, NVK, Valve funded. Valve have been funding FEX since it's conception.
That isn't even everything, just what I've been able to confirm either through interviews or conference talks where their involvement has come up. They've quietly been doing a lot for Linux.
The problem with 'well just don't buy it' is that in many product categories, enshittification has become so entrenched that there are no longer options to avoid it. The availablity of product features is driven by market forces, if it's no longer profitable to sell a TV that doesn't require online connectivity for the purposes of ads, then such TVs will no longer be sold.
Alternatives like using monitors designed for digital signage come with drawbacks. Expense, they don't have desirable features like VRR, HDR or high refresh rates, since they aren't needed for those use cases. Older TV models will break and supply will dry up.
In the long term, this problem, not just TVs but the commercial exploitation of user data across virtually all electronic devices sold, isn't something that can be solved with a boycott, or by consumers buying more selectively. The practice needs to be killed with legislation.
VRR is Variable refresh rates, so if there is nothing going on in the content, they can bring the refresh rate down and save processing, thermal issues and energy. If there is a lot going on(say a game), they can ramp the refresh rate back up super high.
There are a few different "standards" around VRR, not every device supports all of them.
Their explanation of the reason for VRR is bad. The primary reason people want it is gaming where the game is not locked to a specific frame rate. Without VRR, the timing of a frame being delivered isn't necessarily going to match when the display is expecting a new frame. This leads to one of two effects. Either the display is forced to hold an old frame for longer and pick up the new frame on the next refresh cycle, which creates stutter. Or the display switches which frame its using partway through the refresh cycle, which creates a visual tear in the image.
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.
reply