What does "never for this site" for the canvas warning really mean?

When I get an html5 canvas warning in Tor Browser, it suggests that I pick "never for this site".

To me, the word "never" implies that Tor Browser is writing down my answer, and it will use that answer forever after. Like the "permanent exceptions" for SSL certs.

On the other hand, my understanding of Tor Browser behavior is that it wouldn't write it to disk, so my choice would be lost on the next browser reset or new identity click.

There's a contradiction here. I'm assuming the second one is right. Is there a better phrase we can use than "never"?

added component::applications/tor browser owner::tbb-team parent::30037 priority::medium resolution::worksforme severity::normal status::closed type::defect ux-team labels

Tor Browser with its default settings behaves as you are expecting: new identity/browser restart blows your canvas related settings away. Not sure what a better phrasing would be "Not for this session" maybe? Or "Not until I close the browser"/"Not until the browser gets closed"? (We are sort of closing the browser during New Identity as well, so this should not be a problem)

One thing to keep in mind is the case where users enabling disk history. It could be that "never" then really means "never". It's not nothing we really support, but hey, still worth testing for I guess.

"Never for this session" would be my first choice.

But I'll also note that Linda was excited on other tickets to help with user-facing phrases like this.

Though hm, that doesn't make it clear that it is a site-specific choice.

More thinking required.

Raising awareness for the UX-people. FWIW: We had requests as well to add an "not ever" option (#18027 (moved)). Might be time to give the whole warning dialog a bit more thought: What options do we really want to have there? What is meaningful to users at all? And how do we convey the options? And of course: Does it make sense at all to have such a doorhanger given warning fatigue etc.? And if not, what could/should we do instead?

Trac:
Keywords: N/A deleted, ux-team added

As a Tor Browser user i always ignore the warning (the warning fatigue has set in a long time ago) and click on the webpage to make it disappear. With this behavior I'm assuming Tor Browser does the (IMO) right thing by disallowing image data extraction through the canvas by default.

I'm treating the canvas protection like NoScript. As i mostly run Tor Browser on the highest security level I assume everything is disabled it by default. When i notice something breaking i optionally enable JavaScript or lower the security level. I've never disabled the canvas protection through the warning dialog and I'm unsure whether lowering the security level automatically disables it.

Remove the f*cking popup without questions! :) You don't ask about disabling your other security/privacy/etc protections. Why is this a special case?

I think the NoScript analogy is a good one. Other things to consider: how often do people need to allow canvas data extraction for a site to work correctly? And do users expect the browser to remember these kind of permission decisions across sessions (and how do we weigh that against not writing to disk)?

Replying to mcs:

I think the NoScript analogy is a good one. Other things to consider: how often do people need to allow canvas data extraction for a site to work correctly?

The most common use I've seen is a site that writes emoji, then looks to see if the font supports them, and enables image fallbacks if it does not. In this case, Tor Browser users should be fine (albeit slower) with the image fallbacks.

And do users expect the browser to remember these kind of permission decisions across sessions (and how do we weigh that against not writing to disk)?

No, I expect Tor Browser to forget everything when I restart or get a new version.

Even better: when users allow canvas image extraction, does it actually work?

I've seen sites where I've allowed image extraction, and they still fail. Maybe this is because image extraction doesn't work in high security mode even when allowed?

I also never touch the popup for fear of it recording a preference. Why not randomize the low bits of the pixel values to avoid profiling?

Trac:
Username: tokotoko
Cc: N/A to fdsfgs@krutt.org

Replying to gk:

Raising awareness for the UX-people. FWIW: We had requests as well to add an "not ever" option (#18027 (moved)). Might be time to give the whole warning dialog a bit more thought: What options do we really want to have there? What is meaningful to users at all? And how do we convey the options? And of course: Does it make sense at all to have such a doorhanger given warning fatigue etc.? And if not, what could/should we do instead?

I agree that we should give the warning dialogue more thought. Even if it does catch user preferences, it would be tiring to set it up every single time you started tor browser. The better thing to do is to not show the popup so frequently to users.

That being said, it is way better to users to ask them with good context, so I think showing a popup when they first encounter it is a good thing. (i.e., asking about the canvas warning at a relevant time, and not during setup, will give users a better idea about what they are saying yes and no to. It's kind of like if I asked you what you wanted to sit a the right side or left side of the table a party a month from now without telling you who's sitting on each side, what the room looks like, etc.)

Until we get that going, I think that changing the text to "not for this session" is a good band-aid fix.

I think that changing the popup use to record preferences + onboarding users correctly and setting expectations that tor browser erases all data when you close it + changing wording is the best scenario.

Is this ticket obsolete, now that Firefox itself has developed a (better) interface for this topic?

I think your question is obsolete, yes.

Trac:
Resolution: N/A to worksforme
Status: new to closed

Trac:
Parent: N/A to #30037 (closed)

closed

mentioned in issue #24237 (moved)

mentioned in issue #30037 (closed)

moved to tpo/applications/tor-browser#22396 (closed)