- From: Lukasz Olejnik via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Nov 2016 21:05:42 +0000
- To: public-device-apis-log@w3.org
>> 1 vs 3. Same error, different response times ;-) > No, that's incorrect. 3) has different error types for missing sensor (NotReadableError) and rejected permission request (NotAllowedError). You are right (sorry), I treated it as the same as functionally it would be the same due to timing. > Well, do we? This is a tradeoff between UX and fulfilling use cases on one side and increasing the browser's fingerprint by one bit per permission group on the other. Not sure now how many bits, depending on the future. > Can you be a bit more explicit here, and actually provide algorithm steps? I don't see how you'd make 2) look more like 1) without loosing the error distinction which is the part we're interested in. The following idea would be using something along the lines: Option 2a (or 1a? or 1.5) 1. Site requests permission 2. If the sensor exists, UA prompts the user, all is fine. If the user rejects, return _NotAllowedError_ 3. If the sensor does not exist, UA is not prompting the user, but it throws a _NotReadableError_ **after a random delay**. Basically **Option 1.5**, with additional compromise (compromise is on privacy, UX is better, no prompts if sensor exists). I know it's not warranted by any spec-like features (i.e. Permissions API), so it's probably in hands of implementors. It's still a trade-off (better UX, still more acceptable privacy layer; bonus points, if a browser vendor will propose inadequate random-delay choice in an implementation, someone can even make an academic paper! ;-) - I wonder if they would provide a reference to this thread). Caveat: some information would still be leaking, but less than in the case of immediate informing that a sensor does not exist, or allowing to check if it does. I guess a spec-legit alternative is to just propose Option 1 and also document that it increases fingerprinting surface and suggest browser vendors to choose Option 1.5 if they wish. That said, in my opinion API calls should be fenced with permissions. -- GitHub Notification of comment by lknik Please view or discuss this issue at https://github.com/w3c/sensors/issues/145#issuecomment-260767801 using your GitHub account
Received on Tuesday, 15 November 2016 21:05:49 UTC