Re: [w3c/permissions] A new permission for canvas data (#165)

First off, yes, getting canvas to be unfingerprintable is definitely desirable. But we've known about this problem for years and no browser has actually done it. And as long as browsers drive towards GPU-based graphics acceleration, it seems likely that it won't happen. Convincing people to go backwards to software rendering (which addresses some but not all all issues) is... not an easy thing to convince people of, at least for a default mode.

I'm definitely willing to do the spec work, yes. My suspicion is that documenting the Privacy Considerations (and why it's difficult to make canvas unfingerprintable) will be an extended effort. Mostly because I'd like it to be as complete as possible, and it's likely there are even more concerns that have come up since this was last investigated years ago that will take some time to discover.

---

As for the canvas spec. As Isis noted, because Canvas uses synchronous APIs the current behavior in both Tor Browser and Firefox is... cruddy. Prompts get thrown all over the web (see the emoji note) even when fingerprinting isn't occurring; and not all websites can handle the non-standard, unexpected situation of "The browser just lied to you with a blank canvas, but if you call the API again it will work this time!" For the ones that do, it's more luck than robust design.

The ideal situation would be for the APIs of concern to be Promise-based. I am not asking for that in this request. I am basically asking for a string allocation to standardize the current cruddy behavior. I'd be willing to update the Canvas spec to document this possible behavior, but it's definetly a hack. @annevk's notion about pausing execution is very promising, but I'd strongly prefer not to hinge development of solutions here on it.

Now in the future, if canvas changed, this string we allocate would easily accommodate a new, not-cruddy behavior! And if people think it would be well received over in WHATWG I could propose that - but I worry it wouldn't get much traction. It'd basically be converting toDataURL to be promise-based (since toBlob is callback-based).  (There is a snag: isPointInPath looks like it would leak data as well, but that is an ugly API to turn asynchronous. We'd have to investigate it more to learn how much data you can extract from it.) And of course, the web would just need to migrate to the new APIs for better behavior ;)

Separately, there is a new(ish?) [OffscreenCanvas thing](https://html.spec.whatwg.org/multipage/canvas.html#offscreencanvas). It has two APIs: convertToBlob (which is Promise-based already!) and transferToImageBitmap (which is synchronous). Making the latter asynchronous would be awesome, and maybe it would get more traction because it's a newer thing? (Or at least, the web hasn't deployed it everywhere yet?)

---

Separately, I don't like the idea of a general "Can this site fingerprint you?" permission prompt. My hope is that some of the many fingerprinting vectors will be reconsidered in a variety of browsers. For example: so few websites actually use a gamepad, and the tail of users who have gamepads (and which model) is so small; GamePads seems like something that could reasonably be prompted for, as opposed to letting every website on the Internet get that information right away. Similarly, I have a very theoretical idea about making a [prompt for Timezone](https://bugzilla.mozilla.org/show_bug.cgi?id=1426232).

I'm not trying to talk about either of those in this thread, I'm just using them to demonstrate that in the future I hope multiple browsers will consider prompts for fingerprinting resistance of different APIs, and having a single permission that implies A, B, and C in one browser, B and C in another browser, and C in an earlier version of that browser is a bad situation to be in spec and compatibility-wise.

---

> I'm against letting the apps know if we show a prompt if they will fingerprint (unless we always show the prompt). Because letting them know may alter their behavior. So they will fingerprint only the ones who won't notice that. This will make fingerprinting more stealthy , the web less transparent and people more ignorant.

If a website *wants* to be stealthy or malicious, it's not difficult to know how the browser will behave. It's just side-channel feature detection ('Oh you're Firefox 32, then you must support foo'), something the web did for years and now we're working to deprecate. Supporting a simple permission query will make it easy for the web to learn this information in a way that is future-proof. And it will make the web experience for a resist fingerprinting mode better, and more likely to get such an experience into browsers by default.

Here's a simple algorithm to know if a browser will show a permission prompt on canvas. It's not 100% accurate, but it's going to have a very low false positive and a very low false negative rate.

1. Is the client IP address a tor exit node, using [TorDNSEL](https://www.torproject.org/projects/tordnsel.html.en) -> If Yes: It will show a prompt
2. Is the browser User Agent Firefox, the version 52 (or 60), and is the result of performance.now() rounded exactly to 100ms -> If Yes: It will show a prompt

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/165#issuecomment-353118194