Do we really need 3 permissions policies?

[marcoscaceres]

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.

[reillyeon]

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]

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]

Filed https://github.com/w3c/magnetometer/issues/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]

I've submitted https://github.com/w3c/magnetometer/pull/74 that hopefully fixes the dupe.

[marcoscaceres]

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.
• attempt to combine multiple permission into a single UI #183

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]

(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]

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