Open Bug 1429865 Opened 2 years ago Updated Last month
Allow managing canvas permissions in about:preferences when resist
Fingerprinting is on
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20100101 Steps to reproduce: Firefox 58.0 b14 on linux (debian unstable). "privacy.resistFingerprinting" is set to true. Actual results: Starting with b14, visiting just about any website (such as github) now prompts for canvas readout permissions, however I see no way to set a default preference for all website so I can always supress (or always allow) the preference. Expected results: I think the UI and feature here is broken in it's current form. This fingerprinting technique has become so ubiquitous that firefox is late to the party here. I cannot have an annoying prompt for almost every website I visit. Showing the urlbar icon is fine if readout is being requested, as long as there's no prompt. I should be able to set a global preference, and then click there to manually override just the website. I also question the technique used here: returning a zero result will actually increase your entropy as opposed to decrease it, due to the fact that canvas readout is allowed by default on any other browser (or just by default settings). If privacy really matters, the readout should be a stable pseudo-random content, like CanvasBlocker already does. Currently, this behavior is detrimental.
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Firefox 59.0a1, Build ID: 20180115100056 I can reproduce the described behavior on latest Beta 58.0b16 and latest Nightly (59.0a1) build on Windows, Linux and Mac. But, this seems to be more of an enhancement than an issue in my opinion. However, I am assigning a component to this issue in order to involve the development team and get an opinion on this. Johann, can you please look over this?
Severity: normal → enhancement
Component: Untriaged → Canvas: 2D
Product: Firefox → Core
The UI is definitely an enhancement request. But, as noted, the actual underlying implementation has privacy implications as well.
I think generally this is a good idea, considering that the prompt can be annoying. We could do it the same way that other permission prompts can be denied by default in about:preferences (in the Permissions section), the downside of that is that it wouldn't show any prompt at all in its current state. Making the prompt show in minimized state would be a bit of extra effort (but shouldn't be too hard). I don't think we have anyone resourced to work on this at the moment. I'll still leave it as P3 and move it to the front-end category, since this is really more about the UI than the Canvas implementation.
Status: UNCONFIRMED → NEW
Component: Canvas: 2D → Site Identity and Permission Panels
Ever confirmed: true
Product: Core → Firefox
Whiteboard: [gfx-noted] → [gfx-noted][fingerprinting]
Please don't post me-too or plus-one comments in this bug. This bug has been acknowledged and somebody will work on it in due time. I'll hide the previous comments to de-clutter this bug a bit.
I had fingerprinting resistance enabled before and only learned in this bug that it wasn't yet a default. Sorry for that. That said, wavexx has expressed what is needed better than I have. Is there a tracking bug for coalescing all those permission prompts into one icon in the urlbar? The wider web is a hostile place, and I prefer to open access when I miss a feature, basically opt-in/explicitly. To avoid local and remote abuse of browser state many of us clear everything on browser exit. So putting these into site data permissions isn't sufficient. A global deny which then can be gradually opened on each visit to some interactive page is the way to go.
For reference: Bug 967895 (canvas prompt) + Bug 1413780 (site permission) ToDo: (to get the ball rolling) 1. Add a `preferences.default.canvas`  however, it is tied to privacy.resistFingerprinting, so perhaps - `preferences.default.resistFingerprinting.canvas` (in keeping with the current naming convention) - `privacy.preferences.default.canvas` (all RFP prefs start with `privacy`. I favor this one)  Bug 1379560 & 380637 introduced 5 `privacy.default.*` prefs relating to the PageInfo>Permissions panel: 0=always ask 1=allow 2=block. In the case of the pref for overriding firefox shortcut keys, where the only options are allow and block, 0=allow. 0 is always the default. 2. For consideration once this ticket is done: When privacy.resistFingerprinting = true, display Canvas under Privacy&Security>Permissions (site management) Tom, can we get this tagged as part of the tor-uplift? I would consider canvas prompt fatigue as a barrier to user uptake for when you (hopefully) ship in 60
Canvas fatigue is definitely an annoyance; but I actually think the best first thing to do is Bug 1376865 - it should reduce the popup in an overwhelming amount of cases and has no UI/UX components so it's easier to build. I don't know anything about it, but apparently there is a IsHandlingUserInput() function that might make it pretty easy to implement actually. In any event, I don't think this will get done for 60; it hasn't come up in any of the Tor Meetings as a priority, and it is a concern about just getting the things we definitely want in 60 done. I am hopeful whatever Canvas improvements we make would be backported to TB though.
Duplicate of this bug: 1436326
Component: Site Identity and Permission Panels → Preferences
Summary: Allow to set default preference for canvas permissions when resistFinterprinting is on → Allow managing canvas permissions in about:preferences when resistFingerprinting is on
Whiteboard: [gfx-noted][fingerprinting] → [gfx-noted][fingerprinting][fp-triaged]
You need to log in before you can comment on or make changes to this bug.