Progressive Web Apps on the other hard are actively restricted by the browser sandbox and are ganerally a preferred solution from a privacy perspective.
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.
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.
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.
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.
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.
microG handles most of the routine access to Google services that I need.
The creator used to post a lot about it here:
App with file permission can communicate with network permission app
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.
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/...
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.
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).
[1]: https://arstechnica.com/gadgets/2023/09/googles-widely-oppos...
(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.)
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.
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.
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.
I cover this in depth more here: https://divestos.org/pages/browsers
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.
PWAs don't have this problem.
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.
What if I use something like AdGuard to block reqs ?
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.
Not just that, services could end up using the same IP across providers: https://blog.cloudflare.com/addressing-agility/
[0] https://github.com/TrackerControl/tracker-control-android
"all your data"? What data exactly? My contact list? My gallery?
https://www.xda-developers.com/android-permissions-bypass-pl...
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.
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.