-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relation to Permissions API #183
Comments
{Low,High}-Resolution mode has 2 facets:
Without Permission the user gets ->
With Permission the user gets ->
Argument: If it is already behind permissions why still clip data or frequency? (numbers are just for illustration purposes, UA needs to set its threshold after "user-studies" , as is the case with rounding factor, UA defines its own "big" and "small"). Edit: We need some more research to come up with any numbers for Accelerometer, Gyroscope and Magnetometer. Papers: |
We (me and @alexshalamov) have a concern that introducing of low(high)-resolution mode will be quite confusing for web developers who will not know exactly which permission token is required for the functionality they intend to provide. Moreover, definition of high / low thresholds by the UA, would lead to fragmentation between browsers. Also for motion sensor we can hardly find a ‘safe’ zone for both frequency or accuracy (#98 (comment) ), search papers [ ALS, Motion sensors, Gyro ] tell that there can be vulnerabilities even at low frequencies. For ALS we do not really have the use cases requiring accurate readings (@tobie do we?), even rough data (10 - 100 lux accuracy) shall be enough for example for updating a web page style based on the surrounding illumination. We believe that for any sensor type the returned data can be rounded to the values which are good enough to implement the use cases, if it improves user’s security/privacy (this UA can decide), but there is no actual need for introducing any extra modes and permission tokens. |
I don't really have an opinion, here. My involvement with ALS has been limited to rewriting the existing spec to rely on the generic sensor API instead. As far as I'm concerned, all the use cases I've seen don't require more than an light-level inspired enum. Maybe we should drop ALS for now (that is, until we find more conclusive evidence of its need) an release an enum-based, mediaquery-matching |
WRT to resolution mode, for ALS the situation seems easier to handle; it's ALS vs LightLevelSensor. We could go with just exposing the second one for now, with a dedicated permission descriptor. Then if we find legit use cases for ALS, figure out how to make those descriptors work together. |
Couple of options. I'm hearing preference toward option 2. What is your preference? (The names are just placeholders, no need to bikeshed.) 1) Add Low-resolution mode:
High-resolution mode:
2) Dedicated constructors: Low-resolution mode:
High-resolution mode:
3. Something else. [1] |
Nonetheless, liaising with the CSS WG would be important before moving ahead with this. |
I've explained my position about this issue here: w3c/ambient-light#23 (comment) And in particular:
In short: we need to find an acceptable solution for motion sensors. If we don't the whole exercise is moot (we'll basically have failed). If we do, we can probably use that solution as is on ALS. In the meantime, we may attempt to move forward with LightLevel instead, but if we do this will imply liaising with the CSS WG. This might considerably delay us. I recommend:
|
Sorry for spamming this issue with ambient-light specifics in #183 (comment) -- my bad, I thought this was the ALS repo :-/ Let's continue the ALS specific discussion over in w3c/ambient-light#23 where the context is. |
From a permissions standpoint I agree with the sentiment above. I would much rather avoid having low/high precision modes if we can avoid it. It's complicated for developers and for user agents and I'm not convinced of the value of it (e.g. that it enables additional use cases or provides better security/privacy). |
Revisiting this issue after some thought, I now feel the low/high precision mode and related machinery should not be exposed to the web developer direct. I'm not yet sure whether allowing some implementers to toggle such a mode as a side-effect of a permission state would be a smart thing to do or whether that would in fact lead to interoperability issues across implementations. @reillyeon you said:
Did you mean the granted permission state could be taken as a hint for high precision, or that an explicit extension to the permission descriptor à la the enableHighAccuracy flag of the Geolocation API should be added? If the latter, I'd like to understand how well that has worked in real life for geo and what the web developer feedback has been to date. My recollection is there has been issues with it, but I don't have a pointer at hand to backup my claim. |
So you have three different cases here:
Additionally, for this to be effective, you have to incentivize developers to pick the more secure option when they don't require more precision, e.g. by making the permission opt-out vs. opt-in. This implies that the threat level difference between high and low precision must be important enough to warrant this difference in treatment. Developer incentive was completely missing out of the geolocation Agree with @anssiko that making the precision distinction isn't necessarily something that should be exposed as is to the end-user. As mentioned above, this could be also done in certain cases with different permission names, high-level vs. low level sensor types (e.g. pedometer vs. access to low-level motion sensors), or UA level distinction (e.g. opt-in vs. opt-out permissions; available across the web vs. only available on installed PWAs). Finally, while this is something that probably needs to be defined at the generic sensor level, whether it's useful to a given concrete sensor needs to be defined at the concrete sensor level. |
So far it was agreed to proceed with the implementation without low/high precision modes. Moving this issue to level 2. |
Discussions of the privacy considerations of this API have floated the idea of a low-resolution mode which does not require a permission, and a high-resolution mode that does. While the definition of low and high resolution should be left to the User Agent there should be a well defined interface for determining whether the user has granted permission for high-resolution mode. This can be done through the Permissions API.
The text was updated successfully, but these errors were encountered: