You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
It still feels really wonky to have 3 permissions policies at play, which can be seen throughout the spec's:
for loop permission checks, and constantly checking if one or the other has changed. This means potentially having multiple UI options (3x!) which would be super confusing. If a user turns one off, it would break the other two in the case of "absolute" etc.
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.
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).
My gut feeling is that .requestPermission() should take an argument {absolute: true} instead of relying on the third policy (again to decouple and abstract it away from a specific sensor).
Activity
reillyeon commentedon May 2, 2024
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).
marcoscaceres commentedon May 3, 2024
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.
reillyeon commentedon May 4, 2024
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.
anssiko commentedon May 7, 2024
I've submitted w3c/magnetometer#74 that hopefully fixes the dupe.
marcoscaceres commentedon May 19, 2024
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?
marcoscaceres commentedon May 20, 2024
(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...
marcoscaceres commentedon May 20, 2024
Just also noting that WebKit requires all three permissions.... I'm unsure if this a feature or bug:
https://bugs.webkit.org/show_bug.cgi?id=271891
My gut feeling is that
.requestPermission()should take an argument{absolute: true}instead of relying on the third policy (again to decouple and abstract it away from a specific sensor).