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

Re: Proposal for a Permissions API

From: Kis, Zoltan <zoltan.kis@intel.com>
Date: Thu, 4 Sep 2014 22:05:00 +0300
Message-ID: <CANrNqUfGCvHt6-z7xxJEtdCxNjyOjDsEHfNfsVcsU3tQqnGFkA@mail.gmail.com>
To: "Edward O'Connor" <eoconnor@apple.com>
Cc: public-webapps@w3.org

On Thu, Sep 4, 2014 at 8:23 PM, Edward O'Connor <eoconnor@apple.com> wrote:
> Mounir wrote:
>> Permissions API would be a single entry point for a web page to check
>> if using API /foo/ would prompt, succeed or fail.
> It would be a mistake to add such an API to the platform. A unified API
> for explicit permissioning is an attractive nuisance which future spec
> authors will be drawn to.
> 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.
> I don't think much has changed since this last came up, in the context
> of Notifications:
> http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html

This makes sense when applicable, but I think the number of uses cases
where permissions can be inferred from user actions is rather small.

Although I agree that too many prompts (and prompts in general) are
annoying, the proposals in the referred minutes [1] actually address
that annoyance by allowing apps to skip them, if they are playing
along some rules. For both developers and users this gives enough
incentive to be taken seriously.

I like the idea presented in Mounir's doc about separating permission
semantics from the API/mechanism of handling them. Granularity of
needed permissions has always been a hard compromise to set, and would
be difficult to standardize. For instance, take your example where you
talk about separating permission grants (something I always hoped
for). When the user can deny some of the permissions, it may cause
dependency issues, which the apps could resolve either silently (in
good case), or through a user dialog - but for the latter it would
-again- need an API. Also, an API could help user decision, e.g. by
the ability to give a short description on how exactly the feature is
used (e.g. how/when the camera is used), and taking it further, if
that could be expressed in a both presentable and formalized way, then
it could be even enforced by the system. That is where the needed
granularity plays an important role. Standardizing that would be hard,
and it's not independent from the set of policies which need to be

Speaking about policies, choosing one (e.g. the "remember for a day"
or similar) policy is not universal, and there may be smarter ones in
a platform, e.g. an algorithm which chooses about prompting policy as
referred in the mentioned minutes [1]. Probably we don't need to
support an infinity of them either, but a certain set of "web"
policies could be supported. Mounir's doc addresses some of the things
needed for this, and fuels the slightly ambitious hope of
standardizing a mechanism making possible to implement multiple
policies (or no policies).
Let's see, but I wouldn't like to see it cut off this early :).

[1] https://docs.google.com/a/intel.com/document/d/1sPNHXRy7tkj0F2gdTtRHj9oFRNhQkaQy2A9t-JnSvsU/preview

Best regards,
Received on Thursday, 4 September 2014 19:18:14 UTC

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