- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 6 May 2014 19:33:14 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>, Adam Barth <w3c@adambarth.com>
On Tue, May 6, 2014 at 5:24 PM, Glenn Maynard <glenn@zewt.org> wrote: > 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. What do you mean? For fingerprinting, the algorithm would not have to be precise. Instead a routine that return 1 or 2 for cheap machines and > 12 for expensive machines would be enough. The fact that this is so easily accomplished today and we don't have any evidence that this is happening, tells me that it is not that valuable. > 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. Exactly. > 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. > Yes. The 'hardwareConcurrency' and 'parallelTaskCount' terms feel better because they don't imply a maximum.
Received on Wednesday, 7 May 2014 02:33:40 UTC