W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] Proposal for a web application descriptor

From: Glenn Maynard <glenn@zewt.org>
Date: Sat, 30 Apr 2011 09:52:29 -0400
Message-ID: <BANLkTiksmQ1m5KKirwYrMuVvtJ03DeN-5g@mail.gmail.com>
On Sat, Apr 30, 2011 at 3:30 AM, Simon Heckmann <simon at simonheckmann.de>wrote:

> I agree: That is why the example you quote from my previous mail went on
> like this:
> As the users continue to use the page, the web site could check the status
> of the permission using javascript and remind the user to rethink his
> permission settings: "This site would like to access your camera to scan for
> a barcode. If you want to use this feature, please use the global
> permissions dialog to set them." This way users that trust/know the
> application can give permissions directly while others might grant
> permissions one at the time. Thats why I like the idea of a consolidated
> dialog. The user could always quicky return to it and maintain all
> permissions at once.
>

This is what I was cautioning against.  Scripts prompting manually is both a
bad API and bad UI.  Scripts shouldn't pop up a message telling the user to
track down some other UI; they should simply attempt to use what they want
to use, so the browser can just ask.


On Sat, Apr 30, 2011 at 5:23 AM, Robert O'Callahan <robert at ocallahan.org>
wrote:
> The application could have a settings page with a checkbox "Enable desktop
notifications". When you click on that box, the browser shows its (passive,
asynchronous) UI for enabling desktop notifications for that application.

This still implies having an API to ask for permission for a feature before
using it.  (Web Notifications has a draft for this:
http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html
.)

Also, many developers won't want a UI like that, since when you disable a
feature and expect users to enable it in settings, a lot of them won't.
Many people never look at settings pages at all.  Pages are more likely to
request permissions as soon as they can.


> Asking for specific permissions in the context of a user action is the
only model that makes sense to me. When applications ask for a big bundle of
permissions in advance, how can I as a user know what to do? I'm sure to get
into a habit of either blindly denying the permissions (crippling
applications), or granting the permissions (terrible for security).
>
> While some Mozilla developers may think "big bundle of permissions" is a
good idea, others such as me do not.

I'd wonder what their response is to Android; the problems on that platform
are obvious.  The result is exactly as you say: people end up giving up and
just accepting everything.

(The permissions request for Skype includes: "read contact data, write
contact data, coarse (network-based) location, full Internet access, act as
an account authenticator, manage the accounts list, user the authentication
credentials of an account, modify/delete USB storage contents, change your
audio settings, record audio, read phone state and identity, disable
keylock, modify global system settings, prevent phone from sleeping,
retrieve running applications, write sync settings, view network state, view
Wi-Fi state, control vibrator, read sync settings, read sync statistics,
discover known accounts".  It's hopeless; if "take out a mortgage on your
house" was in there, nobody would notice.)

Of course, asking each of these while using the application would also be
painfully annoying, and it's not obvious how to make permissions meaningful
to the user (eg. when you use its feature) while also scaling to lots of
permissions.

-- 
Glenn Maynard
Received on Saturday, 30 April 2011 06:52:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT