[cubesnooper]

GrapheneOS allows disabling network for a particular app, alongside the other permission settings. As a rule, I’ll give an app either file permissions or network permissions, but almost never both.

A lot of apps are perfectly usable without file access by sharing a file to them from the file manager.

GrapheneOS also has “Contact Scopes,” so you can grant an app contacts access (so it thinks) but it’s actually a subset or blank list of contacts.

Another feature that’s commonly recommended is using multiple profiles. I often see people use this to run Google apps in an environment isolated from the rest of their data.

[pritambaral]

I used to use sth like that too. Then a set of apps from a scummy telephony provider in my country showed me evidence of how they circumvent this.

Turned out, all apps from this vendor talked to each other, in the background. If one app has filesystem access but no network access, and another has network but no filesystem access, the former can upload private filesystem data by sending it through the latter.

[hiatus]

How do apps utilize permissions of other apps? How does the filesystem app communicate with the network app if it does not have network privileges and other app has no filesystem privileges (ie there is no shared channel)?

[pritambaral]

Android supports IPC.

[MonaroVXR]

How did you figure that out?

[pritambaral]

Initial suspicion: Apps I had explicitly killed (equivalent to Force Stop) would start running. Most of these apps had no background services (or any reason to run in the background) and no notifications to show either. But they did have one thing in common: the vendor.

Further suspicion: Apps remain killed, for long periods of time, if I don't start any of them.

Quick test: Kill all apps. Start them one by one. Check if other apps are now running.

Confirmation: Pull APKs from device; RE their code for IPC.

[cubesnooper]

Reminds me of this classic: https://web.archive.org/web/20160720140639/https://www.csd.u...

You’ve given me something to think about. Luckily, I only have to amend my mental model a bit, to assume giving a permission to any vendor’s app is to give that permission to every app from that vendor. In most cases where that would be a problem, I already run such apps under a separate user profile, which fully prevents IPC.

[Springtime]

> GrapheneOS allows disabling network for a particular app, alongside the other permission settings.

This feature is also useful in LineageOS, as a kind of native firewall. Thankfully most open source apps on my device don't use network connectivity so the permission is greyed out to begin with.

[jqpabc123]

In e/OS, this is called "Advanced Privacy".

[Vinnl]

Sorry, I just checked the "Advanced Privacy" settings, but I see nothing about restricting network access for a particular app. I'd be very interested in that feature though - do you have more pointers how exactly to restrict a single app?

[jqpabc123]

Sorry, on e/OS this is under app settings where you can uncheck "Allow network access" for apps that have it.

[_rdvw]

This is just a feature inherited from LineageOS, not anything special to /e/OS.

[jqpabc123]

Yes. And the same applies to GrapheneOS does it not?

[bogle]

I recommend using a separate profile for apps you may want that require Google Services. GrapheneOS is perfect for this. My separate profile is called "Burner" which serves as a handy reminder to me that I may, at some point, wipe out the whole profile and every app therein.

[jqpabc123]

I have a separate "burner" phone for extreme cases like this. It contains no personal data.

microG handles most of the routine access to Google services that I need.

[matheusmoreira]

GrapheneOS is way too good. I imported a Pixel just to run it. Wish more phones had the security hardware it requires.

The creator used to post a lot about it here:

https://news.ycombinator.com/threads?id=strcat

[toastal]

That would be nice. Android has a wealth of phones with features, but the Pixel line is missing some I would consider “required”— not mention they aren’t available in my country.

[NullPrefix]

>I’ll give an app either file permissions or network permissions, but almost never both

App with file permission can communicate with network permission app

[OfSanguineFire]

On Graphene, if you deny network access to the sandboxed Play Services, it cannot transmit data to Google. But does Play Services cache all that privacy-invasive data, so that if you switch on network access at some point in the future, Play Services will upload it as soon as it gets a chance? If so, seems like a failure of GrapheneOS's model.

[cubesnooper]

Yes, if the worry is that an app could offload data via the network, then turning off the network only provides a privacy benefit if the network stays off. That’s why the recommendation is to run Google apps in an isolated user profile, so they have no opportunity to collect data in the first place.

[OfSanguineFire]

But even under an isolated profile, wouldn’t Play Services still have access to your IMEI, phone number, location and sensor data? That would seem to completely deanonymize the user regardless, if not to the app developer than at least to Google.

[cubesnooper]

> IMEI

According to the GrapheneOS FAQ: “As of Android 10, apps cannot obtain permission to access non-resettable hardware identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial numbers and subscriber IDs.”

> phone number

I don’t think it has access to this.

> location

You can turn off location permissions. Spoofing location (so the app doesn’t know it has no permission) is a planned feature but with no ETA.

> sensor data

You can turn off sensor permissions alongside other app permissions. This is another toggle present in GrapheneOS but not stock Android.

[kenmacd]

As much as I'd love to run GrapheneOS—and in the context of the original post—I just can't bring myself to willingly give the Google ad-machine my money. I keep hoping another manufacturer will step up and drive support for their devices.

[jqpabc123]

I keep hoping another manufacturer will step up and drive support for their devices.

I wouldn't hold my breath. Mainline hardware manufacturers have little incentive to support this.

e/OS is a well rounded, compromise alternative with much broader hardware support. I use it with an inexpensive Moto 5G Ace.

https://www.motorola.com/us/smartphones-motorola-one-5g-ace/...

[_rdvw]

/e/OS is not well rounded.

It is currently shipping Chromium Browser/System WebView from December of 2022 with 265 known security issues: https://divestos.org/misc/ch-dates.txt

Users cannot change the system webview, Android only allows pre-included ones as it gets directly loaded into the process space of all apps using the WebView widget.

And it still makes many connections to Google and includes proprietary Google binaries and downloads more at runtime: https://divestos.org/misc/e.txt

Disclosure: DivestOS is my project.

[kenmacd]

Thanks, I should take a look. I've also been meaning to try DivestOS.

I'm certainly not holding my breath on more GrapheneOS support, as so few people care. I'm not entirely sure it'd be the right fit for me anyway. I'm currently using a microg setup with lsposed so I can patch out some junk in modern apps (like Outlook trying to be device admin), and this kind of hooking is not something GrapheneOS is interested in (a feature request I opened a while back: https://github.com/GrapheneOS/os-issue-tracker/issues/284).

[pyaamb]

I love this. I wish for these patterns to be available more widely.