B2G RIL includes anything that touches RIL (SMS web telephony 3g data etc). This bug is for tracking the security review of this feature.

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.

Per conversation with :gal putting the flags back, we need to make sure this work is done before ship.

Please make sure you complete this work within the remaining time window, which is very short.

Note: reviewing this at the moment to determine what exactly we want to achieve with this review.

Some initial thoughts on this review: AFAIK, there are three layers to RIL communications - The gecko glue which talks to ril_proxy - ril_proxy, basically just passes messages between gecko and rild - rild, talks to the modem From what I gather rild (and maybe ril_proxy?) may vary on differing devices. So I think this review should focus on the code that is in mozilla-central (which is the dependent bug), which is mainly: https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js http://mxr.mozilla.org/mozilla-central/source/ipc/ril/Ril.cpp Actually we probably want to look at everything in dom/system/gonk directory. https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk Note that there are some mitigations to any security issues in this code: - RIL code is not directly exposed to apps or web content - RIL code is only exposed through APIs which require permissions only available to certified apps (e.g. navigator.mozTelephony, navigator.mozSMS navigator.mozMobileConnection)

Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known bugs with LOE:M". We'll want to have this work done to be able to react to fallout in C3.

No updates since October. Also, the reference RIL will be replaced by the chipset manufacturer's RIL in production phones. Does this need to block? Paul, do you have any updates or input here?

Given mitigations noted above, ie, this is not directly exposed to web content, I dont think this needs to block - this is the main reason why I havent priorisited this over the other outstanding security reviews.

Permission check verified as part of 777602. Time permitting it would be good to do a more in-depth analysis of RIL functionality exposed through the various telephony APIs. But this isn't a priority I don't think.