- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 2 Oct 2014 12:34:45 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: John Mellor <johnme@google.com>, Martin Thomson <martin.thomson@gmail.com>, WebApps WG <public-webapps@w3.org>
On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Oct 2, 2014 at 8:27 PM, John Mellor <johnme@google.com> wrote: >> This seems to either require a somewhat stronger trust signal from the user, >> or a very easy mechanism for revoking the permission if the website does >> spam you; and probably in either case showing the url bar should be >> compulsory to prevent phishing. But this isn't something we've thought about >> deeply yet. > > Indeed. The Notifications API is nice, but it's not suitable for this. > You need a browsing context of sorts so you can show images, video, > buttons, etc. Indeed. I wouldn't call these notifications at all. What's needed here is to launch full browser windows so that we can display full-screen or full-window UIs to the user. To make matters even more complicated, generally speaking you want to be able to do this on a mobile device, even if it's "locked". I.e. an alarm clock app wouldn't be terribly useful if it only worked when the device was unlocked. And a skype app wouldn't be terribly useful if you could only receive calls when the device was unlocked. Fortunately, while this goes outside the browser window, it doesn't "break the same-origin boundary". So it should be quite possible to solve this the same way we're planning on solving other such APIs, like storage, indexedDB and notifications. I.e. make the API async and then leave it up to UAs to implement policies. / Jonas
Received on Thursday, 2 October 2014 19:35:42 UTC