Re: [w3ctag/spec-reviews] privacy of sensor other exotic APIs (#129)

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](https://github.com/lknik?tab=activity) or [my blog](https://blog.lukaszolejnik.com)). 

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, brower 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](http://ieee-security.org/TC/SPW2016/IWPE/). In this case, we might think of additional ways. 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/129#issuecomment-239101784