- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 6 May 2014 19:24:34 -0500
- To: Adam Barth <w3c@adambarth.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>
On Sun, May 4, 2014 at 4:49 PM, Adam Barth <w3c@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 <ian@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 <bzbarsky@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 CPU-bound. -- Glenn Maynard
Received on Wednesday, 7 May 2014 00:25:00 UTC