Re: [whatwg] Proposal: navigator.cores

I've updated the spec proposal [1] to sanction reporting fewer than the
actual number of logical cores as a fingerprinting mitigation.  I've also
renamed the API from navigator.cores to navigator.hardwareConcurrency to
match the proposed WebKit patch.

Adam

[1] http://wiki.whatwg.org/wiki/NavigatorCores



On Thu, May 8, 2014 at 7:02 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> FYI
> From the WebKit side, people are leaning towards returning the logical CPU
> count but limit the maximum value to 8 [1].
> This should cover the vast majority of systems and use cases for this
> property and still not expose users that are on "high value" devices..
>
> 1: https://bugs.webkit.org/show_bug.cgi?id=132588
>
>
> On Tue, May 6, 2014 at 2:30 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> >
> >
> >
> > On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio <jcgregorio@google.com
> >wrote:
> >
> >> On Tue, May 6, 2014 at 7:57 AM, João Eiras <joaoe@opera.com> wrote:
> >> ...
> >> >
> >> > I guess everyone that is reading this thread understands the use cases
> >> well
> >> > and agrees with them.
> >> >
> >> > The disagreement is what kind of API you need. Many people, rightly
> so,
> >> have
> >> > stated that a core count gives little information that can be useful.
> >> >
> >> > It's better to have an API that determines the optimal number of
> >> parallel
> >> > tasks that can run, because who knows what else runs in a different
> >> process
> >> > (the webpage the worker is in, the browser UI, plugins, other
> webpages,
> >> > iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount'
> >> would
> >> > be a start.
> >> >
> >>
> >> +1
> >>
> >> The solution proposed should actually be a solution to the problem as
> >> stated, which,
> >> from the abstract read:
> >>
> >>    "The intended use for the API is to help developers make informed
> >> decisions regarding
> >>    the size of their worker threadpools to perform parallel algorithms."
> >>
> >> So the solution should be some information about the maximum number of
> >> parallel
> >> workers that a page can expect to run, which may have no relation to
> >> the number of
> >> cores, physical or virtual. The browser should be allowed to determine
> >> what that number
> >> is based on all the factors it has visibility to, such as load, cores,
> >> and policy.
> >>
> >> Returning the number is actually important, for example, "physics
> >> engines for WebGL
> >> games", how you shard the work may depend on knowing how many parallel
> >> workers
> >> you should schedule.
> >>
> >
> > It seems everyone is in agreement that this API should return the number
> > of useful parallel tasks.
> >
> > So far, people have proposed several names:
> > - cores -> this seems confusing since the returned number might be lower
> > - concurrency -> there can be more concurrent tasks than there are
> logical
> > cores
> > - hardwareConcurrency
> > - parallelTaskCount
> >
> > Leaving the question of fingerprinting aside for now, what name would
> > people prefer?
> >
>

Received on Friday, 9 May 2014 03:17:30 UTC