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

Hi all,

John Gregg wrote:

> I think the biggest question that the group needs to address here is
> whether the Notifications spec should continue depending on the
> Feature Permissions for its permissions behavior[…] or should we
> remove that dependency and return to writing our own permissions
> behavior scoped to notifications?

I don't think we should adopt the generic permissions API for
Notifications. No other spec is using it and there are no known
implementations—I don't think it has much implementor buy-in.
Additionally, I think a generic permissions API is something we
shouldn't add to the Web platform. More on that below.

> The primary rationale for the central permissions API is this:
> allowing a web site to request all of its permissions once rather than
> requiring the site to ask the user N times is a better experience for
> users.

But this isn't a better experience for users. By having a generic API
for explicit permissioning, we encourage spec authors to design features
that require explicit permissioning, and worse still, we encourage Web
authors to ask for all sorts of permissions.

Consider this scenario. Your friend Bob IMs you:

  <bob> omg check this out dude it's hilarious http://frob.com

Being a fan of hilarity, you click on the link to frob.com. When your
browser loads the page, you are prompted like so:

    The website "http://frob.com"
    would like to use your current location.
    
    [] Remember my decision for one day
    
                       [Don't Allow] [Allow]

It's clear what's being asked of you, and you can't dismiss the prompt
without either granting or denying the request. Your browser helpfully
offers to remember the choice for a day, thus reducing the annoyance of
this prompt coming up later if you invite office-mates over to your desk
to see this site.

Because N of these prompts would be presented for N features requiring
permissioning, the Web author is discouraged from using many features
requiring explicit permissioning. This is a good thing! Hopefully spec
authors will also be discouraged from desigining many such features in
the first place. The number of Web-facing features requiring explicit
permissioning should be kept to a minimum. Much better are features like
Drag and Drop, where the permissioning is implicit in ordinary user
activity. Even better than that, of course, are Web-facing features that
don't require permissioning at all because they don't do anything
sensitive.

Suppose instead you got this prompt:

    The website "http://frob.com"
    would like permission to do the following.

        * use your current location
        * post notifications
        * vibrate your phone [seriously?]
        * frobnicate
    
    [] Remember my decision for one day
    
                       [Don't Allow] [Allow]

This is really bad. What if I wanted to allow frob.com to post
notifications and to frobnicate, but not either of the other options?
(When would I *ever* want to allow a site to *vibrate my phone*?) Users
should be able to individually allow or deny permissions, and
selectively remember such decisions.

OK, so suppose you saw this instead:

    The website "http://http://frob.com"
    would like permission to do the following.

    Allow?
        [] use your current location [] Remember for one day
        [] post notifications        [] Remember for one day
        [] vibrate your phone        [] Remember for one day
        [] frobnicate                [] Remember for one day
    
                                               [Cancel] [OK]

This is a little better than the previous one in terms of user-facing
functionality, but I hope we can all agree that it's a terrible user
experience.


Ted

Received on Tuesday, 13 March 2012 20:15:11 UTC