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

> So the most effective feedback we have is for notifications, where each notification is an implicit reminder that the site is doing stuff in the background, and we'll make it easy to revoke permission from a notification.

We discussed this as well, and concluded that we couldn't rely on that alone (notification UX being outside our control on some platforms).  And limited real estate means that there may simply be too little space anyway.  Not saying that it isn't worth looking into though.

>> 3c. 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.
> I'm confused - why would push permission grant foreground notifications but not background notifications?

It's the opposite: if you can do push, you can notify everywhere.  But the existing Notification permission is unchanged here.  The argument for this case is that we don't change the meaning of an existing consent grant, but merely add another one that provides a wider scope.  The important thing to note with this is that it doesn't distinguish between pushes that do and don't generate notifications.

And in case code would help:
```js
Notifications.requestPermission().then(() => {
  // can show notification from regular content
  assert(Notifications.hasPermission());
  // can't run in background (i.e., web push)
  assert(!Background.hasPermission());
});
```
vs
```js
Background.requestPermission().then(() => {
  assert(Notifications.hasPermission());
  assert(Background.hasPermission());
});
```

> Surely the point of using push is to show notifications in the background?

I don't really want to make too many assumptions about what people plan to do with the increased availability that push provides.  Most of the cases I come back to revolve around hosting and sovereignty issues, most of which can be addressed to a large extent with crypto if they don't require user involvement (and user involvement means notifications).

> Yes, our security UX team have been thinking along similar lines about automatically setting a dynamic quota for silent push messages based on user engagement with the site (with sufficiently good heuristics, it might even be possible to avoid showing confusing prompts at all for this use case, and let the UA handle the tedious task of managing resource consumption - we shall have to see).

That's where we are at already, mostly.  I think we may require some sort of indication from the user that a site is more trusted than any random origin.  I can speculate about how you might avoid a prompt altogether, but I'm not keen on the idea of allowing every site you visit - accidentally or otherwise -  to create background trackers.  If a scheme could be devised that can't be gamed by sites, let me know; we have plenty of other user consent prompts that we hate.

More likely, we'll start with a simple timeout (e.g., one or two weeks).  And then maybe move to a credit-based scheme that runs down with time and pushes.  I'm still disinclined to significantly discount pushes that become visible, but that probably needs a little more modelling.

> Can I ask how you would you represent option 3b in the API?

I'd simply have the two permissions orthogonal from an API perspective.  Rather than gate access to the SW on the "background" permission, I would also allow it when the "notification" permission was active (both can be queried and you can use the logical OR of the results to determine if everything is OK).  So that would result in no change to the API, just the descriptive text saying when the SW is permitted.

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