Re: [whatwg] Proposal: navigator.cores

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. Why are the
> concerns raised at that time no longer valid?
>
>
> > 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),


Not quite true for Win32. An admin can install an application but a user
with very limited privileges can run it and call the
'GetLogicalProcessorInformation' API to get information about the number of
logical cores.
Microsoft did not considered an API that needs additional security. OSX is
the same (and likely most other OS's)


> 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.
>
>
> > 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".


Are you saying it's better that people use an estimator poly-fill? Authors
want to know this information and will use other means to get this
information. This will likely favor popular platforms.


> > 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.


Yes, they have to because even with worker pools, an application wants know
how it can best break up the problem.


> > 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 agree with Adam and fail to see what possible information of value could
leak. This is nothing like reading pixels from the screen or giving access
to a GPS device.
Browsers already directly and indirectly give the author access to its
capabilities. Having an optimal number of concurrent tasks should be basic
information.

Received on Sunday, 4 May 2014 22:33:35 UTC