- From: Robin Berjon <robin@w3.org>
- Date: Mon, 10 Sep 2012 12:05:47 +0200
- To: Tobie Langel <tobie@fb.com>
- CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
On 08/09/2012 22:17 , Tobie Langel wrote: > On Sep 8, 2012, at 20:01, "Carr, Wayne" <wayne.carr@intel.com> > wrote: >> I assumed Marcos meant just the onxxx attribute on Window (not >> addEventListener which always is there). All of these type specs >> add onxxx on Window. For fingerprinting reasons, it seems you >> don't want it there just when there is a sensor. So either always >> there for all of these type specs, or don't use that at all and >> just use addEventListener. (this is about all of these, not this >> draft in particular). > > How do we reconcile developers relying on feature detection and > avoiding device fingerprinting at the same time? We don't have an answer for that — both are right. In the simple case you can work without feature detection. That's the case with vibration, and it's also the case if the developer can simply show a "waiting for data" message (or not show the atmospheric component at all) until some information arrives. But if what you want to do is to use the device capability if it's there, and if it's not prompt the user for her geolocation in order to acquire the pressure from a weather service you're screwed because you don't want to trigger the geo permission for nothing, and you don't want to wait the amount of time it takes to be sure that your sensor has woken up if it's there (which could be multiple seconds). It's just speculation, but I've been wondering if we couldn't just turn the tables on fingerprinting. In order to get a decent fingerprint, you need to look at a decent number of properties — not just a small few. I wonder if UAs could not detect that, and flag the responsible site for review in things like the SafeBrowsing DB. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 10 September 2012 10:05:57 UTC