-
Notifications
You must be signed in to change notification settings - Fork 32
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
Do we really need 3 permissions policies? #162
Comments
The separate permission names reflect the fact that this API includes events that require access to different underlying sensors which represent a spectrum of potential privacy impacts (e.g. magnetometer can be more privacy sensitive than accelerometer). |
Right, I get the rationale, but it's more about in practice what it means and how that's communicated to users (as well as developers). That is, it's difficult to communicate "a magnetometer can be more privacy sensitive than accelerometer" to both developers and users - when either doesn't actually care which sensors are being accessed to produce the "device orientation"... it's all just "magic" 🪄 (some new "quantum gravity motion super position sensor 3000"™️ could be invented tomorrow to do the same thing as the three sensors). I'm worried that trying to use 3 different permissions is trying to be overly clever, when it could just use one (or two at most). My other worry is other APIs trying hang on these permissions (or redefine them!), which is even more confusing... looking at "magnetometer", for example. That doesn't seem great. |
Filed w3c/magnetometer#73 to fix the duplicate definition. The other Generic Sensors specs don't have that bug and their reuse of permissions defined by this specification seems appropriate. |
I've submitted w3c/magnetometer#74 that hopefully fixes the dupe. |
It still feels really wonky to have 3 permissions policies at play, which can be seen throughout the spec's:
This appears to be an issue because of #180 (i.e., abstract away the sensors). It appears that the only real reason to have the 3 policies is because of the Gyroscope, Accelerometer, and Magnetometer specs. If those are folded into this one, the three policies no longer make sense (as they also don't really make sense from a permissions UI perspective). Does Chrome use a single "motion sensors" site setting UI permission for this? If so, my point stands in that users can't ever set "I just want X, but not Y, and allow Z" so the three policies don't make a lot sense from a permission perspective. What am I missing? |
(more notes as I dig into this) On the Safari iOS side, there is no UI for controlling the permission. Instead, the permission is on session basis and reset once the user destroys the window. I think this also goes to the case for not requiring multiple permission policies: in as far that, again, a user has no way to control this permission via UI (let alone each individual permission). I'll check what Firefox does... |
Just also noting that WebKit requires all three permissions.... I'm unsure if this a feature or bug: My gut feeling is that |
That seems somewhat excessive. Can we just consolidate down to 1 specific for this API?
It's also seems problematic that if the user gives permission for one API, you are enabling potentially for other APIs.
The text was updated successfully, but these errors were encountered: