On 2017-04-05 5:44 PM, Tom Ritter wrote: > On Wed, Apr 5, 2017 at 12:29 PM, Aryeh Gregor <a...@aryeh.name> wrote: >> On Wed, Apr 5, 2017 at 7:34 PM, Tom Ritter <t...@mozilla.com> wrote: >>> It looks like this exposes pointerType, which reveals whether the user >>> is using a mouse, pen, or touch input. >>> >>> It also exposes detailed information about the geometry of the input >>> (size of the thing pointing, pressure, tilt, twist. >>> >>> All of these are more detailed information that websites currently >>> receiving, meaning that this can be used as a mechanism for >>> fingerprinting (and tracking) users. >> >> I think this has been discussed here before, but I don't recall a firm >> conclusion: has anyone established whether a nontrivial number of >> users are non-fingerprintable as things stand? If the vast majority >> of users can be fingerprinted right now, and there are no realistic >> plans to change that, it doesn't seem like we should care about >> increasing fingerprinting ability. I haven't investigated, but I'd be >> surprised if there are a lot of users who can't be fingerprinted yet, >> given the huge and rapidly-expanding number of features in the web >> platform. > > Firstly, this does not change the fact that this feature does have > Privacy implications. This is the second 'Intent to Implement' I have > replied to in the past two months that said "No Security or Privacy > Implications" when there are in fact. This trend is disturbing.
This is the point of having this process. :-) Hopefully people will start to think more about the implications of this in the future. But see below about fingerprinting. > Besides that - the goal of anti-fingerprinting is not to make all > users uniform, but rather to make it harder and harder to single > individual users out. The more features we provide about users' > configuration details (like mouse pointer size, type, functionality), > the easier it is to single them out. For private browsing modes, > ideally there would be a mapping or abstraction mechanism that covers > a common denominator. > > I'm not sure how much review this feature has had. In (my) ideal > world, I think when we add a feature like this, the first question we > would ask is "Why is this detailed information needed in the first > place?" and if we have a compelling answer, we would follow it up with > "Why can't we make this optional, so that it's either not exposed in > privacy preserving modes or is only exposed in ways that represent > user intention to release it?" Perhaps these questions were already > considered. But if no one thought this information was related to > Privacy to begin with, my assumption is that they were not given > serious weight. > > Finally, Mozilla _is_ actively working on making users less > fingerprintable. We're devoting resources to integrating > anti-fingerprinting patches > (https://wiki.mozilla.org/Security/Fingerprinting), which is the > groundwork needed to expose the functionality to users (beyond > individual pref flags). Obviously this is tricky - it's hard to put > smoke back into bags once it's bet let out and relied upon all over > the web (which is why it's so important to adequately consider things > in Intent to X threads.). We're exploring options for this in > https://bugzilla.mozilla.org/show_bug.cgi?id=1308340 but some ideas > have been integrating with Private Browsing Mode and/or Tracking > Protection. Of course this presumes adequate research to measure > breakage, etc etc - but my point is - we're not ignoring this problem > and we do in fact care about it. I agree that it would be nice to be proactive for hooking into privacy.resistFingerprinting for features like this. And I think we should do that for this feature specifically but of course we need to figure out the details of what to expose instead of the real info. But what is our official policy towards fingerprinting in Gecko in the face of the (now public knowledge) existence of attacks such as the HSTS super cookie? See <https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/> I was under the impression that given that we already expose arbitrary number of bits through the existing features of the Web platform, this is a lost cause. :/ In general, I should also say that designing features with fingerprinting in mind is *extremely* difficult and takes a lot of effort on the part of all browser vendors, which would be difficult to do effectively without some broad agreement that the extra effort spent is worth it. WHATWG (in HTML at least) mostly treats this by documenting the exposed vectors <https://html.spec.whatwg.org/multipage/introduction.html#fingerprinting-vector>. I wonder what the position of the W3C TAG is? (FWIW, I don't think we should hold off enabling this feature on Nightly for this discussion, I'm excited to see it happen!) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
