Closed Bug 855167 Opened 11 years ago Closed 11 years ago

Support more granular permissions for the MobileConnection API

Categories

(Core :: DOM: Device Interfaces, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 866272

People

(Reporter: pauljt, Assigned: edgar)

Details

(Keywords: sec-low, Whiteboard: [Apps Watch List])

In bug 846880, a partner app wanted to access the MCC from the SIM card, in order to determine what country the device was being used in. This required access to all of the mobileconnection API which is quite dangerous. There will likely be future requirements from partners and other third party apps in this space, so it would be good if we can split the API into more granular permissions (and then potentially expose the less sensitive API calls to privileged applications)

Read vs write is the obvious segregation, but it is likely that further granularity is required. For example, some SIM information is just carrier specific, where as this API also provides access to the phone number of SIM card, so there are privacy concerns. 

The first step will be to classify all of the functions in terms of their privacy impacts. Another approach might be to allow seperate read vs write access, and for read access, allow apps to declare exactly what data they need access to (similar to proposed approach for settings API in bug 846200)

NB this is security improvement expected to be post v1, marking as sec-low accordingly.
Whiteboard: [Apps Watch List]
The most useful API will include MNC & MCC from the SIM card because both pieces of data are need to identify a subscriber's specific operator (within a country). (see http://en.wikipedia.org/wiki/Mobile_country_code for a listing of values for operators by country.)  Please note that we are have two operators within one country on on roadmap for later this year/early next year.  Read only access to this data would be all that is needed by 'privileged' apps.
Marketplace would like to see MobileOperatorInfo be a privileged rather than a certified API.  This is needed to implement some features in Marketplace.  This is a rather important feature to operators that may need to have restricted use of some apps to some carriers or countries because of licensing terms.  Also for operator shelf and customization functionality in Marketplace roadmap.
(In reply to kward@mozilla.com from comment #1)
> The most useful API will include MNC & MCC from the SIM card because both
> pieces of data are need to identify a subscriber's specific operator (within
> a country). (see http://en.wikipedia.org/wiki/Mobile_country_code for a
> listing of values for operators by country.)  Please note that we are have
> two operators within one country on on roadmap for later this year/early
> next year.  Read only access to this data would be all that is needed by
> 'privileged' apps.

MCC and MNC can be retrieved from SIM card which informs about subscribers home network and from the "network" which informs where is the user (roaming).

It's different information and probably with different security levels (where is the user now, where is the user from)

Regarding the list, the official one is here: http://www.itu.int/pub/T-SP-E.212B-2011
Assignee: nobody → echen
As far as I understand it the current API is taking the information from the network not the SIM.

https://bugzilla.mozilla.org/show_bug.cgi?id=866272#c45
In our use cases, it is really about the information from the SIM MNC/MCC that is relevant.  The use case is for operator-only content and for selection of a ccustom operator shelf, which would be based on whether the user is a subscriber.
This was already fixed and landed. We expose MNC/MCC for the current network (roaming) and the home network (the SIM).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.