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
