tranq_cassowary

GrapheneOS user and community member here. TLDR: The blog post that this thread links is full of misrepresentations and falsehoods about what GrapheneOS offers and also is heavy mismarketing of the phones and services PrivacyPros offer. I recommend to avoid PrivacyPros.

The basic premise, that a secured and private phone, is useful for domestic abuse victims is of course okay. It is true that protecting your privacy from abusive family members can be useful and GrapheneOS' features, which are accurately described on their own website (contrary to the linked blog post), certainly help remove threats in that regard. See : https://grapheneos.org/features . This is dependent on the specific situation, of course, (e.g. huge difference between ex-partner stalking you and a current partner you live with abusing you), because if you are forced to give your phone password at the threat of being hurt, a secure phone won't really help you a lot.

While the licenses that GrapheneOS uses permit companies to establishes businesses using GrapheneOS software, it's not recommended by the project to buy pre-installed phones, certainly not pre-configured phones, like PrivacyPros offers. The install process of GrapheneOS is simple if you are using the WebInstaller, and there is a lot of free support available in the community chat rooms and fora if you bump into issues. This saves you a lot of money because you can buy a new, used or refurbished Pixel with the stock OS installed at a much lower price. If you install GrapheneOS itself the guide also mentions you have to verify the integrity of your installation. That also holds true for preinstalled phones, you should check the verified boot hash and set up Auditor app. Preconfigured phones should actually be completely factory reset, not only from the OS but preferably also from recovery mode and then set up again, with a check of the boot hash and a set up of Auditor app before you install any apps or start changing settings. You don't know what PrivacyPros has changed to the settings, what they loaded on the device and Auditor should be set up by yourself and straight from the beginning, before you start using the device, because pinning-based security is an important part of its security model and you would want to be pinned to a clean state from the post install.

The blog post and also the PrivacyPros website where they promote and sell their phones is riddled with unnecessary misguided advice and also falsehoods about what GrapheneOS offers and what the dangers of the stock Pixel OS and Android in general are. Pixel OS and Android in general are portrayed way too negatively. I'll just give a few examples because it will cost me way too much time too debunk and correct all of it. These ones are verified easily by yourself and I hope it just makes clear you can discard everything PrivacyPros has written and makes clear you should just consult the official GrapheneOS website. So, they pretend as if Android and Pixels themselves don't have a permission model, multiple users and verified boot. This is untrue. GrapheneOS hardens the app sandbox and permissions model more and offers stuff like storage scopes to work around to broad permissions, but the sandbox and permissions model itself exists for Android in general. Verified boot is also a standard Android feature, and also exists on iPhones and even on MacOS and ChromeOS. Multiple users are part of Android, GrapheneOS just increases the available number of users and increases their usability. Also note that users don't improve sandboxing. Sandboxing and access control exist within profiles as well, profiles are mainly meant for increased isolation via separate user data, user settings and VPN slots. They also offer separate encryption keys allowing you to selectively put data at rest etc. The whole idea of a "ghost" profile and user profiles being at the centre to security and privacy is misguided. They also call about kill switches, Pixels don't have hardware kill switches and the software kill switches are just part of Android.

KiwiFarms is a platform created for the purpose of cyber bullying, harassment and encouraging self-harm. This is very different from a general purpose social media platform that happens to have people signing up that misbehave. The whole point around KiwiFarms is that it's a place to be the most terrible version of yourself and the promise that it won't be moderated. It says a lot about Rossman that he believes it's worth engaging with such people there. Yes, reasonable and ethical people would indeed choose to not be associated with KiwiFarms.

Rossman leaked private messages without properly giving background information about preceding private conversations that they had and about the circumstances that occured just before the conversation he leaked. It was very bad faith.

> Even if it improves accessibility, it must be rejected out of hand

GrapheneOS has many exploit mitigations and those that would break compatability with too much apps are opt-in instead of opt-out. They also have per app toggles so you can decide to use them per app. So they certainly don't sacrifice accessibility for the highest level of security.

> GrapheneOS promises to liberate us from the enshittification of Google's anticompetitive moat

This isn't something GrapheneOS promises anywhere on their website. They aim to offer a secure and private OS with good compatability with Android apps.

> but it focuses that effort exclusively on security.

They focus on privacy and usability as well. Security is actually only focused on because the privacy features aren't enforceable without security.

> Why is that constantly treated as an unreasonable fantasy?

Because tinkering, hackability and unrestricted freedom aren't the purposes for which GrapheneOS was made.

Phones, to just give one example, at least have fine-grained run-time permission controls while on Linux apps can just access anything the user can, except if you use something like Flatpak which gives you sandboxing but the quality of that sandboxing is still worse than Android 4.4 KitKat. How can you protect your sensitive info without such permission controls that gate access to your personal data?

Note that this is just one example, there are also other problems with traditional desktop OSes and a large portion of desktop hardware.

That's not at all what Google announced.

It has nothing to do with devices. It has to do with OSes, most notably OSes certified by Google, which GrapheneOS isn't.

Also, it will be possible to bypass it even on certified OSes.

This is a production grade OS, it's made by professionals, it's not hobbyist. It keeps up with updates of upstream Android and Linux kernel. It has a ton of good security and privacy features.

ChromeOS (most secure OS), MacOS (most secure firmware and still much more secure OS compared to non-ChromeOS competitors)

What do you think the major practical downsides are? Maybe you are not aware of how many things perfectly work or how easy some workaround are, so I am wondering.

It works but you need to install the Google Fi app from the Google Play Store.

That's not at all a similar approach so it doesn't quality as "if anyone wants *this*). The GrapheneOS feature pretends the network is down and local host is also inaccessible. This is good for compatability (apps generally take into account that a network can be down) and too avoid apps knowing you are using the feature.

Leaving USB dubbing enabled just exposes a lot of attack surface. And if you use USB debugging you are placing a lot of trust in the computer you are connecting to. You don't need USB debugging to reflash GrapheneOS or to sideload updates from the recovery mode. So, it's not relevant to prevent a device brick.

It doesn't make it more possible to irreversibly brick your phone. Even if you set it to the most strict setting the port still works when you are in the bootloader and recovery modes. See https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...

Also, it isn't the only materials difference in that threat model. To just give on example, the autoreboot feature is also useful for that.

> /e/OS focuses on privacy (i.e. reducing data leakage to adtech)

/e/OS literally sends STT data straight to OpenAI...

/e/OS uses priviliged MicroG, which connects to Google for some of its functionality

/e/OS doesn't keep up with updates properly, making its security suffer, making yoru phone easier to compromise, increasing the likelihood of amongs other things sandbox escabes which open up possibilities to data leakage.

> GrapheneOS recommends running all the proprietary Google apps in a locked "sandbox"

They don't recommend this. The user can choose to do so.

> but obviously Google still gets to see everything you do in their apps

Indeed, obviously. So, obviously, also the case on any other OS.

> e/OS tries to provide [largely but not entirely FLOSS] alternatives (e.g. their own Maps app, their own email, their own calendar) that make your phone usable out of the box without Google software.

You can install apps you need on GrapheneOS providing those alternatives yourself. Android has a large FOSS app eecosystem.

Much of the things /e/OS bundles for services are just using Nextcloud and their services have been very unreliable in the past, making people unable to access their data for months. Also, Nextcloud isn't end to end encrypted.

GrapheneOS also makes their own apps, like Vanadium, PDF viewer and Secure Camera.

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.

> They deliberately conflate security with privacy (you even write "secure/private" as though they're the same thing) in a way that does a disservice to users.

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.

Regarding location, please see my comment higher in the thread about the location rerouting through GrapheneOS.

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.

Communication between apps using IPC happens on mutual consent and is explicit. You can't just throw data to Play Services and expect it to accept it and process it well, that's not how it works. Communication via IPC is always very intentional and specific, so it will be very structured data for specific purposes, not just a dump of all your data. Firebase Cloud Messaging (FCM) is a push messaging service, it doesn't need to be used to send the actual notification. It's perfectly possible to just use FCM to wake the device and then handle notifications by yourself as app. The way FCM can be used is much different from Apple's system. Apple forces you to use their services for notifications while Google allows you to use FCM just for waking your device. It's also possible for apps to not use FCM at all and to just use WebSockets or UnifiedPush.

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.

> recommend you install proprietary apps GApps in their sandbox

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.

https://mastodon.social/@gael/115067300718940033 https://nitter.net/GrapheneOS/status/1996683131358007487#m

here you go

The founder of /e/OS regularly comments on posts about GrapheneOS on social media, almost always unsubstantive and of a low level.

There are some problems with this, often if a microSD card is used the storage on that SD card isn't encrypted because of the portability goal of it. It would be a bad fit for the project. As per the headphone jack, the headphone jack is much less durable than a USB-C port and has less use cases. Two USB-C ports on a phone would be nice however. For audio with audio devices not accepting digital audio in you would need to add an adaptor with a DAC in between but this is mostly good for audio quality given that those DACs often have better quality than the ones built into the phones. This is my opinion though, you may have different needs.

They for sure control the direction of the development but it's not really that problematic given that things downstream projects take issue with can just be removed from the source and things they want can be added.

If your criterium for choosing an OS is tinkering and hackability freedom to do modify almost anything to your liking (even if it will compeltely break your system or poke extra security holes in), then desktop Linux OSes ported to mobile might indeed be a good option.

If your goal is security and privacy (which go hand in hand), mobile OSes are clearly the best solution.

Anyway Android is still a Linux OS. The only requirement to be a Linux OS technically is to ship a Linux kernel. Adhering to freedesktop specifications like the FHS, using systemd, using GNU userspace software, etc. isn't necessary.

On Android you can install software by installing directly from APK files or you can use application stores which are package manager, they help you install software and if there are dependencies they can also install the dependencies if they support that.

Call recording is possible on multiple Android OSes, it's possible on stock PixelOS and GrapheneOS, I'm not sure about others but normally it's just part of the Dialer app. You don't need root at all for that.

It's more common in banking apps than in other apps to implement Play Integrity but it's cetainly not "most banks" that do it. It's still only a small subset. Sucks of course if it's your bank.

GrapheneOS distrusts the network. Connections use HTTPS and the integrity of important things like updates is also verified via signatures.

x86 virtualization isn't perfect at all

QubesOS certainly has some good things going for it with isolation but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS

Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot.

With regards to security through obscurity, the Pixel firmware isn't obfuscated at all. It's closed source but it's easy to decompile the code and inspect it. They don't try to obfuscate it to make that difficult.

There is no way to know whether the phone you buy corresponds to the open schematics that are published. It's not verifiable like with software.

The firmware being proprietary is compeltely unrelated to how much attack surface it has compared to open source firmware. The only thing that matters is how secure the firmware is.

Chromium is the only web engine present on a fresh install. If a user doesn't install a browser with another engine, the attack surface doesn't get increased. Chromium/Blink is more secure than Safari/Webkit overall so I don't really think this is an argument in favour of iOS. iOS for sure does some good things though and is better than Android in some areas.