- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Thu, 4 Sep 2014 22:05:00 +0300
- To: "Edward O'Connor" <eoconnor@apple.com>
- Cc: public-webapps@w3.org
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
Received on Thursday, 4 September 2014 19:18:14 UTC