A more modest request()

[annevk]

We've been looking at orientation/motion events yet again and the idea came up to permission-gate them. For this having something like request() with a simple string value seems useful.

Another case that keeps coming up is the clipboard. See w3c/clipboard-apis#51 for the latest discussion there.

Perhaps rather than an open-ended request() method, we could start out with just a couple simple values for which everything is known, rather than try to support all permissions. I hope that might address the concerns raised in #83. So we basically would use request() when there's no better alternative.

(I'm not sure where the initial email went, but here is the recent thread on restricting orientation/motion events: https://groups.google.com/d/msg/mozilla.dev.platform/1YdMiVQ2zaU/UOocyiTzDwAJ.)

cc @ehsan @martinthomson @garykac @jan-ivar @jyasskin @marcoscaceres

[jyasskin]

@raymeskhoury Are you the right person to talk about how Chrome's doing permissions for the Accelerometer/Gyroscope/Magnetometer/Light Sensors? My memory's that we're exposing information via permissions.query({name: 'accelerometer'}) and showing a prompt in response to Sensor.start() if needed.

w3c/sensors#183 with @reillyeon and @anssiko appears to have decided not to deal with high-vs-low precision yet, in order to dodge the permission question.

In general, I weakly prefer APIs like requestAccelerometer(...) over a generic-looking request({name: 'accelerometer'}) if the generic-looking option doesn't actually work generically. I'm open to arguments that the generic-looking one is better though.

[anssiko]

For Chrome permissions UX learnings and implementation plan for the concrete low level sensors that decompose orientation/motion events, see https://docs.google.com/document/d/1XThujZ2VJm0z0Gon1zbFkYhYo6K8nMxJjxNJ3wk9KHo/mobilebasic

Re @annevk’s comment in https://groups.google.com/forum/m/#!msg/mozilla.dev.platform/1YdMiVQ2zaU/UOocyiTzDwAJ:

it would be good if we could get orientation/motion events maintained somehow then so this can just be put in that document

The maintenance issue will be fixed soon, see w3c/das-charter#31

cc @alexshalamov @pozdnyakov

[jan-ivar]

@annevk I agree with @jyasskin on requestAccelerometer. In my view, it's less a request for permission elevation, more a request to turn on the accelerometer (now or forever).

The difference might become apparent if we wanted a stopAccelerometer (e.g. to encourage saving resources). A site would probably want to call that without giving up permission.

The specs pointing here seem to have in common that their feature is the firing of certain events, for which there is no obvious control surface or configuration options (at the moment).

[reillyeon]

@jan-ivar The Generic Sensors API already has start() and stop() methods on the sensor objects which satisfy that requirement.

I'm curious what @jyasskin thinks is not generic about the sensors permission request. Is it that it could be requesting permission for a particular frequency or precision? Could that be included in the PermissionDescriptor?

[jyasskin]

@reillyeon Sorry for being unclear. I understand @annevk as suggesting that we add a permissions.request('accelerometer'), where developers could only pass a subset of PermissionNames to this request() function. Leaving out permissions like "notifications" is what's not generic.

I believe the Mozilla thread is talking about constraining the old devicemotion events. The new Generic Sensor-based sensors already have natural places to insert the permission request, so maybe we don't need a new request function for them.

... Given that, is there value in asking developers to call a new function in order to keep using the old events? Should we just encourage them to move over to the new API instead?

[raymeskhoury]

Just to share my 2c on request():

1. I've come to the view over some time that having a generic request could be a useful thing if designed well.
2. There's a lot of history to it, so I think making progress is going to require a fresh look at it, the problems it addresses and the tradeoffs. We need to go about the discussion in a different way than in the past and I think we would benefit from someone championing it and an explainer document.
3. I agree with @annevk in that starting with an API that is specified for a small subset of permissions would be a good approach.
4. I feel quite strongly that we should avoid a request function that has no return value. The result of requesting access should be a handle to the capability which was requested. There's 2 reasons why I feel strongly about that:
   a) Because it makes API usage very clear to developers
   b) Because it gives UAs full control over the scope of the permission grant and it makes that scope very clear to developers. It deals with a concern previously raised that request() would not support a single-use permission prompt model.

(4) may mean that request() does not fit in with the current design of many APIs but I think we need to think about the direction we want to head in the future and then consider how/whether to move older APIs to that future.

[annevk]

Should we just encourage them to move over to the new API instead?

Does anyone other than Chrome implement the new API?

Anyway, I'm happy with just going with more specific methods instead. I don't really care much for a generic variant personally.

[garykac]

@raymeskhoury
With respect to item 4, how do you think that should work for clipboard?

We have navigator.clipboard, so that people can call clipboard.read() and clipboard.write() and have the permissions checked just before the resource is accessed. These methods would request read and write clipboard access, respectively, as needed.

But we also need a way to request full access[1], and since there is no clipboard API that requires full access, it would need to be done in some sort of clipboard.request() method.

But I don't think it makes sense for this clipboard.request method to return a handle to a resource. Would it just return navigator.clipboard? Because returning a handle like this implies that the handle defines the scope of the access, which would not be true in this case.

And if we remove navigator.clipboard and require that a clipboard handle be requested beforehand, then that undermines the model that @martinthomson discusses in #83.

My preference is for there to be a clipboard.request(), but I don't think it makes sense for it to return a handle to the clipboard.

[1] Note: full clipboard access would grant read/write clipboard access without requiring a user gesture.

[annevk]

@garykac the request() method could return a promise that fulfills with https://w3c.github.io/permissions/#enumdef-permissionstate or some such.

[jan-ivar]

But we also need a way to request full access[1], and since there is no clipboard API that requires full access

@garykac Is "full" access merely persistent read() + write()access?

If so, then how often to bother users with prompts seems like a UX decision to me (between the user and its agent). We could also encourage UAs to merge prompts within a narrow window of time.

[raymeskhoury]

Thanks @garykac
I'm not suggesting this for the clipboard API (I think that would be disruptive). Rather, I'm suggesting that we rethink how we design such APIs in the future. But if we were to apply this to the clipboard API, the idea would be like you suggest: removing navigator.clipboard and returning a handle to the capability in a promise. I disagree that this undermines the model discussed in #83. In fact, I would argue that it better adheres to the philosophy described in #83. Namely, if you merely have a clipboard.request() function that returns no promise, it conceptually separates user consent from usage (which was the problem described). If you have a request() function that returns a promise to a handle, you're in a situation where requesting permission and resource acquisition are tied together as suggested in #83:

I believe that coupling of request and consequence to be important.

Actually I think it's helpful to get away from the word "request". It has too much baggage associated with it now. Adding a generic request() function is not intended to separate consent and acquisition. It would be intended intended to standardize API design for APIs that require getting a handle to some system-level capability that may require user consent. This is a pattern that we're seeing come up more and more and solutions tend to be ad hoc.

[marcoscaceres]

As request() is no longer in scope, and as the newer device APIs already have a means of requesting permission, I'm going ahead and closing this.

NB: the ability to use a enum for .query() where possible is still a nice ergonomic edition.