Re: [whatwg] Proposal: navigator.cores

On Sun, May 4, 2014 at 8:35 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Sun, 4 May 2014, Adam Barth wrote:
> >
> > 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.
> >
> > The needs of the web as a platform have changed because now the web
> > faces stiff competition from other mobile application frameworks.
>
> I'm not arguing that we shouldn't provide solid APIs that allow authors to
> provide multi-core solutions. I'm arguing that when we do so, we should do
> so while protecting the privacy of users.
>
>
> > 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
>
> I'm not responsible for what individual browser vendors do.
>
>
> > 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
>
> I'm not responsible for what editors of other standards do.
>
>
> > 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.
>
> Sure we can. You don't need to know how many cores a system has, you need
> to know how you can make optimal use of the resources of the system
> without affecting other tasks that the user is running. There are plenty
> of ways we can address this use case that don't expose the number of cores
> as a reliable metric.
>
>
> On Sun, 4 May 2014, Rik Cabanier wrote:
> > > >
> > > > 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.
>
> Right. You have to install the application. At that point, game over.
>

No, you misunderstood.
The admin install the application and has all privileges.
A guest user with the most limited set of privileges can still call this
API since it is considered so low risk. (This is likely also why Chrome can
use it since it's process run in a very restricted sandbox.)


> The point is that on the Web there's no installation step. This is a
> feature. It's one of the Web's most critically powerful assets.
>
>
> > Microsoft did not considered an API that needs additional security. OSX
> > is the same (and likely most other OS's)
>
> Sure. Once you've agreed to just let the application reside on your
> system, then you can fingerprint the user with impunity.
>
> The Web is better than that, or at least, we should make it better.


Yes, the web is like the reverse of an OS: instead of the admin/OS vendor
being in charge of the machine and managing the privileges, it's the user
who is in charge and who gets to decide if an application gets to use
restricted features.


> > Are you saying it's better that people use an estimator poly-fill?
>
> No, I'm saying we should provide an API to address the underlying use case
> -- making optimal use of CPU resources -- without increasing the
> fingerprinting risk.


I think we already agree on that. The API should return the optimal number
of concurrent threads. This doesn't need to be just related to hardware
resources and I can even see it be variable depending on the state of the
machine (battery - low battery - too hot - background - load)

Designing a thread scheduler like one the other proposals is a different
problem and much more difficult to generalize.


> On Sun, 4 May 2014, Eli Grey wrote:
> > On Sun, May 4, 2014 at 4:11 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > or you have to examine permissions that the application is requesting,
> > > and explicitly grant it the right to run on your machine
> >
> > I am not aware of this in any platforms. Can you provide one example of
> > a platform that requests an explicit permission for access to core
> > count?
>
> The "explicit permission" is "you can run on this system". On iOS,
> Android, MacOS, Linux, Windows, and pretty much every other platform,
> before you can run code on the system, the user or administrator has to
> explicitly install your code.
>
> On the Web, all it takes is visiting a URL. There's no installation step,
> there's no need for the user to click through a dialog saying "running
> native code is highly risky".
>
> Because the Web has a dramatically lower bar for running code, we have to
> have a dramatically higher bar for protecting the user.
>
>
> > Neither iOS or Android requires any specific permissions for this
> > information. You can create an Android application that requests
> > absolutely no permissions that can read the core count and display it to
> > the user.
>
> No, you can't. You need one explicit permission: the permission to run in
> the first place.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Monday, 5 May 2014 04:17:03 UTC