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

@martinthomson wrote:
> I'm tending more toward 3a (...)
> a. If you can generate notifications, then you can run in the background. There is no separate permission.

We've continued to discuss this internally, and have three largish concerns with 3a:

1. Our user studies showed that users who grant notifications do not expect it to allow apps to run in the background, and that is a thing they are concerned about (for battery/creepiness/privacy reasons).
2. Users who would like e.g. news sites to sync in the background may deny notification permission if the site has a reputation for spammy advertising.
3. If users don't realise they're granting silent push, their location can be geoip tracked without their awareness (whereas if notifications are shown, the user at least knows the app is doing something, so it's comparable to open tabs tracking your IP).

> It's damaging - to all of us - to have divergence on this.

Convergence would be nice, but the Chrome Security UX team is convinced that 3b is most understandable for users; if we can't agree on that, it seems we'll have to start off with different UI and hopefully later converge once data proves which is more effective.

We'd still like the spec to allow for UAs to choose 3b (without excluding the alternatives). If we can't agree on that either, our current short-term strawman is to ask developers to put "gcm_user_visible_only":true in their manifest if they opt in to notification-only push, otherwise we will treat calls to PushManager.subscribe() as requests for silent push messaging (but a developer that has separately called Notification.requestPermission() would of course be allowed to show notifications as well).

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