[Security Review] Mobile Connection API

RESOLVED FIXED

Status

P2
normal
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: pauljt, Assigned: pauljt)

Tracking

other
x86
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(blocking-kilimanjaro:+, blocking-basecamp:+)

Details

(Whiteboard: [LOE:S][Score:36:Medium], URL)

(Assignee)

Description

7 years ago
Expose signal strength, operator, etc for GSM and other mobile connections. This does not cover WiFi.
(Assignee)

Comment 1

7 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: 729173
(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.
Assignee: nobody → ptheriault
Status: NEW → ASSIGNED
(Assignee)

Updated

7 years ago
Blocks: 754730
(Assignee)

Updated

7 years ago
Priority: -- → P1
blocking-basecamp: --- → +
(Assignee)

Comment 3

6 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
Component: Security Assurance → Security Assurance: Review Request
blocking-kilimanjaro: --- → +

Comment 4

6 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

6 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

6 years ago
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [LOE:S]
(Assignee)

Updated

6 years ago
Priority: P1 → P2
(Assignee)

Comment 7

6 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

6 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

6 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

6 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

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