feat(prompts): allow UAs to deny non-gesture prompts

[jyasskin]

Preview at https://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/jyasskin/permissions/gesture-may-gate-prompt/index.bs#requesting-more-permission

This allows a UA to leave the permission state at "prompt" but deny
permission requests that weren't triggered from a user gesture without
prompting the user. We don't require UAs to deny these prompts because
it would cause non-persistent permissions to require two click in
some flows that Firefox folks think should only require one click.

Fixes #77.

@mnoorenberghe @noncombatant @jan-ivar @benfredwells @martinthomson

---

Preview | Diff

[marcoscaceres]

don't we want consistency here across browsers? The "may" gives no certainty.

[marcoscaceres]

That question above was, I guess, for "Firefox folks".

[jan-ivar]

Are we presupposing here that UAs are barred from denying non-gesture prompts today? That seems false, because a user agent by definition can act on behalf of its user.

Permission prompts are the browser’s own communication with its user, and dictating such browser-chrome UX is traditionally not the domain of specs.

This spec started as a web surface, but seems to want to inflict change outside of that scope.

[marcoscaceres]

Are we presupposing here that UAs are barred from denying non-gesture prompts today? That seems false, because a user agent by definition can act on behalf of its user.

No, the question is about the behavior of calls to .request() to get more permission, and if calls should only succeed if initiated by user action.

Permission prompts are the browser’s own communication with its user, and dictating such browser-chrome UX is traditionally not the domain of specs.

Yes, but they are initiated by scripts (e.g., geolocation.getCurrentPosition()).

This spec started as a web surface, but seems to want to inflict change outside of that scope.

The spec doesn't "want" anything - the people editing the spec are just asking for input. You are making it sound like there is malicious intent in what is currently in the spec (which is not the case!). We are just looking for input to see if .request() is workable and worth keeping.

[annevk]

@jan-ivar I think what we want is something that is good for users and predictable for developers. The latter requires some consistency across browsers. That's why folks are trying to figure out the constraints.

[jan-ivar]

@marcoscaceres My understanding is that the _request permission to use_ algorithm that is modified here, is for use by other specs and not limited to .request(), hence my concern about scope.

[jan-ivar]

@annevk I find the application of gesture here misplaced and poorly thought out.

I understand we sometimes put a feature behind a gate, to preserve user intention.

User gesture is a gate.
Fullscreen is a feature.
Camera access is a feature.
Permission prompt is a gate.

Putting a gate behind a gate, is unprecedented and a bad idea, and pushes users to leave the gate open.

[annevk]

I think there's a reasonable case for both sides of the argument.

• Showing users a dialog without the user having asked for it might be confusing.
• If the user already expects a dialog (e.g., because of the domain or nature of task at hand), then having to interact with the page and then the dialog is convoluted.

What's the case for requiring user interaction with the page first?

[jan-ivar]

@annevk please see #77 so we don't discuss this twice (it mentions at least one use-case).

This was also discussed on an email thread with permission and UX people at Mozilla, where we found that deep linking (from bookmarks, links from chats and other sites) is a valid use-case for repeat visitors, which is made worse only for (most) Firefox users (since unlike Chrome, Firefox supports non-persistent grants, and offers it by default).

Importantly, it's not the feature that Google wants to restrict to a user gesture, only the (to them initial) permission prompt, so you won't hear them argue there are no use-cases.

In fact, I'm sure Google will continue to support e.g. geo-location on page-load for all repeat visitors (read: implicit persistent permission granters). The only losers are Firefox users who resist granting sites persistent access to their whereabouts (still most Firefox users, given it's default).

Will this help prevent permission spamming? In Chrome, yes (marginally, since the remedy is half-baked in that it likely only delays an inevitable prompt), because it detects first-time visits really well.

In Firefox, this dragnet fails to distinguish first-time visitors from privacy-minded visitors, so it hurts a segment that had nothing to do with spam.

[jan-ivar]

@annevk apologies if I got your question backwards, and it's for someone else.

[annevk]

The question was mainly meant for Chrome and like-minded browsers, but the reminder pointer to #77 helped (and the explanation is appreciated too, I had seen it before, but it takes a while before it all sinks in).

The problem I see with the proposal from Google to "allow different models" is that sites will likely code toward a particular model and since Chrome has way more outreach the Firefox approach likely loses over time, which seems detrimental to users who don't want to grant things persistently.

[jyasskin]

Are we presupposing here that UAs are barred from denying non-gesture prompts today? That seems false, because a user agent by definition can act on behalf of its user.

Say you call query('foo'), then you call requestFoo() without a gesture, and the UA decides to auto-deny, then query('foo') again, then requestFoo() again with a gesture, and the UA does show a prompt. What permission state did the two query() calls return?

[jan-ivar]

@jyasskin you tell me. Does requestFoo() mean "request feature X" or "request permission elevation for feature X" ? Those two seem to be conflated a lot. See also #83.

[jyasskin]

requestFoo() could be navigator.geolocation.getCurrentPosition(), for example.

[jyasskin]

For that matter, the difference between "request permission to use 'foo'" and "request that the permission state for 'foo' be increased" doesn't affect the answer here. This is about what happens before the user chooses, while that distinction is about after.

[jan-ivar]

Thanks for clarifying, though I'm still not sure this question is for me, or how its answer bears on this conversation, sorry.

[jyasskin]

@jan-ivar In #107 (comment) you asked "Are we presupposing here that UAs are barred from denying non-gesture prompts today?" The answer is "yes, UAs are barred from denying non-gesture prompts today" because there's no set of permissions states allowed by the current spec that would allow the sequence of events in #107 (comment).

"inflict change" is a pejorative way to put it, but I'm trying to specify how browsers handle permissions in general, outside the scope of the navigator.permissions object (contra @marcoscaceres' answer). I think this PR makes the spec more closely align with and describe the full variance in what browsers are actually doing.

@annevk I think you captured one of the reasons to require user interaction with the page first: "Showing users a dialog without the user having asked for it might be confusing." Other reasons are behind the links in #77 (comment).

[jan-ivar]

@jyasskin Sorry, I meant "today" as in this spec having no consensus today.

"Trying to specify how browsers handle permissions in general" is perhaps an approbative way to put that we're locking down how all future browsers are allowed to manage permissions on behalf of their users - for all features - based on how browsers manage this today. That's a change.

Is that the intention of this spec? If so, it could be made clearer, as there seems to be some confusion about what we're actually discussing among participants.

[jyasskin]

We're in the process of publishing the editors' draft to https://www.w3.org/TR/permissions/, and it'd be nice to get this relaxation in either before or soon after that. Are there any remaining objections to this PR?

[annevk]

I still think #107 (comment) is problematic. By allowing this for certain user agents, there's a huge risk that other user agents will have to change their permission model to match, to the detriment of their users.

It also ties back to trying to figure out a generic "request access" primitive, if there is such a thing. E.g., for persistent storage it's likely Chrome might never even show a dialog. So at that point you can't even rely on a generic model around request() for a single browser, since it'll vary based on the arguments you pass. That seems really icky.

[jyasskin]

@annevk I think the risk you're worried about goes like:

1. Chrome starts enforcing a gesture.
2. Developers notice that when they test on Firefox, their page doesn't work on Chrome.
3. Firefox is forced to add a gesture-enforcing mode lest developers all switch to Chrome.
4. Websites change their UI so that permissions are always requested with a gesture, so nobody's actually taking advantage of Firefox's flexibility.
5. People complain about the double-prompt in Firefox, and the number of people who select "remember this grant" in Firefox increases.
6. Firefox's UI folks give in and make "remember this grant" the default.

Is that right?

I suspect Chrome's security team is going to insist on the gesture even if the spec disallows it, but we could wait to make the spec allow it until that's a change to reflect reality.