W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: Proposal for a Permissions API

From: Florian Bösch <pyalot@gmail.com>
Date: Thu, 4 Sep 2014 22:50:04 +0200
Message-ID: <CAOK8ODhSe0j8htN7-EK965+yhxve5KpTXqu+4Ag19vbZK1tGEw@mail.gmail.com>
To: noloader@gmail.com
Cc: Webapps WG <public-webapps@w3.org>
On Thu, Sep 4, 2014 at 10:36 PM, Jeffrey Walton <noloader@gmail.com> wrote:

> A site that continually prompts the user could negatively affect the
> user experience. If the designers of the site appreciate the fact,
> then they might ask for fewer permissions. They might even segregate
> functionality into different areas of the site with different
> permission requirements to lessen the burden on a user. Its kind of
> like a forced attrition into principal of least privilege.
>
> If there are no hurdles or obstacles, then sites will ask for
> everything whether they need it or not. The web will degenerate into
> an Android flashlight app.

Well, the motivation to ask for permission up front is so that you later
don't have to pester the user. Everytime you poll a user, there's a
possibility he'll not see the prompt (happens to me pretty frequently in
chrome and firefox) and stuff won't work and the site makes a sad face.
Putting it up front is one way to avoid a bad user experience. It's likely
APIs that require permissions will proliferate, which makes it more likely
to run into the bad cases.

There are other motivations to put permissions up-front though. For
instance if you enter pointerlock, then in order to click on the
permissions, the browser needs to throw the user out of pointerlock, but
you're not getting back into pointerlock by itself, so you need to reaquire
it, which necessitates a user interaction.

Sometimes a set of functionality (like say geolocation and user media) is
often requested together, so it makes it again more likely to run into the
bad cases. Pointerlock & fullscreen solved this issue by coalescing the
permission for both into a single dialog if both are requested.
Received on Thursday, 4 September 2014 20:50:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC