1429865 - Allow managing canvas permissions in about:preferences when resistFingerprinting is on

Status: NEW

(Firefox :: Settings UI, enhancement, P3)

Description

[wavexx]

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.

Comment 1

[Cosmin Muntean [:cmuntean], Ecosystem QA]

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?

Comment 2

[wavexx]

The UI is definitely an enhancement request.

But, as noted, the actual underlying implementation has privacy implications as well.

Comment 4

[Johann Hofmann [:johannh]]

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.

Comment 5

[u474838]

(In reply to Johann Hofmann [:johannh] from comment #4)
> 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

I don't want to be a party pooper, but it's bad how 58.0 does it.

It's unfortunate that 58.0 was released with this, and it is very annoying.
Just navigate to github.com or reddit.com.

You cannot press Alt-N or Alt-A to make a selection.

You cannot make it go away via a setting.

It will show up once, or in the case of reddit, at least twice.

The safety improvement is nice, but this is like Vista-level UAC.
I'm almost inclined to hack it away or build an extension to intercept
the dialog until it's fixed.

> 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).

Disallowing canvas image capture is a good idea, if I can override the setting
via a urlbar icon on the left. Same for other permissions.

Come to think of it, can't I achieve the same (no popup by default) for mic/cam
access, as well? It's not annoying like the canvas popup since few sites ask
for mic/cam, but it sounds like the same mechanics are needed for that.

> 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.


True, but allow me stress this needs to be fixed in 58.x or people will write
extensions to suppress it.

Comment 6

[Johann Hofmann [:johannh]]

(In reply to Carsten Mattner from comment #5)
> True, but allow me stress this needs to be fixed in 58.x or people will write
> extensions to suppress it.

You realize this is behind a pref, right? It's there for a reason.

Comment 7

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to Carsten Mattner from comment #5)
> (In reply to Johann Hofmann [:johannh] from comment #4)
> > 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
> 
> I don't want to be a party pooper, but it's bad how 58.0 does it.
> 
> It's unfortunate that 58.0 was released with this, and it is very annoying.
> Just navigate to github.com or reddit.com.
> 
> You cannot press Alt-N or Alt-A to make a selection.
> 
> You cannot make it go away via a setting.
> 
> It will show up once, or in the case of reddit, at least twice.
> 
> The safety improvement is nice, but this is like Vista-level UAC.
> I'm almost inclined to hack it away or build an extension to intercept
> the dialog until it's fixed.
> 
> > 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).
> 
> Disallowing canvas image capture is a good idea, if I can override the
> setting
> via a urlbar icon on the left. Same for other permissions.
> 
> Come to think of it, can't I achieve the same (no popup by default) for
> mic/cam
> access, as well? It's not annoying like the canvas popup since few sites ask
> for mic/cam, but it sounds like the same mechanics are needed for that.
> 
> > 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.
> 
> 
> True, but allow me stress this needs to be fixed in 58.x or people will write
> extensions to suppress it.

To be clear, this behavior is not on in 58 by default. You have to enable a non-default, hidden pref.

While I'm very grateful to those who do, as it gives us fantastic feedback on what we need to improve, it also means the feature is still in development, and one should expect papercuts of varying sizes when using it.

Comment 8

[wavexx]

Although this is behind a pref, I actually disabled resistFingerprinting due to this behavior, so I share a bit of concern with Carsten.

In my mind though, it would be great if we could improve these permission requests for several other prompts.
One great example, is the permission prompt for web notifications. 

There is an increasingly number of website that simply asks for permission right when you visit them. Obviously, I didn't even see the website yet, so I will always deny, *unconditionally*.

So you try to go to the permissions section, and there is *no* way to set the default preference to *deny*.
End result: I simply disabled webnotifications entirely. I don't want to be spammed with requests on random websites I visit accidentally.

The right way to do it, in my mind, is a little badge on the left of the urlbar, like for the cookie readout prompt, which appears if a website happens to request some permissions which require user feedback. Canvas readout and web notifications would be the prime example: only if I'm really concerned with some website feature I will allow the feature, which otherwise should be disabled (and *not* prompted) by default.

I would argue all prefs (location, camera, microphone) should work like this, but so far only web notifications and canvas readout are being abused by random websites.

Although this spans a bit beyond the original report, try to consider this as a general UI improvement for prompt requests.

Comment 9

[Johann Hofmann [:johannh]]

(In reply to wavexx from comment #8)
> So you try to go to the permissions section, and there is *no* way to set
> the default preference to *deny*.
> End result: I simply disabled webnotifications entirely. I don't want to be
> spammed with requests on random websites I visit accidentally.

This was implemented in bug 1368744.

Comment 10

[Johann Hofmann [:johannh]]

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.

Comment 11

[u474838]

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.

Comment 12

[Simon Mainey]

For reference: Bug 967895 (canvas prompt) + Bug 1413780 (site permission)

ToDo: (to get the ball rolling)
1. Add a `preferences.default.canvas` [1] 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)

[1] 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

Comment 13

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

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.

Comment 17

[wavexx]

I still experience the prompt very frequently on FF68, despite Bug 1376865.
This frequently happens during/after logins as a result. One offender is definitely amazon.

I'd love to keep resistFingerprinting on, but it seems that most of the functionality can be offloaded to extensions which have a superior UI so far.

Comment 18

[jwms]

It would be nice if the effect was that when you go to the padlock icon on a site, click the right arrow and then More Information, and the Permissions tab, that we know that you are controlling the per-site exception to Extract Cavas Data. Similar to how the other per-site permissions are set. That way you have both the default permission controlled under Privacy & Security and then per-site exceptions to the rule in its typical spot.

Comment 19

[Daniel Roi]

I also experience the prompt frequently with the latest Firefox and would appreciate if managing the prompt was allowed in about:config