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

Thanks for looking into this in depth. It sounds like at a high level, we are surprisingly well aligned :-)

> feedback [is] hugely important (...) the idea [for storage] is to provide feedback in the form of a display, showing how much capacity each site uses (...) 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.

We strongly agree. Chome is about to launch an improved [Permission/Resource Manager](https://docs.google.com/a/chromium.org/document/d/1oQwmj3AU4QYhTyGrYEGr6zaZhHUfx-wqUgEcQGbUU-U/edit), for example for storage you'll be able to see sites sorted by how much space they use.

For push/notifications, we'll show when the site last sent/showed a push/notification. But realistically, most users won't go looking at this UI. 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.

> 3b. 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.

This is exactly the model we think makes sense.

> 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? Surely the point of using push is to show notifications in the background?

> A consent grant doesn't have to be permanent (...) Any limited budget might be refreshed if the site is visited (...) You can imagine getting arbitrarily inventive with the accounting of time, visible and invisible pushes.

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 take care of managing resource consumption - we shall have to see).

Can I ask how you would you represent option 3b in the API? (this pull request was my attempt to do so, but it seems it has been confusing).

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