Re: Privacy report on sensors, for generic sensors API.

Hi!


2016-04-09 1:57 GMT+02:00 Frederick Hirsch <w3c@fjhirsch.com>:

> 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.
>

Thanks. I will keep that in mind. However,  I think for clarity reasons I
will want to keep it there (unless rewrite it). I am also taking the advice
here
https://www.w3.org/TR/2016/PR-battery-status-20160329/#security-and-privacy-considerations



>
> 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')
>

Definitely. That's why I also tried to see the far-fetched scenarios.
Even if, we might mention them, or include that "this is a thing, but the
actual behavior is unexpected".
That said, for behavioral analysis, only receiving data would be needed.


>
> Permissions are hard when considered with usability, new information/ideas
> in this area might be worth discussing more
>


I believe there definitely should be  a way of doing so... Why not consider
the introduction of levels of permissions (as in the report), for example?
And then go with some defaults. Then, basing on the default settings, do
not prompt the user about permissions for certain sensors marked as perhaps
"minor risk". Something akin to the old 'security zones' in, yes, Internet
Explorer (AFAIR).

As for TLS - we are speaking about network connections, where accessing all
the generic sensor APIs would be allowed provided the client connected to
the server through TLS. It is already being done with geolocation, if I
understand correctly...