- From: Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com>
- Date: Tue, 29 Mar 2016 11:49:59 +0200
- To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>, W3C Device APIs WG <public-device-apis@w3.org>
- Message-ID: <CAC1M5qp5wyb5iZkBtmnxQdwYwVKOB-32YPVfeZ06E6kqHoyGTA@mail.gmail.com>
Dear all! I am working on a sensors privacy (impact, risk, ...) assessment for a while now. And I think now it has little sense to withhold it for any longer, as most of the work I did some time ago, anyway. It is primarily intended for Devis APIs WG (DAP), with whom I have the pleasure to work on the privacy aspects of sensors API. I invite you to take a look on the document [1]. I hope it will be useful, and I primarily hope this can be an appropriate starting input in privacy considerations of sensors. Often, as indicated in the PDF report, even perhaps far-fetched scenarios are considered. Same for cross-device risks, where plausible scenario could be pointed to. As advised in private correspondence with (and by), Tobie Langel (DAP), it would be good if specific pull(s) request(s) follow. I'll look into that next. Also of note. It is not included in the PDF (should it?), but I believe it is worthy to require a secure (i.e. TLS) connection for having access to sensors ('secure contexts') - all of them, generically and just like that. I can't imagine a scenario where this could cause any issues, apart from the need to set up a TLS, that is. I also highlight my view and want to ask a question. Can W3C give guidance/recommendation/note regarding the transparency UIs (sometimes called "privacy user interface")? A method for a straight-forward user-verification of: what/how was being used, how frequent, etc. Please, enjoy ;-) Best regards Lukasz Olejnik [1] http://lukaszolejnik.com/SensorsPrivacyReport.pdf
Received on Tuesday, 29 March 2016 09:50:30 UTC