Re: Intent to Implement: canvas-imagedata permission
On Thu, Jan 11, 2018 at 10:26 AM, Gervase Markham wrote: > On 10/01/18 18:40, Tom Ritter wrote: >> This proposal is that. Add a permission 'canvas-imagedata' that will >> return 'granted' when Resist Fingerprinting mode is disabled, and >> 'prompt' when RP is enabled and appropriate. > > As this is basically a "is RF turned on?" flag, why not just call it > that? Or are we going to add more permissions for any other things about > RF mode that people might want to query? Two reasons. The first is what you said: We are thinking idly about other permissions. (Like timezone: https://bugzilla.mozilla.org/show_bug.cgi?id=1426232 ). But that doesn't preclude us using a single 'is resist-fingerprinting turned on' flag. The real argument is buried in that github discussion, which I'll just copy/paste: 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. 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. -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: canvas-imagedata permission
On 10/01/18 18:40, Tom Ritter wrote: > This proposal is that. Add a permission 'canvas-imagedata' that will > return 'granted' when Resist Fingerprinting mode is disabled, and > 'prompt' when RP is enabled and appropriate. As this is basically a "is RF turned on?" flag, why not just call it that? Or are we going to add more permissions for any other things about RF mode that people might want to query? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: canvas-imagedata permission
> In Resist Fingerprinting mode, could it sometimes return all 3 > states (granted, prompt, denied) depending on whether the user had > chosen to remember the decision from a prior prompt? Or is there no > such memory? Yes, it can return all three, it will behave like a normal permission (and already does in fact) in that regard. (And +1 to Dan) -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: canvas-imagedata permission
On Wed, Jan 10, 2018 at 12:32 PM, L. David Baron wrote: > Is stopping canvas fingerprinting actually a substantial reduction > in available entropy, or is it just removing a convenient source > that happens to combine a bunch of sources of entropy that are also > available elsewhere Blocking canvas fingerprinting βis itself substantial, but it's just one of many things that resist.fingerprinting changes which is a kind of "master switch" for many of the anonymity patches we've uplifted from Tor. -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: canvas-imagedata permission
On Wednesday 2018-01-10 12:40 -0600, Tom Ritter wrote: > When Resist Fingerprinting is enabled, we display a permission prompt > when a website tries to access the rendered canvas data. This is > because canvas rendering is a popular fingerprinting and tracking > vector on the web. Is stopping canvas fingerprinting actually a substantial reduction in available entropy, or is it just removing a convenient source that happens to combine a bunch of sources of entropy that are also available elsewhere (such as OS and major version, browser version, available fonts, and some characteristics of the graphics hardware and drivers, although some of the latter might not be fully available elsewhere)? (I ask this because I think it's more useful to work on privacy protections that work at scale and against determined adversaries, than ones that work only when they're used by a small number of users because if they would be used by more users then sites would work around the protection.) > However, some uses of this technique are not actually malicious - > they're doing feature detection (emoji suppot may be the most popular > instance of this.) This has actually hit even us: we throw the prompt > on blog.mozilla.org > https://bugzilla.mozilla.org/show_bug.cgi?id=1413182 > > The people behind this emoji detecting this is Wordpress, and they > agree: this prompt is annoying. They would like to not show it (and > assume emoji support is missing.) But they don't have a way to ask > "Hey, will the browser let me read canvas pixel data?" > > This proposal is that. Add a permission 'canvas-imagedata' that will > return 'granted' when Resist Fingerprinting mode is disabled, and > 'prompt' when RP is enabled and appropriate. In Resist Fingerprinting mode, could it sometimes return all 3 states (granted, prompt, denied) depending on whether the user had chosen to remember the decision from a prior prompt? Or is there no such memory? > Is this feature enabled by default in sandboxed iframes? Yes. > > In general, I think nested permissions are a bad idea, and we should > block them, but that's a whole different discussion. See > https://bugzilla.mozilla.org/show_bug.cgi?id=1414164 I think there's been some discussion in other forums about moving to a model (at least for new permissions) where: * permissions apply to the toplevel document by default, but not to subframes within it * there's an API that allows the toplevel document to delegate one of its permissions to a frame inside of it (which could be done recursively). (I think the proposed way of doing this was https://wicg.github.io/feature-policy/ although I'm not sure if I'm remembering correctly.) -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Implement: canvas-imagedata permission
Summary: When Resist Fingerprinting is enabled, we display a permission prompt when a website tries to access the rendered canvas data. This is because canvas rendering is a popular fingerprinting and tracking vector on the web. However, some uses of this technique are not actually malicious - they're doing feature detection (emoji suppot may be the most popular instance of this.) This has actually hit even us: we throw the prompt on blog.mozilla.org https://bugzilla.mozilla.org/show_bug.cgi?id=1413182 The people behind this emoji detecting this is Wordpress, and they agree: this prompt is annoying. They would like to not show it (and assume emoji support is missing.) But they don't have a way to ask "Hey, will the browser let me read canvas pixel data?" This proposal is that. Add a permission 'canvas-imagedata' that will return 'granted' when Resist Fingerprinting mode is disabled, and 'prompt' when RP is enabled and appropriate. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1429519 Link to standard: It's been discussed here: https://github.com/w3c/permissions/issues/165 Platform coverage: All platforms Estimated or target release: TBD Preference behind which this will be implemented: Unless requested, there won't be a pref to disable this entirely, but it will always return 'granted' unless privacy.resistFingerprinting is enabled. Is this feature enabled by default in sandboxed iframes? Yes. In general, I think nested permissions are a bad idea, and we should block them, but that's a whole different discussion. See https://bugzilla.mozilla.org/show_bug.cgi?id=1414164 Do other browser engines implement this? No; no other browser does anti-fingerprinting, so they would not need to implement this. Brave could I suppose. Tests - We'll write some, including WPT. In general, work on Canvas is progress on several fronts. We would indeed like to neuter Canvas fingerprinting entirely, and are investigating that over in https://trac.torproject.org/projects/tor/ticket/24521 -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform