817087 - [Settings] Update list of permissions based on the finalized permissions set in apps permissions UI

Status: RESOLVED DUPLICATE of bug 821961

(Firefox OS Graveyard :: Gaia::Settings, defect, P1)

Description

[Jason Smith [:jsmith]]

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.

Comment 1

[Jason Smith [:jsmith]]

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.

Comment 2

[Jason Smith [:jsmith]]

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

Comment 3

[Jason Smith [:jsmith]]

Here's the thread for context:



On Thu, Nov 29, 2012 at 4:46 PM, Jason Smith <[e-mail]> 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

Comment 4

[Joe Cheng [:jcheng] (please needinfo)]

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

Comment 5

[Alex Keybl [:akeybl]]

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.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 7

[Jason Smith [:jsmith]]

(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.

Comment 8

[Alex Keybl [:akeybl]]

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

Comment 9

[Jason Smith [:jsmith]]

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

Comment 10

[David Scravaglieri [:scravag]]

Removing target 12/21