Closed Bug 1469502 Opened 3 years ago Closed 2 years ago
Remove permissions along with site data
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.)
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.
Depends on: 1460768
Priority: -- → P3
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?
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.
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...
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...
(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 :)
(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.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
Component: Preferences → Data Sanitization
Product: Firefox → Toolkit
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Status: REOPENED → RESOLVED
Closed: 2 years ago → 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.