Re: [sensors] granularity of Permission name for concrete/ fusion sensors

> If we want to make high-level sensors no-permission, let's first 
define the extent of no-permission readout (i.e. precision, etc).

We don't. We might do so for very specific cases, such as light-level 
(where the reading is an enum with 3 values), UserProximity (where the
 reading is a boolean), but otherwise, no.

> As for the fusion - ability to read from a number of sensors 
simultaneously, it's catchy to think how to define those, i.e. to 
avoid permissions such as "all" (grant all by default). I agree it 
would be nice from a usability point of view to stack permissions 
under a different name (e.g. "motion sensors"), although it doesn't 
mean that other sensors can't contribute data suggesting user's motion
 patterns ;)

We've decided to go with find-grained denomination for permission 
names, and let UA combine those as they wish to show more 
user-friendly messages.
 
> Perhaps let's think of a (perhaps separate?) note with informative 
suggestions and guidance, i.e. also related to transparency. Like 
perhaps Note on Sensors Accountability, or Privacy even, or so? […]

This is something you should take to the list.



-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/132#issuecomment-257709655 using
 your GitHub account

Received on Tuesday, 1 November 2016 21:50:56 UTC