On Mon, May 12, 2014 at 5:03 PM, Rik Cabanier <caban...@gmail.com> wrote:
> Primary eng emails
> caban...@adobe.com, bugm...@eligrey.com
>
> *Proposal*
> http://wiki.whatwg.org/wiki/NavigatorCores
>
> *Summary*
> Expose a property on navigator called hardwareConcurrency that returns the
> number of logical cores on a machine.
>
> *Motivation*
> All native platforms expose this property, It's reasonable to expose the
> same capabilities that native applications get so web applications can be
> developed with equivalent features and performance.
>
> *Mozilla bug*
> https://bugzilla.mozilla.org/show_bug.cgi?id=1008453
> The patch is currently not behind a runtime flag, but I could add it if
> requested.
>
> *Concerns*
> The original proposal required that a platform must return the exact number
> of logical CPU cores. To mitigate the fingerprinting concern, the proposal
> was updated so a user agent can "lie" about this.
> In the case of WebKit, it will return a maximum of 8 logical cores so high
> value machines can't be discovered. (Note that it's already possible to do
> a rough estimate of the number of cores)
Here's the responses that I sent to blink-dev before you sent the
above email here.
"For what it's worth, in Firefox we've avoided implementing this due to
the increased fingerprintability. Obviously we can't forbid any APIs
which increase fingerprintability, however in this case we felt that
the utility wasn't high enough given that the number of cores on the
machine often does not equal the number of cores available to a
particular webpage.
A better approach is an API which enables the browser to determine how
much to parallelize a particular computation."
and
"Do note that the fact that you can already approximate this API using
workers is just as much an argument for that there are no additional
fingerprinting entropy exposed here, as it is an argument for that
this use case has already been resolved.
Additionally many of the people that are fingerprinting right now are
unlikely to be willing to peg the CPU for 20 seconds in order to get a
reliable fingerprint. Though obviously there are exceptions.
Another relevant piece of data here is that we simply haven't gotten
high priority requests for this feature. This lowers the relative
value-to-risk ratio."
I still feel like the value-to-risk ratio here isn't good enough. It
would be relatively easy to define a WorkerPool API which spins up
additional workers as needed.
A very simple version could be something as simple as:
page.html:
var wp = new WorkerPool("worker.js");
wp.onmessage = resultHandler;
myArrayOfWorkTasks.forEach(x => wp.postMessage(x));
worker.js:
onmessage = function(e) {
var res = doHeavyComputationWith(e.data);
postMessage(res);
}
function doHeavyComputationWith(val) {
...
}
This obviously is very handwavey. It's definitely missing some
mechanism to make sure that you get the results back in a reasonable
order. But it's not rocket science to get this to be a coherent
proposal.
/ Jonas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
