When we dug into the permissions model against the settings app permissions implementation, we've discovered that we are currently not harmonized against the permissions model, which results in such situations of risk as the following: - Permissions that may exist in the app but not in the model - Permissions that may not want to be modifiable by an end-user (as they are dangerous to modify) - Permissions that may exist in the model but not in the app - And so on... What we need to figure out here is the following: - What app permissions should an end-user be exposed to if the app is: ** Web? ** Privileged? ** Certified? - What app permissions should an end-user be able to modify if the app is: ** Web? ** Privileged? ** Certified?

Some references to look at: https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsInstaller.jsm#158 https://mxr.mozilla.org/mozilla-central/source/extensions/cookie/Permission.txt https://mxr.mozilla.org/gaia/source/apps/settings/js/apps.js#10 https://developer.mozilla.org/en-US/docs/Apps/Manifest#permissions

Discussed with jcarpenter and clee that we do not need to include certified apps in the app permissions list because we can't modify permissions nor delete these apps. Also, for further clarification regarding the App Permissions Settings design, the permissions I included in the mockups were always intended to be filler for the actual permissions we allow. The design spec is here: From pg. 26: http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Security_and_Privacy_v3.pdf

Permissions matrix is here - https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E#gid=0 When exploratory testing this, here's some things I immediately noticed: 1. We're exposing permissions for an app they may not even have the right to use and does not make sense to the user in the context of the app's privileges. For example, I installed a hosted app from Fabrice's test page with web level permissions and checked apps permissions page, I saw permissions listed that app would never be allowed to use (e.g. camera |deny|). Any permission we know an app of permission type web that we know should never be allowed to be used I think shouldn't have any UI exposed and instead, always immediately deny the permission. This avoids any risk for confusion of wondering why X permission is immediately denied and not take the risks against the current known underlying api bug in bug 812289. 2. We need to make sure our permissions list that our settings app uses falls in line with the permissions matrix. That means not just exposing exactly what permissions are given in the app, but actually following whether the permission makes sense to expose - something that a hosted app should never get access to I don't believe should be exposed. Something a lot like this example: A hosted app that calls out support for the contacts api should *not* expose any UI for the contacts permission and be able to be modified. A privileged app that calls out support for the contacts api should expose UI for the contacts permission with that app and allow the typical edit rules (ask, deny, always allow, etc). A certified app that calls out support for the contacts api as Larissa has stated wouldn't even show up in the app permissions UI. This is currently implemented correctly. I think at a high-level, what I'm getting at here is kinda along the lines of theme Larissa stated in comment 2 that originally hit on certified apps only: Expose UI that makes sense in the context of the app's permissions in relation to it's app permission level. If it doesn't make sense, then don't expose the UI.

I put my suggestion for what the UI should do in bug 811281 comment 25. Let me know what you think.

blocking- on this for now, doesn't feel like there's anything actionable in here at this point. please re-nom with details or create other bugs for specific apps.

(In reply to Dylan Oliver [:doliver] from comment #5) > blocking- on this for now, doesn't feel like there's anything actionable in > here at this point. please re-nom with details or create other bugs for > specific apps. Disagree. I generalized the bug mainly cause there a lot of problems - if we need to break this bug down more than let's do that. But I don't want to turn this into a qa bash to find every possible case when we know there's issues.

Actually, I'm going to generalize bug 811281 and dup on that one - since the actions for it can be taken care of there.

Actually not a dupe - let's just mark invalid for now and I'll open separate actionable bugs based on Jonas's input. Attempting to not create too much confusion...

For those watching at home: See bug 817031 and bug 817034 for the actionable bugs involved here. Sorry for the confusion.