Re: [whatwg] Proposal: navigator.cores
On May 4, 2014, at 7:45, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. Shouldn't this also be captured in the API's name? --tobie
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 12:13 AM, Tobie Langel tobie.lan...@gmail.comwrote: On May 4, 2014, at 7:45, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. Shouldn't this also be captured in the API's name? Maybe navigator.hardwareConcurrency as a nod to the C++11 name? Adam
Re: [whatwg] Proposal: navigator.cores
On Sat, 3 May 2014, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch It's not clear what has changed since that discussion. Why are the concerns raised at that time no longer valid? As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), or you have to have it vetted by a third party (iOS), or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine. The Web's security model is radically different. On the Web, we assume that it is safe to run any random hostile code, and that that code cannot harm you or violate your privacy. There are flaws in the privacy protection (i.e. fingerprinting vectors) that browsers are slowly patching, but we have worked hard to avoid adding new fingerprinting vectors. We should continue to do so. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/ The core estimator is wildly inaccurate. For example, it is highly sensitive to machine load. I don't think it's fair to say well, you can get this data with poor fidelity over a few seconds, therefore providing a precise number with zero milliseconds latency is no worse. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. They don't have to, though. In fact, the web was the only platform I could find that didn't make the number of cores available to developers. The Web is unique in attempting to protect users' privacy in the face of hostile code without requiring installation or a trust-granting step. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 1:11 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 3 May 2014, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch It's not clear what has changed since that discussion. The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. Why are the concerns raised at that time no longer valid? The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), or you have to have it vetted by a third party (iOS), or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine. The Web's security model is radically different. On the Web, we assume that it is safe to run any random hostile code, and that that code cannot harm you or violate your privacy. There are flaws in the privacy protection (i.e. fingerprinting vectors) that browsers are slowly patching, but we have worked hard to avoid adding new fingerprinting vectors. We should continue to do so. My personal view is that the fingerprinting horse left the barn years ago. I don't believe vendors will succeed in patching the existing fingerprint vectors. For example, the WebKit project cataloged a number of vectors three year ago and has made very little progress patching any of them: http://trac.webkit.org/wiki/Fingerprinting Moreover, vendors are adding new state vectors all the time. For example, the HTTP2 protocol contains an explicit protocol element for persisting data on the client: http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5 The web cannot afford to avoid exposing useful, non-privacy sensitive information, such as the number of cores, to developers out of a fear of fingerprinting. Avoiding exposing this information will not improve privacy because fingerprinting is already possible. Instead, not providing developers the tools they need to build compelling web content on mobile will simply result in developers leaving the web platform for other mobile application frameworks. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/ The core estimator is wildly inaccurate. For example, it is highly sensitive to machine load. I don't think it's fair to say well, you can get this data with poor fidelity over a few seconds, therefore providing a precise number with zero milliseconds latency is no worse. 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 IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. They don't have to, though. I didn't say they needed to. I said they did. In fact, the web was the only platform I could find that didn't make the number of cores available to developers. The Web is unique in attempting to protect users' privacy in the face of hostile code without requiring installation or a trust-granting step. I don't believe the number of cores is privacy-sensitive information. Revealing this information to web sites does not require a trust-granting step. Adam
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 1:11 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 3 May 2014, Adam Barth wrote: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 [2] http://wiki.whatwg.org/wiki/NavigatorCores Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024251.html [4] http://en.wikipedia.org/wiki/Grand_Central_Dispatch It's not clear what has changed since that discussion. Why are the concerns raised at that time no longer valid? As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), Not quite true for Win32. An admin can install an application but a user with very limited privileges can run it and call the 'GetLogicalProcessorInformation' API to get information about the number of logical cores. Microsoft did not considered an API that needs additional security. OSX is the same (and likely most other OS's) or you have to have it vetted by a third party (iOS), or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine. The Web's security model is radically different. On the Web, we assume that it is safe to run any random hostile code, and that that code cannot harm you or violate your privacy. There are flaws in the privacy protection (i.e. fingerprinting vectors) that browsers are slowly patching, but we have worked hard to avoid adding new fingerprinting vectors. We should continue to do so. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. [5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/B6pQClqfCp4/bfPhYPPQqwYJ [6] http://wg.oftn.org/projects/core-estimator/demo/ The core estimator is wildly inaccurate. For example, it is highly sensitive to machine load. I don't think it's fair to say well, you can get this data with poor fidelity over a few seconds, therefore providing a precise number with zero milliseconds latency is no worse. Are you saying it's better that people use an estimator poly-fill? Authors want to know this information and will use other means to get this information. This will likely favor popular platforms. IMHO, a more complex worker pool system would be valuable, but most systems that have such a worker pool system also report the number of hardware threads available. They don't have to, though. Yes, they have to because even with worker pools, an application wants know how it can best break up the problem. In fact, the web was the only platform I could find that didn't make the number of cores available to developers. The Web is unique in attempting to protect users' privacy in the face of hostile code without requiring installation or a trust-granting step. I agree with Adam and fail to see what possible information of value could leak. This is nothing like reading pixels from the screen or giving access to a GPS device. Browsers already directly and indirectly give the author access to its capabilities. Having an optimal number of concurrent tasks should be basic information.
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 6:49 AM, Adam Barth w...@adambarth.com wrote: On Sun, May 4, 2014 at 12:13 AM, Tobie Langel tobie.lan...@gmail.comwrote: On May 4, 2014, at 7:45, Rik Cabanier caban...@gmail.com wrote: On Sat, May 3, 2014 at 10:32 PM, Eli Grey m...@eligrey.com wrote: The proposal specifically states using logical cores, which handles all of the CPUs you mentioned properly. Intel CPUs with hyperthreading enabled report logical cores as double the hardware cores. Depending on the version and configuration of the Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical cores (only one cluster can run at a time) or 8 logical cores (big.LITTLE MP, available in Exynos 5420 or later only). Great! Make sure this is captured when it is put in a specification. Otherwise the subtlety between an actual and a logical core might get lost. Shouldn't this also be captured in the API's name? Maybe navigator.hardwareConcurrency as a nod to the C++11 name? That sounds reasonable. `navigator.concurrency` is not quite correct since you can have higher concurrency than the number of hardware threads.
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 4:11 PM, Ian Hickson i...@hixie.ch wrote: or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine I am not aware of this in any platforms. Can you provide one example of a platform that requests an explicit permission for access to core count? Neither iOS or Android requires any specific permissions for this information. You can create an Android application that requests absolutely no permissions that can read the core count and display it to the user.
Re: [whatwg] Proposal: navigator.cores
Adam Barth w...@adambarth.com writes: Over on blink-dev, we've been discussing [1] adding a property to navigator that reports the number of cores [2]. As far as I can tell, this functionality exists in every other platform (including iOS and Android). Some of the use cases for this feature have been discussed previously on this mailing list [3] and rejected in favor of a more complex system, perhaps similar to Grand Central Dispatch [4]. Others have raised concerns that exposing the number of cores could lead to increased fidelity of fingerprinting [5]. My view is that the fingerprinting risks are minimal. This information is already available to web sites that wish to spend a few seconds probing your machine [6]. Obviously, exposing this property makes that easier and more accurate, which is why it's useful for developers. This script pushed system load to 2.5 for 30 seconds and then estimated I have 4 cores – when running on an old Thinkpad T60 inside Chromium 33. Fact: A sticker on the laptop says “Core Solo”. /proc/cpuinfo agrees. I think it would be a bad idea to expose this information to web applications in an easier and more accurate way for two reasons: First, this enables web application authors to discriminate unduely. Web authors often try to enforce minimal specifications on User Agents if it suits their purpose. Authors often lie to make users more susceptible to tracking and advertising. Enabling authors to discriminate moves the web away from a universal medium – see for example UA string discrimination. I do not want users to see “sorry, this web page needs at least 2 cores” – it will most likely be a lie, similar to messages informing users that they need to allow cookies and JavaScript just to read a web page. Additionally, from a game theory standpoint, I think it is a bad idea to expose the processing resources a client has to applications at all. If a non-malicious application author wants to know the number of cores, then for the purpose of using as much processing power as possible. Applications that grab a maximum number of resources do not play well with other applications that may or may not follow the same strategy. I think a good real-world example how a computing system can handle constrained resources is the OOM killer in Linux. Its simple: If your application uses too much memory, it will be terminated with prejudice. Of course, authors can not know what “too much” means – systems are too diverse for that. This gives an incentive to err on the side of caution, as trying to allocate and use all available memory is most likely fatal. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Proposal: navigator.cores
On Sun, 4 May 2014, Adam Barth wrote: The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. I'm not arguing that we shouldn't provide solid APIs that allow authors to provide multi-core solutions. I'm arguing that when we do so, we should do so while protecting the privacy of users. My personal view is that the fingerprinting horse left the barn years ago. I don't believe vendors will succeed in patching the existing fingerprint vectors. For example, the WebKit project cataloged a number of vectors three year ago and has made very little progress patching any of them: http://trac.webkit.org/wiki/Fingerprinting I'm not responsible for what individual browser vendors do. Moreover, vendors are adding new state vectors all the time. For example, the HTTP2 protocol contains an explicit protocol element for persisting data on the client: http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5 I'm not responsible for what editors of other standards do. The web cannot afford to avoid exposing useful, non-privacy sensitive information, such as the number of cores, to developers out of a fear of fingerprinting. Sure we can. You don't need to know how many cores a system has, you need to know how you can make optimal use of the resources of the system without affecting other tasks that the user is running. There are plenty of ways we can address this use case that don't expose the number of cores as a reliable metric. On Sun, 4 May 2014, Rik Cabanier wrote: As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), Not quite true for Win32. An admin can install an application but a user with very limited privileges can run it and call the 'GetLogicalProcessorInformation' API to get information about the number of logical cores. Right. You have to install the application. At that point, game over. The point is that on the Web there's no installation step. This is a feature. It's one of the Web's most critically powerful assets. Microsoft did not considered an API that needs additional security. OSX is the same (and likely most other OS's) Sure. Once you've agreed to just let the application reside on your system, then you can fingerprint the user with impunity. The Web is better than that, or at least, we should make it better. Are you saying it's better that people use an estimator poly-fill? No, I'm saying we should provide an API to address the underlying use case -- making optimal use of CPU resources -- without increasing the fingerprinting risk. On Sun, 4 May 2014, Eli Grey wrote: On Sun, May 4, 2014 at 4:11 PM, Ian Hickson i...@hixie.ch wrote: or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine I am not aware of this in any platforms. Can you provide one example of a platform that requests an explicit permission for access to core count? The explicit permission is you can run on this system. On iOS, Android, MacOS, Linux, Windows, and pretty much every other platform, before you can run code on the system, the user or administrator has to explicitly install your code. On the Web, all it takes is visiting a URL. There's no installation step, there's no need for the user to click through a dialog saying running native code is highly risky. Because the Web has a dramatically lower bar for running code, we have to have a dramatically higher bar for protecting the user. Neither iOS or Android requires any specific permissions for this information. You can create an Android application that requests absolutely no permissions that can read the core count and display it to the user. No, you can't. You need one explicit permission: the permission to run in the first place. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: navigator.cores
On Sun, May 4, 2014 at 8:35 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 4 May 2014, Adam Barth wrote: The world of computing has changed since 2009. At that time, the iPhone 3G had just been released and Apple hadn't even released the first iPad. The needs of the web as a platform have changed because now the web faces stiff competition from other mobile application frameworks. I'm not arguing that we shouldn't provide solid APIs that allow authors to provide multi-core solutions. I'm arguing that when we do so, we should do so while protecting the privacy of users. My personal view is that the fingerprinting horse left the barn years ago. I don't believe vendors will succeed in patching the existing fingerprint vectors. For example, the WebKit project cataloged a number of vectors three year ago and has made very little progress patching any of them: http://trac.webkit.org/wiki/Fingerprinting I'm not responsible for what individual browser vendors do. Moreover, vendors are adding new state vectors all the time. For example, the HTTP2 protocol contains an explicit protocol element for persisting data on the client: http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-6.5 I'm not responsible for what editors of other standards do. The web cannot afford to avoid exposing useful, non-privacy sensitive information, such as the number of cores, to developers out of a fear of fingerprinting. Sure we can. You don't need to know how many cores a system has, you need to know how you can make optimal use of the resources of the system without affecting other tasks that the user is running. There are plenty of ways we can address this use case that don't expose the number of cores as a reliable metric. On Sun, 4 May 2014, Rik Cabanier wrote: As far as I can tell, this functionality exists in every other platform (including iOS and Android). This is true, but all those platforms have security mechanisms in place to mitigate the risk: you have to manually install the application, thus granting it either essentially full access to your machine (Win32), Not quite true for Win32. An admin can install an application but a user with very limited privileges can run it and call the 'GetLogicalProcessorInformation' API to get information about the number of logical cores. Right. You have to install the application. At that point, game over. No, you misunderstood. The admin install the application and has all privileges. A guest user with the most limited set of privileges can still call this API since it is considered so low risk. (This is likely also why Chrome can use it since it's process run in a very restricted sandbox.) The point is that on the Web there's no installation step. This is a feature. It's one of the Web's most critically powerful assets. Microsoft did not considered an API that needs additional security. OSX is the same (and likely most other OS's) Sure. Once you've agreed to just let the application reside on your system, then you can fingerprint the user with impunity. The Web is better than that, or at least, we should make it better. Yes, the web is like the reverse of an OS: instead of the admin/OS vendor being in charge of the machine and managing the privileges, it's the user who is in charge and who gets to decide if an application gets to use restricted features. Are you saying it's better that people use an estimator poly-fill? No, I'm saying we should provide an API to address the underlying use case -- making optimal use of CPU resources -- without increasing the fingerprinting risk. I think we already agree on that. The API should return the optimal number of concurrent threads. This doesn't need to be just related to hardware resources and I can even see it be variable depending on the state of the machine (battery - low battery - too hot - background - load) Designing a thread scheduler like one the other proposals is a different problem and much more difficult to generalize. On Sun, 4 May 2014, Eli Grey wrote: On Sun, May 4, 2014 at 4:11 PM, Ian Hickson i...@hixie.ch wrote: or you have to examine permissions that the application is requesting, and explicitly grant it the right to run on your machine I am not aware of this in any platforms. Can you provide one example of a platform that requests an explicit permission for access to core count? The explicit permission is you can run on this system. On iOS, Android, MacOS, Linux, Windows, and pretty much every other platform, before you can run code on the system, the user or administrator has to explicitly install your code. On the Web, all it takes is visiting a URL. There's no installation step, there's no need for the user to click through a dialog saying running native code is highly risky. Because the Web has a dramatically lower bar for running code, we have to
