- From: Edward O'Connor <eoconnor@apple.com>
- Date: Tue, 13 Mar 2012 13:14:26 -0700
- To: John Gregg <johnnyg@google.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, Marcos Caceres <w3c@marcosc.com>, Jon Lee <jonlee@apple.com>, public-web-notification@w3.org
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