Re: Intent to Implement: canvas-imagedata permission

[Tom Ritter]

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

[Gervase Markham]

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

[Tom Ritter]

> 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

[Daniel Veditz]

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

[L. David Baron]

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

[Tom Ritter]

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