Long story short: There is nothing that actually prevents an installed app from collecting all your data.
Progressive Web Apps on the other hard are actively restricted by the browser sandbox and are ganerally a preferred solution from a privacy perspective.
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.
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.
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)?
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.
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.
> 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.
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?
My DivestOS features both the GrapheneOS and LineageOS implementation, and I document the former as block and the latter as "data restriction" (eg. to simply block over cellular) as it cannot guarantee a real block.
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.
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.
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.
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.
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.
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.
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.
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
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).
Except the only difference is that PWAs in Chrome's "sandbox" just collect data for Google, and Google alone. Do you believe they do it for the greater good?
Google probably gets data both within the sandbox and outside the sandbox. But outside the sandbox, probably so do parties with worse privacy practices than Google, such as actually selling your data instead of just letting their internal ad systems use your data so that advertisers can reach you with targeted ads, or such as not letting you as effectively delete your data as Google does.
(Disclosure: I have worked for Google in the past, but not for over 8 years, and I’m certainly not speaking for them here. My Google job never included anything relevant to this comment, except doing roughly 1-2 years of standard SRE/devops/sysadmin work for a now-decommissioned acquired product in the publisher-side display ads yield management space, ending roughly a decade ago.)
> just letting their internal ad systems use your data so that advertisers can reach you with targeted ads
Your distancing yourself from your former employer's practices is appreciated but Google monopolizing click and all other web usage data isn't any better than keeping those for themselves from an antitrust PoV (as opposed to selling the data under FRAND terms).
There's no way around taking Chrome development and monopoly influence on web standardization away from Google as one outcome of ongoing antitrust lawsuits.
> Your distancing yourself from your former employer's practices is appreciated but Google monopolizing click and all other web usage data isn't any better than keeping those for themselves from an antitrust PoV (as opposed to selling the data under FRAND terms).
I’m comparing practices from the perspective of privacy, not antitrust, since that is the frame in which we were discussing, and with which the original submitted NOYB article was concerned.
I don’t like monopoly power in the advertising industry any more than you do, and Google is not an exception to that. But I don’t want the fix to any Google advertising monopoly to be forcing them to share user data on FRAND terms. Not only would that likely violate privacy law in Europe and elsewhere in the world, it would reduce my data’s privacy protections to what results from the worst privacy practices among anyone who buys the data from Google. Yes, that’s far worse than what Google currently does.
> There's no way around taking Chrome development and monopoly influence on web standardization away from Google as one outcome of ongoing antitrust lawsuits.
If authorities like those in Europe or the US decide that antitrust violations by Google warrant those remedies, I have no personal objection. But I would object to any anti-monopoly measures that effectively destroy the privacy of the profile Google has built on me, such as mandatory FRAND licensing of that data. At least I can delete the data when it’s just the one data custodian, and one which properly implements and tests data deletion process more than many companies.
This is why I don't use default Chrome or stock Androud. They're both apps from a known privacy invader.
But even if you do, these are restricted from wholesale collection of data like your contacts by marketplace and public relations pressures and concerns that smaller junk app vendors don't have.
e/OS and Brave browser. I generally avoid Google's Play store and install most apps from Aurora and F-Droid. Aurora provides a privacy report that you can review before installing an app.
> There is nothing that actually prevents an installed app from collecting all your data.
Uhm, false? Unless by "all your data" refers to "what you do in the app" + IP address + phone model, on the iPhone nothing else is accessible by default. All that info is also available to any website you visit, so PWAs are not special in this regard.
The easiest way for a bad actor to get access to personal data on iPhone or Android is to simply ask for it --- create a junk installed app with some quasi-plausible excuse for requesting it. There is no restriction on what can be done with the data once the request is granted.
Granting a random app access to all your private data after they request access is very different than "There is nothing that actually prevents an installed app from collecting all your data."
I think the only sensitive APIs not available in the browser are calendar and photo gallery access, but PWAs have otherwise access to Contacts, GeoLocation, Cameras, Microphone, Clipboard, and even the FileSystem.
Maybe Android apps do suffer from the problem you’re describing, since permissions are granted lumped together at install time, but on iOS all permissions are optional just like in the browser.
The only reason stuff like PiHole / AdGuard DNS and many others work is because the service vendors have not bothered unifying ALL the network requests their service needs under a single domain. The one and only reason we can use those privacy-enhancing solutions is because the vendors are sloppy.
The moment your favorite app starts using only `your-fav-app.com` domain for everything, ads and sending out your private info included, you are toast and you'll need a MITM proxy or any other on-device-network-payload-inspector-after-decryption-has-taken-place to save yourself. (So maybe Adguard's client app, I presume? But haven't ever tried.)
Maybe Privaxy[0] will help -- haven't tried it yet and I got no time and energy for it for the moment, sadly, but DNS-level blocking in particular is just waiting for a few more resourceful vendors to do the right thing for their interests, and we're disarmed.
Your data can easily be sent to an IP collection point that is not on AdGuard's list. DNS blockers are better than nothing --- which is a pretty low bar and easy to jump over.
That research was conducted on the 2018 version of the OS, and also at a time when Google Play's distribution agreement was much more relaxed (close to zero app checks).
As far as I know, most (if not all) of the concerns shared have been addressed in the following 2 years, so I would assume that this is not an issue anymore in 2023 - or at least not as severe. I believe that new loopholes exist, but this one seems outdated to me.
The data described in that article (Eg MAC Address) has virtually zero overlap with the kind of data GP mentioned (contact list, gallery). Most people only care about the latter.
btw "The researchers discovered that the Shutterfly app was accessing the location tags of photos' EXIF metadata. All that's required is the READ_EXTERNAL_STORAGE permission" sounds ridiculous. If you grant permission to read entire files, of course the app can read metadata.
Progressive Web Apps on the other hard are actively restricted by the browser sandbox and are ganerally a preferred solution from a privacy perspective.
https://web.dev/progressive-web-apps/