W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] Proposal: navigator.cores

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 4 May 2014 14:49:00 -0700
Message-ID: <CAJE5ia8qbCDm5-FHm-YgJuaCLpNVQnrCusDP3N6f2ZqSrEOexg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@lists.whatwg.org>
On Sun, May 4, 2014 at 1:11 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Sat, 3 May 2014, Adam Barth wrote:
> >
> > Over on blink-dev, we've been discussing [1] adding a property to
> navigator
> > that reports the number of cores [2].
> > [1]
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4
> > [2] http://wiki.whatwg.org/wiki/NavigatorCores
> > Some of the use cases for this feature have been discussed previously on
> > this mailing list [3] and rejected in favor of a more complex system,
> > perhaps similar to Grand Central Dispatch [4].
> > [3]
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html
> > [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch
>
> It's not clear what has changed since that discussion.


The world of computing has changed since 2009.  At that time, the iPhone 3G
had just been released and Apple hadn't even released the first iPad.

Why are the concerns raised at that time no longer valid?
>

The needs of the web as a platform have changed because now the web faces
stiff competition from other mobile application frameworks.

 > As far as I can tell, this functionality exists in every other platform
> > (including iOS and Android).
>
> This is true, but all those platforms have security mechanisms in place to
> mitigate the risk: you have to manually install the application, thus
> granting it either essentially full access to your machine (Win32), or
> you have to have it vetted by a third party (iOS), or you have to examine
> permissions that the application is requesting, and explicitly grant it
> the right to run on your machine.
>
> The Web's security model is radically different. On the Web, we assume
> that it is safe to run any random hostile code, and that that code cannot
> harm you or violate your privacy. There are flaws in the privacy
> protection (i.e. fingerprinting vectors) that browsers are slowly
> patching, but we have worked hard to avoid adding new fingerprinting
> vectors. We should continue to do so.
>

My personal view is that the fingerprinting horse left the barn years ago.
 I don't believe vendors will succeed in patching the existing fingerprint
vectors.  For example, the WebKit project cataloged a number of vectors
three year ago and has made very little progress patching any of them:

http://trac.webkit.org/wiki/Fingerprinting

Moreover, vendors are adding new state vectors all the time.  For example,
the HTTP2 protocol contains an explicit protocol element for persisting
data on the client:

http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5

The web cannot afford to avoid exposing useful, non-privacy sensitive
information, such as the number of cores, to developers out of a fear of
fingerprinting.  Avoiding exposing this information will not improve
privacy because fingerprinting is already possible.  Instead, not providing
developers the tools they need to build compelling web content on mobile
will simply result in developers leaving the web platform for other mobile
application frameworks.

> Others have raised concerns that exposing the number of cores could lead
> > to increased fidelity of fingerprinting [5].
> >
> > My view is that the fingerprinting risks are minimal.  This information
> > is already available to web sites that wish to spend a few seconds
> > probing your machine [6].  Obviously, exposing this property makes that
> > easier and more accurate, which is why it's useful for developers.
> > [5]
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ
> > [6] http://wg.oftn.org/projects/core-estimator/demo/
>
> The core estimator is wildly inaccurate. For example, it is highly
> sensitive to machine load. I don't think it's fair to say "well, you can
> get this data with poor fidelity over a few seconds, therefore providing a
> precise number with zero milliseconds latency is no worse".
>

You're right that Panopticlick doesn't bother to spend the few seconds it
takes to estimate the number of cores because it already has sufficient
information to fingerprint 99.1% of visitors:

https://panopticlick.eff.org/browser-uniqueness.pdf

 > IMHO, a more complex worker pool system would be valuable, but most
> > systems that have such a worker pool system also report the number of
> > hardware threads available.
>
> They don't have to, though.
>

I didn't say they needed to.  I said they did.

> In fact, the web was the only platform I could find that didn't make the
> > number of cores available to developers.
>
> The Web is unique in attempting to protect users' privacy in the face of
> hostile code without requiring "installation" or a trust-granting step.
>

I don't believe the number of cores is privacy-sensitive information.
 Revealing this information to web sites does not require a trust-granting
step.

Adam
Received on Sunday, 4 May 2014 21:50:00 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC