- From: Carr, Wayne <wayne.carr@intel.com>
- Date: Fri, 25 May 2012 20:09:03 +0000
- To: "public-sysapps@w3.org" <public-sysapps@w3.org>
- Message-ID: <52F8A45B68FD784E8E4FEE4DA9C6E52A3FBA48AE@ORSMSX101.amr.corp.intel.com>
There are cases in the Browser where the server knows the identity of the user and they have a trusted relationship. In those cases, fingerprinting concerns do not apply. An example is a web page where a user interacts with their mobile phone account from their mobile phone. The server really does know who they are and what device they are using. It would be OK for JavaScript to know they're connecting over wifi or what sensors they have. I would hope that some of these System Level APIs could be adopted in Web Browsers, but be unavailable unless it is for a web page where the user allows it in some way. Like using Do Not Track or log in where the user agrees that server can know about the device. Otherwise, we’re preventing capabilities to avoid tracking where there isn’t going to be any tracking or the user wants it. It would be something to consider in APIs -- a variant perhaps in some APIs that would be appropriate for in the browser for use with trusted web sites (but not including apis that erase the disk). It isn't crucial, because it should be possible to use standalone apps instead (we hope), but may be worth considering. It would be useful to know, for instance, what the level is of WebGL performance to know if you should even try to display something (rather than have the experience where the display is so slow it clearly appears broken). But that will be blocked due to fingerprinting. It shouldn't be if the user is logged into some game site where they want the site to pick games appropriate for their hardware and where the site has promised to use information only in ways the user has approved. Should something related to this be in the charter?
Received on Friday, 25 May 2012 20:10:36 UTC