Re: [push-api] Add optional userVisibleOnly parameter to register & hasPermission (#87)

I've shopped this idea, and variations on it, around a bit.  I've now talked to a bunch of people about what their expectations are and it's clearly not a straightforward decision.

I should say that I'm not responsible for making a final determination from a Firefox perspective; we're still very much in the process of working out what we want from this feature at the product level.

### First, the negative reactions

The reaction to a having multiple levels of consent grant for a single capability was generally negative.  I think that this was because it wasn't clear that it was possible to communicate the difference clearly.

Even in the conversations I had, it was often the case that the distinction between "push notifications" and "notifications" (i.e., toasts or equivalent) was confusing.  Language matters, so I've been using "run in the background" and "display notifications" as the names of capabilities we're talking about.  

I also found it hard to convey the full range of subtlety in the proposed UX to some people who are highly technically adept, so I worry that it might be a little hard to explain this to web developers and users.

### Consent and feedback

The overwhelming majority of people think that we should have some sort of consent, but that the consent for "running in the background" (hereafter, just "push") and "displaying notifications" need to be orthogonal.  How orthogonal varied though; it certainly wasn't clear cut.

The amount of concern over the ability to periodically trigger requests was - on the whole - low.  Though generally understood to be a concern, it wasn't considered to be qualitatively worse than the resource consumption concerns (i.e., access to CPU and storage).  As long as there is some elevation process from random drive-by origin, most people were OK providing push, though there were some exceptions.

One of the key points I took away was that feedback was hugely important, but the nature of that feedback might vary. Toasts, or visible notifications in that vein, are just one such option.  I had some fairly positive discussions about feedback in a more general sense, which I think is the right direction to be taking the discussion.

In particular, Anne van Kesteren had some good ideas and information.  There is no consent process for access to storage for sites.  I believe that current designs don't even enforce a quota (this might change). Instead, the idea there is to provide feedback in the form of a display, showing how much capacity each site uses.  Coupled with a notification when storage capacity crosses certain thresholds, users are left in control (they can clear state for a site), but they aren't burdened with consent choices.

A similar system of feedback for push would significantly reduce the load on the consent process.  Currently, the implication is that a bad choice exposes the user to indefinite tracking and expenditure of resources.  From that perspective, I can understand the desire to somehow limit this exposure.  A goal of clearly communicating what is going on and providing immediate controls is what I'm trying to head towards.  I don't want that to be only a long term aspirational goal though, because stop-gaps have a way of shaping the landscape, sometimes in negative ways.

### Options

Here are what I think the options are for the permission model.

#### 1. Graded permissions

Two levels of permission grant for push, as proposed.  The proposal elevates the two levels to become a first class part of the API.  What I'm hearing implied in this proposal is a desire to see if it is possible to gradually eliminate the real differences between the levels, but please correct me.

I'd like to see the expectations around each level - particularly this intermediate stage - be expanded considerably.  When we we discussing this, it seemed like the system of enforcement or penalties was still a little nebulous.  If this is going to hit the API, then it needs to be very clear what an application can expect from the browser when it opts for each level of permission.

#### 2. One permission

A single "run in the background" permission.

This option would be entirely orthogonal to the other permissions in the system.  If you want to generate visible notifications, then consent for the notifications API needs to be acquired separately.

#### 3. Some interaction with notification consent

There are a few variations on this one.  Basically, the idea is that if a site has acquired consent for this (related) feature, then it's OK.

Part of the rationale for these options is the close conceptual relationship between the push and notification features.  There is also a theory that users expect to receive notifications from sites when they aren't visiting them, and might be surprised to learn how infrequently this is actually true.

If you consider the two identified classes of permission we are talking about (push visible and push invisible), plus an existing consent for notifications, you can cover the space almost exhaustively:
* a. If you can generate notifications, then you can run in the background.  There is no separate permission.
* b. If you can generate notifications, you can run in the background, but if you don't generate a notification, the browser will generate a generic one for you.  Getting complete push access requires a separate permission, but you need to acquire notification consent separately.
* c. A push access permission implicitly grants consent to generate notifications.  The notifications permission only covers the case where an open window/tab generates a notification.
* d. b., but with push consent implying notification consent, like c. instead.

One person I talked to about UX was particularly in favour of ensuring that notifications are kept separate from background running, even if the notifications weren't being generated by an active window/tab.  Option b here sort of covers that.

#### (Extra) Options for limiting exposure

There are alternative approaches to reducing the cost to the user of a bad consent choice.  A consent grant doesn't have to be permanent.  If the use of a push notification service were limited in time or uses (or both), then any mistake is similarly non-permanent.

Any limited budget might be refreshed if the site is visited (i.e., the top-level browsing context hits the origin).

When the subscription expires, deliver a `pushregistrationlost` event to the SW that terminated the push subscription.  This event might need to be augmented to have some sort of indicator that the error is unrecoverable.

You can imagine getting arbitrarily inventive with the accounting of time, visible and invisible pushes.

### My preference

The general idea of having API surface as a protection measure still grates, though I can appreciate the concern.

I'm also concerned about creating a perverse set of incentives whereby applications generate user visible notifications when they aren't otherwise necessary or desired.  I don't think it is in the interest of users to have this sort of incentives in place.

I think that option 2 is simplest, but I quite like 3c.  Adding expiration of consent is very attractive; and it may not even need to remain a short-term feature.  Once we have good site status feedback UX in place, then the need for expiration might diminish, but it could turn out to be a good natural limiting function.



---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/pull/87#issuecomment-66545863