- From: Rich Tibbett <rich.tibbett@gmail.com>
- Date: Sat, 24 Mar 2012 15:38:12 +0800
- To: Jon Lee <jonlee@apple.com>
- Cc: John Gregg <johnnyg@google.com>, "Edward O'Connor" <eoconnor@apple.com>, Maciej Stachowiak <mjs@apple.com>, Marcos Caceres <w3c@marcosc.com>, public-web-notification@w3.org
On Thu, Mar 15, 2012 at 2:46 AM, Jon Lee <jonlee@apple.com> wrote: > There are currently three different permissioning models used by Web APIs: > implicit (drag-and-drop), on-demand (geolocation), and explicitly requested > (notifications). Explicit permissioning is the least desirable of these > three models, and we should discourage it whenever possible. I'd argue there is a fourth permissioning model: the 'in-flow implicit authorisation' you provide when you using <input type=file>. The file picker is just a part of the work flow of uploading a file and isn't even considered an authorisation dialog. This is an excellent design IMO and its subtly is often overlooked as an excellent workflow-based permissioning mechanism. > By only providing a generic API for explicit permissioning, we implicitly > elevate that model to be the preferred approach for the whole Web platform. > Thus far, the lack of a common API for *any* of the Web's permissioning > models has forced spec authors to think hard about how permissioning should > work in each case. I've been thinking a lot about if we could enable an 'in-flow' authorisations for Web Notifications. Any web page is free to call the Web Notification method and notifications appear tab-modal - that is, they appear automatically but only in the originating tab (or across all currently open tabs at a UA level pending more UX experimentation). The user is then able to simply elevate that notification to the system level via a native control available in each displayed tab-modal notification which then enables subsequent notifications to appear at the system level. In this model each notification gets displayed but the user gets to decide what they want or need to notify them at a system level. Those settings would likely be maintained until the user clears their private data at which point we would forget the authorized web notifications and/or the user could drill in to individual notification elevation permissions via an in-UA preferences panel. > In another part of this thread, you said—and I agree—that providing the > pattern to follow for explicit permissions is vitally important. We should > consider writing a Note discussing the different permissioning models of Web > APIs and the trade-offs among them. Spec authors could then refer to this > Note when designing features requiring permissioning. We discussed the need to document some best practices wrt to permissioning systems for the web at our recent Device APIs F2F meeting. We've come a long way on this topic and there are a lot of lessons learned, since we've made all of these mistakes (and more) in that group from a lot of APIs we've been experimenting with over the last couple of years. My hope is that this is an action that the W3C DAP would be able to pick up and I'm sure they'd be interested to know that the Web Notifications group is requesting some input here. HTH, Rich
Received on Saturday, 24 March 2012 07:39:01 UTC