Re: Proposal for a Permissions API

This is an issue to use, for a user.

   - http://codeflow.org/issues/permissions.html
   - http://codeflow.org/issues/permissions.jpg
   - In firefox it's a succession of popup

It's also an issue to use for a developer, because the semantics and
methods for requesting, getting, being denied and managing permissions
differ. Sometimes permissions aren't queryable.

It's my stated opinion that ignoring these issue will not make them go
away. And delaying addressing UX and consistency issues just contributes to
a proliferation of bad UX and inconsistent and difficult to use APIs.



On Thu, Sep 4, 2014 at 9:05 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:

> Hello,
>
> 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
> supported.
>
> 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,
> Zoltan
>
>
>