- From: Owen Campbell-Moore <owencm@google.com>
- Date: Fri, 24 Oct 2014 17:39:34 +0100
- To: public-webapps@w3.org
- Message-ID: <CACjoXu6povGZDdZXjkv+bjpmn-BZvtfUT-RSO+DwznsaXevOZA@mail.gmail.com>
Hi All - my name is Owen and I recently joined the Chrome team. Taking a step back, we believe users have control such that they can permit a site to send them notifications (or notify them of an event using other UI) without permitting it to run arbitrarily in the background without their knowledge. The Notification API permission alone isn't sufficient for the "I want notifications from this site" use case since we want this to work after the page is closed and also because some browsers kill tabs in the background when a user hasn't visited them recently, so this also fails for foreground notifications on mobile. Hence we would like the 'user-visible' permission state so users can grant the permission to receive push notifications independently of background sync push use cases. > I think it might make sense to ask for permission to display notifications/UI at the same time as you ask for permission to "run in the background". I hope the above explains why we believe that while some sites *may *want to ask for both permissions, they should be able to say to the user "Hey, I want to send you notifications", without saying "Hey, I want to run in the background whenever I want for any reason". When a developer optionally commits to userVisibleOnly:true we propose to only ask the user about receiving notifications and not full push, which we believe will increase adoption since users are more likely to accept this less scary permission. Browser vendors can then decide exactly how they wish to notify users of sites which violate their commitment. In Chrome's case we are planning to show a notification after the service worker finishes handling the push in the case that it didn't show a notification. That said, due to special cases like loss of network after the push message was received etc, we plan to allow a very small number of pushes to not result in a notification so as to minimize annoyance for users. > However I don't think that it makes sense for apps to commit to displaying UI when there's an incoming push. I'm not sure what problem that would solve? I hope the problem is now clear. If sites want the unrestricted push they can still ask for it. Also note browser vendors can ask the user for the unrestricted permission when the restricted one is requested if they don't want to use to distinguish between the notification and sync use cases. This change would just let vendors like Chrome allow users to grant permission for push to be used for different use cases independently, increasing user control.
Received on Saturday, 25 October 2014 12:12:24 UTC