So I commented on this to share why this is important. On my last comment, I criticized GOS for marking this issues as priority-none. I was polite, and there was no violence or any attacks.
Guess what ? My comments were deleted, as well as comments from someone else (pointinig out that this could fingerprint you across profiles due to the unique update time for system apps.).
Furthermore, the issue was locked.
I am now concerned that GrapheneOS doesn’t care about Privacy but only Security.
This reads more like you want to stir the pot regarding GrapheneOS but anyway. I’m not sure whether GOS promises to allow you to run hostile apps on the device without issues, but the ability to use multiple profiles to compartmentalise your stuff is certainly compromised if an app can effectively and easily fingerprint someone
There’s no claimed protection against fingerprinting by native apps by Android or GrapheneOS. Our FAQ on non-hardware identifiers explains how fingerprinting is possible. None of this is a bypass for any kind of isolation. Web sites can successfully do fingerprinting in many ways in a far more restricted/limited environment. Even the most strict anti-fingerprinting features deployed for web browsers don’t prevent doing it via JavaScript-based timing measurements to measure performance along with other side channels. Native apps are inherently able to fingerprint in many different ways and it’s unrealistic to bring it to the same level as web pages without running apps in a standardized virtual machine with more limited functionality than they currently have available. There has only recently started being any significant progress on mitigating fingerprinting for the web and the same thing has barely begun for native app environments. The difference in the starting points is also significant. For example, access to information about battery life is relatively new in web browsers and there’s limited list of similar APIs but access to far more than that has always been available to native apps. Frequently Asked Questions | GrapheneOS Frequently Asked Questions | GrapheneOS
In the much longer term, support for running apps in virtual machines is planned. There will be a much more limited set of functionality available which will gradually need to be filled in and there can be far more toggles. This is the only way of hiding many things like the device model from apps by having the same virtual machine image builds across devices and supporting using a standardized screen resolution, etc. They could still do timing/performance-based fingerprinting which is also doable by websites. This can also theoretically be used for communication between apps and even web sites. The performance impact of CPU and other resource usage by an app or web site can be observed by others, so there’s inherently a potential for data leaks and communication through this approach, not only fingerprinting the hardware and OS based on performance of various functionality.
I am not backing the anonymous useraccount GrapheneOS’s handling on queries, but if you search through GOS forum, you will find plenty of similar threads, and GOS team did properly reply at that time.
Edit: Changed thread title to make it more precise and neutral.
I don’t. But yeah I am a bit angry that they delete comments on issues just to not look bad.
When you claim to be “private” I think you should be more upfront that you don’t prevent fingerprinting. Any browser that would claim to be private but doesn’t fingerprinting would be laughed upon.
This is a really bad argument. First this is clearly what-aboutism as browsers like Firefox and Brave have really strong anti-FP. Sure, the performance thing might identify you, though I am not sure how just the perf of your device will identify you, as it probably vary over time. Plus running this is quite sosphicated, the real threat isn’t the one shady website that has super-advanced FP, but the 100 that do naive fingerprinting.
Well, you have to start somewhere. It is possible to increase the barrief of them doing so, which is currently basically 0. Hiding apps info + precise storage + charge cycles, and you already greatly reduce it.
Also, this isn’t just about fingerprinting, there are others concern that I share here.
Just to be clear, those response in quote were from GOS Team back in 2023, not my words.
So
GOS is already much more privacy friendly than stock OSes out-of-the-box, yeah it is not perfect, but it is, to my knowledge, already the best option and keeps improving. So I think this comment is not quite appropriate.
I think GOS’s very lengthy FAQ does a very good job at explaining GOS’s capabilities and limitations, though I have to say I did need to do some extra reading in order to understand the FAQ.
I try to stay on topic so won’t add too much here, but base on the bar you set for GOS, only Tor might meet your requirement, and even thats with a lot of caveats.
I don’t code so I don’t know how it exactly works. But I would imagine poorly thought out and implemented anti-fingerprinting measures would either break tons of apps, or makes you more unique, or both. Just like browser anti-fingerprinting.
They’ve marked it with the feature tag, which means they will likely implement it at some point in the future. As far as I understand, the ‘priority’ tags exist to give some idea of what they are currently focusing their limited resources on.
If you have more to add about the feature then an issue tracker is the appropriate place; otherwise, you’re in the wrong place. Issue trackers aren’t really meant to be an endless stream of users demanding a project follow their priorities (especially when it’s a completely free open-source project).
It’s pretty silly to imply that GrapheneOS doesn’t care about privacy when they have plenty of such features like the soon-to-be greatly expanded scopes features, sandboxed Google Play services, location indicator, etc.
Finally, moderation decisions taken by other communities like the GrapheneOS community are thoroughly beyond the scope of this forum. They will always be entitled to make those choices in their communities and the fact that they develop a privacy and security focused OS does not mean their moderation decisions relate to those subjects.
The whole point of GrapheneOS is privacy AND security. So your conclusion is not fully correct as there is no privacy without security.
That being said, everyone can put as much thumbs down as they want, GrapheneOS handling of public interaction is not the best… That is a fact. So, my advice is: either you trust the team and continue using the OS, or just move on to something else if you feel you can´t.
I would agree my last comment may have been a bit ouf-of-subject and could merit removal. But the others were useful, especially in clarifying what/how the issue could be dealt with.
Point taken,I could have been more nuanced.
Soon
I personnaly dislike the namming of “sandboxed Google Play Services”. It is sandboxed -like every other app- and in this sense it is different from stock OSes. But it isn’t really sandboxed in a practical sense, as GPS works by communicating with all other apps, so it can be a vector of tracking. There is no way around this, but it isn’t sandboxed either - a sandbox often refers to an environment disconnected from others. I know this is the name Android uses, so maybe I am overblowing it.
Absolutely, and this is case there is no conflict between them.
GrapheneOS is the best we’ve got currently, so I will stick with them.
Anti-fingerprinting doesn’t make you unique, in that sense you can look at the Arkenfox wiki.
Apps know you are using GrapheneOS anyway, so any anti-fingerprinting implemented by GOS measures cannot FPing you further.
It will not break apps if you return “falsified data”, so you would return rounded values (any install/update time would be year-month-day-00:00, any storage would be dd.00G). Same for charge cycles, just return with a diminished precision, you round to the nearest 100, starting at 20 (47 will be 20, 53 will be 100, 149 will be 100, etc).
Not saying this would be easy to implement, but not impossible.
As I said, I am more concerned about the 100 sites (or apps) that do naive fingerprinting, than the few sites (or apps) that have very advanced fingerprinting.
In this regard, Firefox (properly configured) and Brave, are sufficient for naïve FPing
Sandboxed apps don’t have special or privileged access to the system. They can’t access data they haven’t been given permission to. Inter Process Communication (IPC) isn’t a security hole in the sandbox but required basic functionality, available not only to Google but to all apps & requiring mutual consent.
The way around this is user profiles
All 3 concerns you list have the specific mentioned attack vector (app list) mitigated by using user profiles. They are also possible to detect in other ways = false sense of security.
But an incomplete implementation doesn’t make you “less unique”, so to say.
Changing from unique to “less unique” = still unique. Should limited development time be spent on work which won’t be useful until very significant effort has gone into it? Until then it’ll only give a false sense of privacy = privacy theater.
GrapheneOS has ~300K users. Let’s say they all installed GrapheneOS on their device in the past 3y. If these values were to be ‘protected’ as above:
YYYYMMDD-0000: 1095 possible values
Storage dd.00GG: 100 possible values (if you actually meant a ceiling of 99GB, else up to 1000 possible values)
Charge cycles: no upper limit but let’s say 200 cycles is reasonable for this example? So 3 possible values, although many will have more.
The spread of users won’t be even, but that’s 328K possible fingerprinting buckets from those 3 ‘protected’ values alone (328K > 300K = unique). And that’s assuming they’re not looking at device model, OS update, timezone, network country code or any other similar global settings or data points mentioned.
And that’s not taking into account values changing over time. Preventing cross-profile fingerprinting of persistent apps isn’t the same as fingerprinting ephemeral web browsing. Not even going to mention same-profile fingerprinting…
