- From: Frederick Hirsch <w3c@fjhirsch.com>
- Date: Fri, 8 Apr 2016 19:57:46 -0400
- To: "Lukasz Olejnik (W3C)" <lukasz.w3c@gmail.com>
- Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>, W3C Device APIs WG <public-device-apis@w3.org>
Lukasz much thanks. I have a few comments re your document: it is deliberate not to use RFC 2119 language in the security and privacy considerations since they are non-normative. Implementers should heed advice and take responsibility but they also have to be able to make tradeoffs considering the context (business and otherwise). Privacy is not solely a technical problem, part of the reason for this. it might be useful to understand how much effort is needed to do behavioral analysis; (the security analogy is that of whether you are dealing with script-kiddies vs the 'Andromedan' (1) government agencies') Permissions are hard when considered with usability, new information/ideas in this area might be worth discussing more also comment inline below much thanks for this work regards, Frederick Frederick Hirsch www.fjhirsch.com @fjhirsch (1) 'Thinking Security' reference > On Mar 29, 2016, at 5:49 AM, Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com> wrote: > > 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. > will all sensors have the resources/capability/cost-performance to perform TLS? > 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 Friday, 8 April 2016 23:58:21 UTC