1469502 - Remove permissions along with site data

Status: RESOLVED WONTFIX

(Toolkit :: Data Sanitization, enhancement, P3)

Description

[Anne (:annevk)]

Whenever a user removes site data, we should also remove permissions. Otherwise a site that uses permissions will have at least 1 bit of data left indicating that the user visited before.

Note that user credentials are different and should not be erased without the user asking for it explicitly.

(This was discussed at the most recent San Francisco All Hands.)

Comment 1

[Johann Hofmann [:johannh]]

The site data manager will need to be converted to the new ClearDataService anyway, which I probably need to do in bug 1460768, so blocking on that one.

Comment 2

[Thorin [:thorin]]

Will this be behind a pref? Because I can see a lot of annoyance from losing site permissions exceptions: eg prompts for geo, exceptions for canvas in privacy.resistFingerprinting, even user's zoom settings.

There has to be a distinction between web data (localStorage, IDB, cookies, cache, service workers cache, maybe even history) for tracking vs non web data, such as site settings.

Or have I misinterpreted what is proposed here?

Comment 3

[Anne (:annevk)]

You have not. The problem is that the permission itself can be used for tracking and will make any fingerprint they have on you much more definitive.

Comment 4

[Johann Hofmann [:johannh]]

I understand the concern. Permissions are not set by the website, but rather by the user. The fingerprinting possibilities are quite limited considering that the user needs to explicitly grant permission first. I think this really depends on which UI it will be implemented in. I think it's fine to make deleting individual sites in the site data manager clear permissions as well, while the "Clear History" menu probably should have site data and permissions as separate options...

Comment 5

[Johann Hofmann [:johannh]]

Also note that the only thing enabling this fingerprinting without notifying the user is the permissions API, so maybe it's a fault in that API as well...

Comment 6

[Thorin [:thorin]]

(In reply to Anne (:annevk) from comment #3)
> You have not. The problem is that the permission itself can be used for
> tracking and will make any fingerprint they have on you much more definitive.

While I appreciate that, the problem is that users have explicitly set these permissions to work in their setup - they were so annoyed by prompts, or they need the website to work, that they went to the trouble of "fixing" it (see example of a govt tax website below). All this will do (if enforced and not behind a pref or UI setting), is make them have to add their site permission exceptions time and time again as needed: eg every session if they clear on close, when an extension clears cookies(?), or containers using contextualIdentities.remove(?), or when all PB mode windows close, or manually clearing (ctrl-shift-del, or using the Site Data UI). In which case the website still gets the new settings - site permission exceptions as a fingerprinting attack vector is not static - that's what the exceptions mean, it can vary from site to site.

Consider that users can change the *default* value (cookies, camera, microphone, location, notifications, popups - all from the UI), and consider the growing number of users concerned with privacy and tracking and Mozilla's own focus on making this more accessible (eg new permissions UI, new Site Data UI). This allows a setup where users can default deny and then whitelist, and users can easily clear data. Now picture an ever-increasing vast horde of users who are concerned with privacy, and regularly clear data. You are effectively breaking their "fixes" for making websites work.

I block all cookies, for example, and have about 50 entries for allow and allow for session. I have a couple of canvas exceptions, and so on. These all took time to curate, I have no master list of these. If these all get wiped, then I lose it and have to start over. The 500 or so websites I visit regularly all work flawlessly, and you want to break a bunch of them every time I clear local persistent WEB data!

Can you see how incredibly annoying this will be to almost **every** user - they set permission exceptions to make things work. Consider a client of mine the other day, due to website changes on the govt tax website, I had to apply a site popup exception. Now picture that client getting frustrated every time he tries to access his business tax records and make filings etc.

Also note that "site permissions" is a separate item in `privacy.cpd` and `privacy.clearOnShutdown`. It can *already* be bulk cleared. Please do not enforce clearing site permissions with site *web* data - they are two different things. It needs a pref and a UI option if you want to go down this road.

I also do not buy the fingerprinting attack vector here at all
- One: as a persistent data item on the local machine (hacking etc), this can already be disabled (permissions.memory_only), and can already be cleared manually and on close.
- Two: as a web tracking FP mechanism: you already allow a number of permutations of settings via the UI for an end user's "permissions FP", so not everyone will be the same by default. And if an end user made exceptions, if anything, that would obfuscate cross site tracking.
- Three: there are already so many other FP mechanisms (ignoring the obvious): for example, a website can easily determine your cipher suite (and there's nothing you can do about it). Or it can easily determine your media capabilities. Would you also propose that all these *settings* get reset when "clearing data". Permissions are not data, they are settings!

Sorry for the long post :)

Comment 7

[Thorin [:thorin]]

(In reply to Anne (:annevk) from comment #0)
> Whenever a user removes site data, we should also remove permissions.
> Otherwise a site that uses permissions will have at least 1 bit of data left
> indicating that the user visited before.

If you are talking about local machine security (hacked, computer forensics) then this is true. If you are talking about a website working out bits for entropy - this is not true (indicating that the user visited before). A user can change default settings - they do not need to visit a site firsthand. An extension can block a cookie, without needing to visit the site before. A user can allow a prompt for geo (so that bit of entropy would differ from the default "ask") on their first visit.

Bake this into PB mode by all means (if its not already), because PB mode is all about persistent DISK data. This does not belong in normal mode IMO. Think of the 100 million plus users and wiping all their hand crafted site settings (yes hand crafted, they had to be added manually). That's all I'm saying.

Also, leave the FP'ing up to the Tor Uplift guys: get Tom Ritter, Arthur Edelstein in here if need be. `privacy.resistFingerprinting` already covers persistent zoom settings. Note: RFP blocking geo will be reverted (Bug 1441295), so they're happy with the default "ask" and allowing per site prompt overrides, although you added the ability to change the default (FF58: `permissions.default.geo`), so that may need to be rethinked.

Comment 8

[Johann Hofmann [:johannh]]

I think I follow the concerns that permissions are an explicit user choice and the fact that a permission for the site is present does not make an extended fingerprinting vector for non-resistFingerprinting use cases.

If the permission is directly queryable this is a flaw in the permissions API that we might want to address separately.

Comment 9

[Thorin [:thorin]]

If the permission is directly queryable this is a flaw in the permissions API that we might want to address separately

re: Permissions API [1]

for (const a of [ 'accelerometer', 'accessibility-events', 'ambient-light-sensor',
 'background-sync', 'camera', 'clipboard-read', 'clipboard-write', 'geolocation',
 'gyroscope', 'magnetometer', 'microphone', 'midi', 'notifications', 'payment-handler',
 'persistent-storage', 'push' ]) navigator.permissions.query({name:a}).then(e => 
console.log("permission for", a, ":", e.state)).catch(console.log);

Currently only geolocation, notifications, push and persistent-storage return values and might be worthwhile as FP'able metrics. See [2]: geolocation is a good metric (at the end of the languages/locale section). persistent-storage (in the cookies/storage section) always returns the prompt reply (or stored site exception) and is not a stable metric.

So yes, some permissions are directly queryable if someone wants to open a ticket for it

[1] https://developer.mozilla.org/en-US/docs/Web/API/Permissions/query
[2] https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html

Comment 10

[Thorin [:thorin]]

pinging Ethan so someone from Tor Uplift is aware

Comment 11

[Ethan Tseng [:ethan]]

This is both a disk hacking and fingerprinting issue. Let's reopen this bug to keep track of it.

Comment 12

[Johann Hofmann [:johannh]]

I don't see how this bug is a problem for Tor browser. Permissions are not stored on disk in Tor (if they were it would be another bug, but not this one). Ethan, can you please elaborate how this is relevant to Tor?

Comment 9 does not present an argument to re-opening this bug. As I said in comment 8, I'm aware that permission states are queryable but this should be solved on the Permissions API level, either by discussing at the spec level or (more likely) by updating permissions.query to always return "prompt" when RFP is enabled.

If these are issues of relevance for Tor browser please file them separately, I'm 99% certain that this bug is not relevant to you.

Comment 13

[Ethan Tseng [:ethan]]

Johann, I didn't think of it clearly enough while re-opening the bug. Thanks for the clarification.

Comment 14

[Thorin [:thorin]]

(In reply to Ethan Tseng [:ethan] from comment #13)

Johann, I didn't think of it clearly enough while re-opening the bug. Thanks for the clarification.

As Johann said "... or (more likely) by updating permissions.query to always return "prompt" when RFP is enabled", which is why I pinged you, to possibly create a ticket. While it doesn't affect Tor Browser (site permissions are session only, and they can enforce their defaults etc), it does affect Firefox

If you create a ticket, cc me in (if you remember), thanks