Digging into source and per a few email threads, we've realized that our list of permissions might not be in alignment with the finalized permissions list off of the permissions matrix (the names in other words). Let's get the list fixed.

Noming cause we have to get the permissions list naming right. Otherwise, we can end up scenarios where users can install apps requesting permissions that are valid, but not manageable in this UI, or vice versa.

Permissions matrix is here: https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E#gid=0

Here's the thread for context: On Thu, Nov 29, 2012 at 4:46 PM, Jason Smith <jsmith@mozilla.com> wrote: > +Margaret - since she's working on > https://bugzilla.mozilla.org/show_bug.cgi?id=815505 in connection to this > +Paul - he's looking into this as well > > Thanks. Hmm...so that's a much smaller and different list then what I see in > the code that Margaret referenced: > > https://mxr.mozilla.org/gaia/source/apps/settings/js/apps.js > > First - are there any other code references we should analyze to make sure > it's consistent with the doc? > > Any thoughts on the diff between what's in the app manifest vs. in that > code? Also, should we breakout the permissions definition here by what level > of privileges the app has to have to use the permission? > > Here's a breakdown of the analysis from the code perspective: First of all, I strongly feel that we should not show permissions for certified apps. There are too many ways for users to shoot themselves in the foot, and too little reason for them to mess around with these properties. Hence certified only APIs should never be shown. Another thing to be careful about is when talking about what is "in code". We have over time ended up with a lot of entries in the table in PermissionsInstaller.jsm which aren't actually hooked up to a backend. I.e. the PermissionsInstaller will find the property in the manifest and write it into the permissions database, however no API is looking for that permission in the database. So we shouldn't claim that something is "in code" unless we're sure that there's actually an API which is hooked up to the permission. > power - same in doc and code > sms - same in doc and code, but certified only - what happens in this case? > Should we not show the property at all? > telephony - same in doc and code, but certified only - what happens in this > case? Should we not show the property at all? > mobileconnection - same in doc and code, but certified only - what happens > in this case? Should we not show the property at all? > backgroundservice - same in doc and code, but certified only - what happens > in this case? Should we not show the property at all? > settings - same in doc and code, but certified only - what happens in this > case? Should we not show the property at all? > camera - same in doc and code, but certified only - what happens in this > case? Should we not show the property at all? > voicemail - in code, not in doc > networkstats-manage - in code, not in doc > webapps-manage - same in doc and code, but certified only - what happens in > this case? Should we not show the property at all? > background - different in code than doc - doesn't even exist in doc > attention - in code not in doc > permissions - in code, not in doc > device-storage:apps - diff in doc vs. code - code adds the apps piece, doc > calls it device-storage generally > networkstats-manager - in code, not in doc > content-camera - in code not in doc > time - in code, not in doc > network-events - in code, not in doc > embed-apps - in code, not in doc > deprecated-hwvideo - in code, not in doc > idle - in code, not in doc All of these are certified-only and so shouldn't be a concern for the settings UI. But getting some sort of documentation for them would be great. > bluetooth - same in doc and code, but certified only - what happens in this > case? Should we not show the property at all? > mozBluetooth - different in doc vs. code - code calls it "mozBluetooth" > while doc calls it "bluetooth" - I believe there's a patch on inbound to fix > this, right? There are patches to rename this one to 'bluetooth' for what it's worth. Also, this one is certified so not something we need to worry about in this context. > desktop-notification - same in doc and code, but certified only - what > happens in this case? Should we not show the property at all? > mozApps - in code, but not in doc I don't know what these do. We should look through the code to see what they are hooked up to. I couldn't find "mozApps" anywhere in our code. Neither in the permissionsinstaller or anywhere else. > contacts - same in doc and code > browser - same in doc and code > geolocation - in code and doc > fmradio - same in code and doc > wifi-manage - in code, not in doc > storage - same in doc and code I think these are in a good state and ready to be implemented for the settings UI. > alarms - same in doc vs. code > alarm - in code, diff in doc - code looks wrong, cause I think it's alarms > if I understand correctly We should collapse these into "alarm". > mozFM - in code, not in doc This one should be removed. It's now called "fmradio". > wifi - in code and doc This is called "wifi-manage". > systemXHR - in code, not in doc We should rename this one to "network-http". > tcp-socket - diff in code vs. doc - code calls it tcp-socket, doc calls it > network-tcp Yes. I think we should rename this "network-tcp". But it's not a big deal if people want to keep the current name. > device-storage:pictures - diff in doc vs. code - code adds the pictures > piece, doc calls it device-storage generally > device-storage:music - diff in doc vs. code - code adds the music piece, doc > calls it device-storage generally > device-storage:videos - diff in doc vs. code - code adds the videos piece, > doc calls it device-storage generally > device-storage:sdcard All of these should ideally be renamed to "device-storage-pictures", "device-storage-music" etc. It would be super awesome to get bugs filed on all of the changes discussed here. Another thing that we should track in the security spreadsheet is which APIs have been audited for security checks in the client as well as audited for security checks in the parent. / Jonas

BB+, P3 - as this is something need to get it right but less of an user impact

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

This seems like union of bug 817031 and bug 817034. Is there a reason to keep this bug open?

(In reply to Jonas Sicking (:sicking) from comment #6) > This seems like union of bug 817031 and bug 817034. Is there a reason to > keep this bug open? I think I originally filed this bug cause in the finalize-permissions bug, we noticed the perms names used were not correct. This bug was filed to get the names right.

This performance bug represents a non-trivial amount of work. Marking as a P1 issue to frontload risk.

Duping to a more clean definition per Jonas's feedback about the confusion about 3 bugs open for one bug's purpose.

Removing target 12/21