search

w3c / sensors

Generic Sensor API
https://www.w3.org/TR/generic-sensor/
Other
127 stars 59 forks source link

Integrate Permissions API changes #416

Closed anssiko closed 2 years ago

anssiko commented 2 years ago

Remove references to enum PermissionName and refer to powerful feature 'name' dfn instead.

Helps with https://github.com/w3c/permissions/issues/263

Preview | Diff

anssiko commented 2 years ago

cc @miketaylr @rakuco

anssiko commented 2 years ago

@reillyeon @rakuco here's one detail I want you to pay attention to in your review:

This PR implicitly defines any Generic Sensor-based API as a powerful feature via the "name" reference linking back to "a powerful feature is identified by its name". A powerful feature is currently defined as follows (emphasis mine):

A powerful feature is a web platform feature (usually an API) for which a user gives express permission before the feature can be used. Access to the feature is determined by the environment settings object by the user having granted permission via UI, or by satisfying some criteria that is equivalent to a permission grant.

https://www.w3.org/TR/permissions/#dfn-powerful-feature

A possible issue may arise if the powerful feature definition changes in incompatible ways or if this language is interpreted differently.

Technically, Generic Sensor API is not a powerful feature. It can be extended to create a powerful feature or a "powerless" feature.

A solution might be to state that for Generic Sensor API the "criteria that is equivalent to a permission grant" (this could become a dfn so it could be referenced) is https://pr-preview.s3.amazonaws.com/w3c/sensors/pull/416.html#concepts-can-expose-sensor-readings that allows extension specs to add additional conditions. This also allows implementers to innovate in terms of UX.

Thoughts?

@marcoscaceres for Permissions API.

rakuco commented 2 years ago

My understanding is that this particular change wouldn't be a "regression" or behavior change, as to me it look as if we're just using the term name instead of permission name for the same concept. The Generic Sensors API as in this spec doesn't define any powerful features itself, but the specs using it (may) do, which also sounds OK to me.

The crux of the matter here is that "criteria that is equivalent to a permission grant" gives implementations quite a bit of leeway AFAICS -- I wonder if Chrome's current implementation of granting access by default without asking users would count as such even though it's the opposite of "granting permission via UI".

anssiko commented 2 years ago

Thanks for your review @rakuco and @reillyeon.

I'm landing this and the following concrete sensor integrations that currently appear in the powerful features registry defined in the Permissions API:

https://github.com/w3c/ambient-light/pull/71 (a tweak to the earlier patch) https://github.com/w3c/accelerometer/pull/62 https://github.com/w3c/gyroscope/pull/47 https://github.com/w3c/magnetometer/pull/61

We may need to clarify the "criteria that is equivalent to a permission grant" in the future, possibly on a per concrete sensor spec basis. That change we need to carefully coordinate with implementations to stay in sync.