On Tue, May 20, 2014 at 12:29 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Mon, May 19, 2014 at 8:14 PM, Rik Cabanier <caban...@gmail.com> wrote: > > On Mon, May 19, 2014 at 6:35 PM, Jonas Sicking <jo...@sicking.cc> 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) > > > > I'm unsure what point you are trying to make. > > This is not an API that exposes any more information than a user agent > > sniffer can approximate. > > It will just be more precise and less wasteful. For the high value > system (= > > lots of cores), we intentionally limited the number of cores to 8. This > > number of cores is very common and most applications won't see much use > > above 8 anyway. > > I've already answered this in both this thread and on blink-dev. And > I'm not the only one that have done so. > Was this your answer? 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. My point was that the polyfill is only good for fingerprinting but not for efficiently returning a correct number. I believe we are going in circles. As far as I can tell there is not a > lot of agreement to ship this. At least not at this time. > No, not from mozilla. Just authors, blink and WebKit. > I'm happy to help working on the WorkerPool suggestion though. I > believe that will give more value to developers anyway (not a strict > superset I agree, but way easier to get right). A worker pool is not a solution for applications that want workers that are ready to respond and that target different workloads. It's also a complex solution that will will come with a long term commitment. I'm unsure if it addresses the fingerprinting or Ehsan's "core availability" issues. Will there be only 1 workerpool per browser process, or 1 per document? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
