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

Re: Proposal for a Permissions API

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Fri, 05 Sep 2014 19:14:12 +1000
Message-Id: <1409908452.2476730.163957149.519068E7@webmail.messagingengine.com>
To: "Edward O'Connor" <eoconnor@apple.com>, public-webapps@w3.org
On Fri, 5 Sep 2014, at 03:23, Edward O'Connor wrote:
> We should be avoiding adding features to the platform that have to
> resort to explicit permissioning. Instead of adding features which
> require prompting for permission, we should be designing features—like
> drag & drop or <input type=file>—that don't require prompting for
> permission at all.

That is a pious wish that I can understand but it is unfortunately not
possible. Features like <input type='file'> are great features with
regards to security and permission: the user knows what is happening and
the developer is aware of the flow, it is consistent and reliable.
Generally speaking, I think most of us would agree that the picker flow
is good and should be used when possible.

This said, we cannot use that model all the time and there are many APIs
that are constantly implemented via a permission prompt. The Web
platform tried to stay away of that "implementation detail" for long but
this is unfortunately crippling Web applications way more than it

Note that the Permissions API model isn't requiring all APIs to abide by
its model. Having no permissions at all for an API is a decent model if
possible. For example, having a permission concept for <input
type='file'> doesn't make much sense. Other APIs could use the
permission model but have some UA mostly returning 'granted' because
they have an opt-out model instead of opt-in, such as most
implementations of fullscreen.

-- Mounir
Received on Friday, 5 September 2014 09:14:40 UTC

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