Gavin: The fingerprinting entropy exposed by Rik's patch is actual *magnitudes* less than the entropy exposed on http://renderingpipeline.com/webgl-extension-viewer/
I don't need the extra less-than-a-bit of entropy from my proposal to reliably fingerprint you, as the above URL + Panopticlick is already more than enough than I'll ever need. I can also reliably detect machine value using this information—core count is unnecessary. On Tue, May 20, 2014 at 9:22 AM, Joshua Cranmer 🐧 <pidgeo...@gmail.com> wrote: > Yet the entire reason you're arguing to include it is that developers need > to gauge the amount of simultaneous work that can be done. > If you read the spec, you will find that "the intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms." Your worker threadpool will always stay the same size, but it will have different performance characteristics throughout it's lifetime based on varying system load. This is okay. The OS scheduler balances your load with everything else. If you want constant performance then you will need a realtime OS and a platform other than the web. If instead I used a value that represents the "amount of simultaneous work that can be done" (a constantly changing value based on current system load) to size my threadpool, I would be constantly *resizing* my threadpool to accommodate for the load. As explained in the previous navigator.cores/hardwareConcurrency discussions, workers were intentionally created as very heavyweight interfaces, unlike lightweight native threads with shared memory. Continuously resizing a worker threadpool only results in much worse performance due to the worker setup overhead. My spec is not a measure of simultaneous work that can be done or performance that can be had. It is a tool for you to use to split up parallel workloads among multiple processors, independent of system load. Userspace load balancing is not part of my spec. On Tue, May 20, 2014 at 12:16 PM, Gavin Sharp <ga...@gavinsharp.com> wrote: > I think it might help your case to acknowledge the often significant > difference between "technically possible, but expensive and > unreliable" and "extremely simple and 100% reliable". That something > is already technically possible does not mean that making it easier > has no consequences. Arguing that the incremental fingerprinting risk > is negligible is reasonable, but you lose credibility if you suggest > it doesn't exist. > > Gavin > > On Tue, May 20, 2014 at 12:30 AM, Rik Cabanier <caban...@gmail.com> wrote: > > On Tue, May 20, 2014 at 12:24 AM, Jonas Sicking <jo...@sicking.cc> > wrote: > > > >> On Mon, May 19, 2014 at 7:14 PM, Mike Hommey <m...@glandium.org> wrote: > >> > On Mon, May 19, 2014 at 06:35:49PM -0700, Jonas Sicking wrote: > >> >> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier <caban...@gmail.com> > >> wrote: > >> >> > I don't see why the web platform is special here and we should > trust > >> that > >> >> > authors can do the right thing. > >> >> > >> >> I'm fairly sure people have already pointed this out to you. But the > >> >> reason the web platform is different is that because we allow > >> >> arbitrary application logic to run on the user's device without any > >> >> user opt-in. > >> >> > >> >> I.e. the web is designed such that it is safe for a user to go to any > >> >> website without having to consider the risks of doing so. > >> >> > >> >> This is why we for example don't allow websites to have arbitrary > >> >> read/write access to the user's filesystem. Something that all the > >> >> other platforms that you have pointed out do. > >> >> > >> >> Those platforms instead rely on that users make a security decision > >> >> before allowing any code to run. This has both advantages (easier to > >> >> design APIs for those platforms) and disadvantages (malware is pretty > >> >> prevalent on for example Windows). > >> > > >> > As much as I agree the API is not useful, I don't buy this argument > >> > either. What prevents a web app to just use n workers, where n is a > much > >> > bigger number than what would be returned by the API? > >> > >> Nothing. The attack I'm trying to prevent is fingerprinting. Allowing > >> workers to run a large number of workers does not allow > >> fingerprinting. > >> > > > > Eli's polyfill can already be used to do fingerprinting [1]. It's not > very > > good at giving a consistent and accurate results which makes it less > > suitable to plan your workload. It also wastes a lot of CPU cycles. > > > > 1: http://wg.oftn.org/projects/core-estimator/demo/ > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
