I was going to update the MDN page on manifest permissions today, but first I wanted to lock down exactly permission strings will be used, since there are duplicates and differences in different places in the code which need to be harmonized. The source of truth from a design perspective is this spreadsheet, which I have attempted to update today: https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E#gid=0 There are a number of issues (in yellow) though which I will raise bugs for since most require code changes one way or another. For reference, the following document/files need to be harmonized: * https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsInstaller.jsm * https://mxr.mozilla.org/mozilla-central/source/extensions/cookie/Permission.txt * http://hg.mozilla.org/gaia-l10n/en-US/file/e428ebd17a6e/shared/permissions/permissions.properties * The actual permission checks in the varios Gecko APIs * The permissions in the manifests I'll raise dependent bugs for each of the issues so they can be resolved. But to summarize the issues I am aware of are: - background vs backgroundservice (or do we even need this permission given bug 801351) - bluetooth or mozBluetooth - deprecated-hwvideo (what is this?) - keyboard (this isnt used in gaia, but is in PermissionsInstaller) - push (I assume this will be used in the future for push API, but maybe should be removed for now?) - systemclock (maybe called time now) - storage (what does this actually grant, and what is the security model) - WiFi ( I think this is replaced by wifi-manage?) Please comment/raise more bugs if there are other issues I've missed.

Disregard backgroundservice/background, gaia has changed to background service so that is what I am going with, I assume there is a bug somewhere that relates to this.

I'm actually going to put this in the nom queue cause we're finding loads of problems with this already (I just looked at some of the gaia code). If we don't do this, then we'll risk a lack of consistency in the permissions model (which is already evident).

This looks like just a reminder to document - all the deps are process or nommed for triaged and will be dealt with.

(In reply to JP Rosevear [:jpr] from comment #3) > This looks like just a reminder to document - all the deps are process or > nommed for triaged and will be dealt with. Not necessarily only document. It's the investigation + documentation. But that's fine, I'll focus on the dependencies.

Added comparison between PermissionsInstaller.jsm and the matrix to the second sheet of https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E#gid=0

Note that the permissions matrix is now finalized, with no outstanding information. https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E#gid=0

Now that matrix is finalized, I have finished reconciliation between matrix and permission installer - see spreadsheet 2 in the matrix for specifics, or blocking bugs. To summarize changes remaining for PermissionsInstaller.jsm: audio: restrict channels per app type (819136) camera: make certified only for v1 (818566) desktop-notification: make available to all content (819218) device-storage:apps : make certified only with restricitons (818583) storage: allow apps to request this (819216)

Cleaning up my old bugs. This is long since complete and documented here: https://developer.mozilla.org/en-US/docs/Apps/App_permissions To see the implementation detail, go here: https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm