Closed
Bug 751005
Opened 13 years ago
Closed 12 years ago
[Security Review] Mobile Connection API
Categories
(mozilla.org :: Security Assurance: Review Request, task, P2)
Tracking
(blocking-kilimanjaro:+, blocking-basecamp:+)
RESOLVED
FIXED
People
(Reporter: pauljt, Assigned: pauljt)
References
()
Details
(Whiteboard: [LOE:S][Score:36:Medium])
Expose signal strength, operator, etc for GSM and other mobile connections. This does not cover WiFi.
Assignee | ||
Comment 1•13 years ago
|
||
Not sure if this needs to be a seperate review from the existing RIL review. For reference that review bug is bug 751050.
Blocks: webmobileconnection
Comment 2•13 years ago
|
||
(In reply to Paul Theriault [:pauljt] from comment #1)
> Not sure if this needs to be a seperate review from the existing RIL review.
It's a DOM API just like WebTelephont and WebSMS, so I'd say yes.
Updated•13 years ago
|
Assignee: nobody → ptheriault
Status: NEW → ASSIGNED
Assignee | ||
Updated•13 years ago
|
Blocks: B2G-secreview
Assignee | ||
Updated•13 years ago
|
Priority: -- → P1
Updated•13 years ago
|
blocking-basecamp: --- → +
Assignee | ||
Comment 3•13 years ago
|
||
Added review of bug 731786 to this review, since it is part of the same API.
Main threat I see from this bug is DoS (called unlockCardLock multple times to lock the sim card?) Not sure what the impact would be for this though?
Blocks: 731786
Updated•13 years ago
|
Component: Security Assurance → Security Assurance: Review Request
Updated•13 years ago
|
blocking-kilimanjaro: --- → +
Comment 4•12 years ago
|
||
I am going to unblock on this because this clutters the list of engineering bugs to work on. We should never the less obviously finish this work asap, and block on any mandatory follow-up items that come out of it. Please renom if you disagree with this rationale.
blocking-basecamp: + → ---
blocking-kilimanjaro: + → ---
Per conversation with :gal putting the flags back, we need to make sure this work is done before ship.
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
Assignee | ||
Comment 6•12 years ago
|
||
In terms of a status update, the initial review is complete here, pending a permission model for this API, and the two follow-up bugs (how to apply CSP and how to handle SSL). Like most new Web APIs the security review is blocked on the application of the permissions, however I have been on leave for two weeks so not sure of the current status. I'll update further next week when I return from leave.
Assignee | ||
Updated•12 years ago
|
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [LOE:S]
Assignee | ||
Updated•12 years ago
|
Priority: P1 → P2
Assignee | ||
Comment 7•12 years ago
|
||
Risk/Priority Ranking Exercise https://wiki.mozilla.org/Security/RiskRatings
Priority: 4 (P2) - Mozilla Initiative
Operational: 0 - N/A
User: 2 - Normal
Privacy: 2 - Normal
Engineering: 2 - Normal
Reputational: 3 - Major
Priority Score: 36
Whiteboard: [LOE:S] → [LOE:S][Score:36:Medium]
Assignee | ||
Comment 8•12 years ago
|
||
Access to this API is restricted to Apps which have the 'mobileconnection' permission:
http://mxr.mozilla.org/mozilla-central/source/dom/base/Navigator.cpp#1235
Assignee | ||
Comment 9•12 years ago
|
||
I can't see any security issues with the implementation of this API. The main threats are:
- it allow access to private phone information (SIM data etc)
- you cause a DoS of the phone (change the network, set a SIM pin code etc)
But all access to these data and functions is provided through the navigator.mozMobileConnection object which is null, unless the principal for the current window has mobileconnection permission.
Assignee | ||
Updated•12 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•12 years ago
|
||
Note that I have not reviewed the underlying implementation of the how gecko communicates with the phone (through RIL). THis work will be conducted in bug 751050.
You need to log in
before you can comment on or make changes to this bug.
Description
•