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

On Tue, Mar 13, 2012 at 1:14 PM, Edward O'Connor <eoconnor@apple.com> wrote:

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

Well I agree that explicit permission models are not as good as implicit
ones where that's possible. But some features do require explicit
permission models, and I don't get the idea that simply having a single
good way of doing that encourages bad behavior among feature designers.  I
would hope that new features for the web platform (a relatively rare thing)
are proceeding carefully as in this process here.

Annoying sites are going to ask for permissions however we allow it - one
api or N doesn't really matter.  Consider a legitimate site that wants to
use these features for the users' benefit (the features don't exist
strictly for purposes of annoyance).  Discouraging the use of features
should not be a goal, even if after being thoughtfully designed those
features require explicit permission.

So the real choice is between:

navigator.permissions.requestPermissions("notifications", "location",
"protocol frob-protocol", "vibrate", callback);

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

[ ] show notifications
[ ] use your current location
[ ] handle frob-protocol:// links
[ ] vibrate your computer
                                             [ Grant selected permissions ]
 [ Ignore ]

and this (3 out of 4 of these exist today):

Notifications.requestPermission(callback1);
Geolocation.getLocation(callback2);
RegisterProtocolHandler("frob-protocol");
Device.askForVibratePermission(callbackToVibrate);

The website "http://frob.com" would like permission to show notifications
   [ Grant ]  [ Ignore ]

The website "http://frob.com" would like to use your current location
 [ Allow ]  [ Cancel ]

Allow the website "http://frob.com" to handle "frob-protocol://" links?
 [ Yes ]  [ No ]

Should "http://frob.com" be allowed to vibrate your computer?      [ Sure ]
 [ No vibration ]