W3C home > Mailing lists > Public > public-web-notification@w3.org > March 2012

Re: static permission functions on Notification (was Feedback from Safari on Web Notifications)

From: Rich Tibbett <rich.tibbett@gmail.com>
Date: Sat, 24 Mar 2012 15:38:12 +0800
Message-ID: <CALmeN0eFAHZVyXj=A8ncLmTbHB554eg1G-5VKg9oQaYR_Adp1A@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:13 UTC