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

On Mar 25, 2012, at 11:15 AM, Andrew Wilson wrote:

> On Sat, Mar 24, 2012 at 12:38 AM, Rich Tibbett <rich.tibbett@gmail.com> wrote:
> 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.
> 
> BTW, is the objection to explicit permissioning solely around the existence of a "grantPermission()" API?
No, the API is not the issue; the largest disadvantage to explicit permissioning is the user experience.

> Let's say we had some other sort of permission model (e.g. on-demand, triggered by the display of a superfluous notification generated when a page first loads) - we'd still want to be able to query the state of the current permission so we could avoid generating a superfluous notification. Would having the ability to query for a prior grant of a permission be just as objectionable as the ability to explicitly request permission?
I find it hard to answer this question because notifications seem to be the only spec (someone please correct me if I'm wrong!) where the site is trying to push generated content to the platform. But here are my thoughts about your scenario, which assumes that we've already made a policy decision:

1. The user originally decided to turn notifications on, and then switches them off. In this case, the API could be designed to throw an error or dispatch an error callback, which means that the site had to just post one extra notification, which doesn't seem horrible to me.

2. The user originally decided to turn notifications off, and then switches them on. I can see an argument to request permission in this case. But even without it, I can see web pages using the API in either of the following ways:

a. The web page has been ignoring the error, posting notifications that never showed all this time, but now do, or,

b. Since it was denied before, the web page just doesn't post notifications for the rest of the session, but could as soon as the user reloads the page.

Even with these extra notifications, I still don't think scenario (a) is awful. Scenario (b) isn't that bad either, since the next reload of the page by the user will show notifications.

3. I really feel that both (1) and (2) are rare, and between the two of them, (1) sounds more common.

That said, using notifications with another model is a hypothetical that doesn't apply here, because we know that we want to avoid sending a test notification due to its visual impact. We want to employ the explicit permissioning model, which requires that we have to ask for permission ahead of its actual use. This is the only model that adopts the notion that web sites can interrupt a user's flow with some kind of nag. And to best allow sites to properly time this inconvenience, they need to query what the existing permission is.

The solutions we find to meet the needs of this feature don't generally apply to all features. The fact that notifications pushes generated content to a platform visually makes the permissioning API, IMO, extraordinary, and not common.

> 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.

I agree, and believe this is the best model, but I think this fourth model you're citing folds into the implicit model. To use your example, the user's selection of a file, either via file picker or drag-and-drop of files over the file input, implies he's granting the UA access to those files in the file system, and therefore obviates the need to request permission in some other fashion.

> The flow you describe above would require us to display in-tab notifications to the user when gmail is the focused window, which IMO is no better than displaying an infobar - if anything, it's worse, because at least in the case of gmail I am able to display an infobar immediately upon the user enabling the feature, rather than waiting for the next new mail to arrive (or, worse, displaying a notification for no other purpose than to display the text "click the little arrow button to pop out gmail notifications").

Agreed.

Jon