On Sun, May 4, 2014 at 4:49 PM, Adam Barth <w...@adambarth.com> wrote:

> 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

It's pretty unpleasant to use a paper arguing that fingerprinting is a
threat to online privacy as an argument that we should give up trying to
prevent fingerprinting.

On Mon, May 5, 2014 at 10:20 PM, Ian Hickson <i...@hixie.ch> wrote:

> of Workers today, as bz pointed out earlier). Indeed, on a high-core
> machine as we should expect to start seeing widely in the coming years, it
> might make sense for the browser to randomly limit the number of cores on
> a per-origin/session basis, specifically to mitigate fingerprinting.

This might make sense in browser modes like Chrome's "incognito" mode, but
I think it would be overboard to do this in a regular browser window.  If
I've paid for a CPU with 16 cores, I expect applications which are able to
use them all to do so consistently, and not be randomly throttled to
something less.

On Tue, May 6, 2014 at 4:38 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 5/6/14, 5:30 PM, Rik Cabanier wrote:
>> Leaving the question of fingerprinting aside for now, what name would
>> people prefer?
> "mauve"?
> Failing that, "maxUsefulWorkers"?

It can be useful to start more workers than processors, when they're not

Glenn Maynard

Reply via email to