privacy of sensor & other exotic APIs

[torgo]

e.g. https://blog.lukaszolejnik.com/privacy-of-w3c-vibration-api/

[torgo]

Looping in @lknik. Lukasz we discussed this and the topic generally on today's call - see minutes. The main question that came up: is this kind of thing being addressed well enough in W3C Privacy Interest Group - e.g. https://w3c.github.io/privacy-considerations/ or https://w3c.github.io/fingerprinting-guidance/ ? Some feedback from @npdoty might be helpful as well...

[lknik]

Hello,

Thanks for letting me know. I will be happy to provide my input in this and other cases.
First of all, thank you very much for kind words. This is really motivating. My aim is to provide as much help as I can.

Indeed, I am an IE in DAS, and also PING. Currently my main focus is put on sensors privacy and the related issues. I generally tried to organize the workflow to analyse the new APIs one after another (for example, please see here GH activity or my blog).

I am thinking of several ideas, relating to Permissions, transparency (including browser UIs) and research process. And I do believe a there should be an incentive for active research.
I will highlight them here in a short form.

Ideas for Web privacy

1. Granular Permissions. By default, all APIs are subject to permissions.
2. API Auditing and Transparency. Browsers log all the uses/accesses of APIs. Users can browse them, browser or plugins can easily access this information to e.g. detect abuses.
3. Transparency. Browsers clearly display relevant information to the user.

Point (1) will not cause a pop-up fatigue, because browsers will start with sane configuration, for example reflecting the default (current) situation. However, user should be able to choose to set multiple levels of verbosity, i.e. if the user wants to receive dialogs, he can configure his browser to respect the user's setting. This should also be done on a per-API basis. For example, users wishing not to be ever bothered with dialogs could set "allow always" if they are not concerned, or "deny always" if they do not wish to provide any access, to anyone. The main issue is on the browser UI side. I believe W3C is still in position to provide a guidance here.

Point (2) will allow to detect fingerprinting attempts, which currently are not easy to observe. Moreover, this would be a pro-active measure. In other words, ALL sensitive APIs need to declare that the browser either SHOULD or MUST make the API subject to auditing/transparency.

Point (3). Data on the current use should be clearly displayed to the user. This is entirely at browser vendor's discretion. Remember the time when the use of geolocation API was not clearly marked? Well, we're here with many APIs now. Bonus points for designing a framework working on mobiles and WoT devices.

In addition to that, I am currently consider to write a dedicated W3C Note relating to sensors API (Following a discussion on DAS list).

Research motivations.
I like how in the minutes you discussed research matters. PING has an impressive questionnaire
to help PING members to assess the sensitiveness. The issue is, some forms of privacy analysis/fingerprinting might be - currently - "esoteric", this is still an active research are.. Privacy is also not just fingerprinting or tracking. I believe that the key is to design future-proof APIs with privacy engineering standards, thinking outside-the-box, some form of attacker-like mind-set.

I would suggest an idea of holding a regular (research) workshop/conference on W3C Privacy (why not hold the 1st edition in London or Paris, soon ;-) ). I would be very happy in helping with chairing, organization, writing description, call-for-papers, reviews, spreading the word, etc. I would go to great lengths to help here. I understand there is already a dedicated track along WWW, but if I understand correctly in the current form it would not be relevant to our goals of understanding Web Privacy, in particular implications from/to standards and browsers. The situation might be similar for IPWE. In this case, we might think of additional ways.

[torgo]

Discussed at Tokyo F2F & agreed to put some text into the design principles document around this stuff. We feel that focusing on writing down API and Spec design principles regarding privacy (and garnering wide review of these) would be more productive than a general workshop at this time.

[travisleithead]

Design principles related issue: w3ctag/design-principles#37

[torgo]

Agreed to close this issue because further work on this topic will happen in the design principles doc.