Closed Bug 782603 Opened 7 years ago Closed 7 years ago

B2G RIL: Expose Home Network Identity (HNI) in privileged DOM API

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla18
blocking-basecamp +

People

(Reporter: jaoo, Assigned: jaoo)

References

Details

(Whiteboard: [LOE:S])

Attachments

(5 files, 19 obsolete files)

8.86 KB, patch
jaoo
: review+
Details | Diff | Splinter Review
1.45 KB, patch
jaoo
: review+
Details | Diff | Splinter Review
4.37 KB, patch
jaoo
: review+
Details | Diff | Splinter Review
5.33 KB, patch
smaug
: review+
Details | Diff | Splinter Review
96.65 KB, image/png
Details
We need to expose the IMSI number to content. There is a requirement for certification that says "Any time a SIM of a different Telefonica operating country is inserted the handset must use the MCC and MNC parameters of the IMSI provided by the SIM to identify the Telefonica operator network and then load all
the settings related to that network." Current mnc and mcc codes provided by 'mozMobileConnection' are not valid since they identify the network where the phone is registered in.

Here is an example where I was using a SIM from O2 (Telefonica UK) on a otoro phone in Spain.

{"imsi":"234106173689696","ad" {"0":0,"1":0,"2":0,"3":2},"mcc":234,"mnc":10,"rilMessageType":"iccinfochange"}

{"rilMessageType":"operatorchange","longName":"Telefonica Moviles Espana","shortName":"movistar","mcc":214,"mnc":7}

This development is needed to implement the operator-variant software I am currently working on.
Assignee: nobody → josea.olivera
Attached patch Part 1: DOM API - v1. (obsolete) — Splinter Review
Attachment #651716 - Flags: review?(jonas)
Attached patch Part 2: DOM impl (C++) - v1. (obsolete) — Splinter Review
Attachment #651717 - Flags: review?(marshall)
Attached patch Part 3: RIL impl - v1. (obsolete) — Splinter Review
Attachment #651718 - Flags: review?(marshall)
blocking-basecamp: --- → ?
Nom'ed for basecamp since it should be a MUST have for v1.
Comment on attachment 651718 [details] [diff] [review]
Part 3: RIL impl - v1.

Review of attachment 651718 [details] [diff] [review]:
-----------------------------------------------------------------

r-, just because I didn't see any tests (you should be able to test the IMSI from the emulator. See the other marionette tests in dom/network)

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +396,5 @@
>                " timestamp=" + message.localTimeStampInMS);
>          break;
>        case "iccinfochange":
>          this.rilContext.icc = message;
> +        ppmm.sendAsyncMessage("RIL:ImsiChanged", message);

You are sending this message every time anything in icc changes, shouldn't this be checking for changes in |message.imsi|?
Attachment #651718 - Flags: review?(marshall) → review-
Comment on attachment 651717 [details] [diff] [review]
Part 2: DOM impl (C++) - v1.

I'm not a DOM peer, so I can't review DOM implementation code (Olli might be able to though)

FWIW, this looks good to me.
Attachment #651717 - Flags: review?(marshall) → review?(bugs)
(In reply to Marshall Culpepper [:marshall_law] from comment #5)
> ::: dom/system/gonk/RadioInterfaceLayer.js
> @@ +396,5 @@
> >                " timestamp=" + message.localTimeStampInMS);
> >          break;
> >        case "iccinfochange":
> >          this.rilContext.icc = message;
> > +        ppmm.sendAsyncMessage("RIL:ImsiChanged", message);
> 
> You are sending this message every time anything in icc changes, shouldn't
> this be checking for changes in |message.imsi|?

Yes. Try and do the change check in ril_worker even, if possible.
Comment on attachment 651716 [details] [diff] [review]
Part 1: DOM API - v1.

Review of attachment 651716 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/network/interfaces/nsIDOMMobileConnection.idl
@@ +22,5 @@
>  
>    /**
> +   * Gets the SIM IMSI.
> +   */
> +  readonly attribute DOMString imsi;

What is the format of IMSI? If it has both an MCC / MNC, should those be extracted?
Comment on attachment 651717 [details] [diff] [review]
Part 2: DOM impl (C++) - v1.

> 
> NS_IMETHODIMP
>+MobileConnection::GetImsi(nsAString& imsi)
Parameter names should be in form aParameter name.
I noticed that not all of the file follows Gecko coding style, 
but this is reasonable new code, so it really should.
So, please change imsi to aImsi.
Attachment #651717 - Flags: review?(bugs) → review+
So is this a legal requirement then?
Whiteboard: [LOE:S]
blocking-basecamp: ? → +
Summary: Expose International Mobile Subscriber Identity (IMSI) to web content. → Expose International Mobile Subscriber Identity (IMSI) to certified apps.
We need mcc and mnc information to identify a suscriber's home network. This information is included in IMSI value.
This information will be useful to configure the suitable settings of each user for each country: suitable APNs.
Jaoo, I agree Marshall's point in comment 8.
MNC might have 1~3 digits, how do you plan to extract MCC/MNC base on IMSI?
(In reply to Yoshi Huang[:yoshi][:allstars.chh] from comment #12)
> Jaoo, I agree Marshall's point in comment 8.
> MNC might have 1~3 digits, how do you plan to extract MCC/MNC base on IMSI?

Oh crap!, We need some extra information to extract those codes properly from the IMSI number. On ril_worker.js [1] we have that "extra information" but not in content. I didn't notice this issue at the beginning. We need to know/identify the subscriber's carrier which is fully identified by the combination of the MCC and the MNC codes (AKA HMI - Home Network Identity). Both codes are part of IMSI number but parsing them properly it's a bit tricky. I'm lost about what to do here, morphing this bug for exposing that HMI information instead of exposing the IMSI number itself or finishing current implementation and filing a new bug about exposing both MCC and MNC subscriber's carrier (home network information). What do you guys think about it?

[1] http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#1145
I think this is a good idea in order to let some applications to keep information by SIM (i.e, cost control application need to store SIM configuration and we could use IMSI as hash).
Attached patch Part 4: Tests - WIP v1. (obsolete) — Splinter Review
WIP not tested yet since I'm not able to run the emulator and make tests. It builds successfully but doesn't boot.
Attachment #652399 - Flags: feedback?(marshall)
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #13)
> (In reply to Yoshi Huang[:yoshi][:allstars.chh] from comment #12)
> > Jaoo, I agree Marshall's point in comment 8.
> > MNC might have 1~3 digits, how do you plan to extract MCC/MNC base on IMSI?
> 
> Oh crap!, We need some extra information to extract those codes properly
> from the IMSI number.

Correct me if I'm wrong, but the link you just gave shows that ril_worker already parses mcc and mnc, and places them in iccInfo / rilContext. Wouldn't you just need to expose these values instead of the raw IMSI?
(In reply to Salvador de la Puente González [:salva] from comment #14)
> I think this is a good idea in order to let some applications to keep
> information by SIM (i.e, cost control application need to store SIM
> configuration and we could use IMSI as hash).

Since IMSI is essentially a unique user identifier, We probably need to also stop and think about the security and privacy implications of exposing it to content. There might be better ways to achieve what you're talking about without providing this in WebAPI.

Jonas, do you have any thoughts in that regard?
(In reply to Marshall Culpepper [:marshall_law] from comment #16)
> Correct me if I'm wrong, but the link you just gave shows that ril_worker
> already parses mcc and mnc, and places them in iccInfo / rilContext.
> Wouldn't you just need to expose these values instead of the raw IMSI?

Yes, that would be the idea. I started thinking about exposing the IMSI and parsing mcc and mnc codes from it but I didn't notice how tricky the parsing is. Please sorry, my fault. Also security and privacy implications have arisen lately so IHMO I think we could solve all the problems by exposing both codes instead of exposing the IMSI number. Let's wait Jonas' thoughts about it.
(In reply to Marshall Culpepper [:marshall_law] from comment #17)
> (In reply to Salvador de la Puente González [:salva] from comment #14)
> > I think this is a good idea in order to let some applications to keep
> > information by SIM (i.e, cost control application need to store SIM
> > configuration and we could use IMSI as hash).
> 
> Since IMSI is essentially a unique user identifier, We probably need to also
> stop and think about the security and privacy implications of exposing it to
> content.

I don't see how that's necessarily more of a concern here than with a lot of other privileged APIs. E.g. I bet access to the USSD functionality (which is also part of the MobileConnection API) would allow content to find out a whole lot more than just this identifier.

> There might be better ways to achieve what you're talking about
> without providing this in WebAPI.

Can we back up for a moment and talk about the goal here? AFAIUI, we need to display the IMSI somewhere on the device. But maybe that's a faulty assumption.
(In reply to Philipp von Weitershausen [:philikon] from comment #19)
> > There might be better ways to achieve what you're talking about
> > without providing this in WebAPI.
> 
> Can we back up for a moment and talk about the goal here? AFAIUI, we need to
> display the IMSI somewhere on the device. But maybe that's a faulty
> assumption.

Hrm, never mind, just reread comment 0. Still, loading different settings smells a lot like something that involves Gaia, so I don't think we get around exposing at least MNC and MCC.

jaoo, we need to parse it at some point anyway, right? If Gecko doesn't do it, then Gaia would have to figure out the MCC and MNC to load the right settings, no? So we might as well do it in Gecko.
(In reply to Philipp von Weitershausen [:philikon] from comment #20)
> 
> Hrm, never mind, just reread comment 0. Still, loading different settings
> smells a lot like something that involves Gaia, so I don't think we get
> around exposing at least MNC and MCC.
> 
> jaoo, we need to parse it at some point anyway, right? If Gecko doesn't do
> it, then Gaia would have to figure out the MCC and MNC to load the right
> settings, no? So we might as well do it in Gecko.

This still needs to be done in Gecko,
The length of MNC is determined by a record in ICC(SIM) called EF_AD(Administrative Data).
As security isues had been risen, the parse of IMSI is quite tricky and we just need mcc and mnc of the home network(means coming from the SIM), we do not need the complete IMSI value. So I guess we should modify the goal of this bug in favour of exposing only those two values.

With those values(mcc-mnc) we can configure the device with the suitable settings.

(In reply to Salvador de la Puente González [:salva] from comment #14)
> I think this is a good idea in order to let some applications to keep
> information by SIM (i.e, cost control application need to store SIM
> configuration and we could use IMSI as hash).

I will suggest to use ICC identification instead of IMSI. ICC is stored on the SIM and provides a unique identification. This number has no security concerns.
Comment on attachment 651716 [details] [diff] [review]
Part 1: DOM API - v1.

I'll leave the API up to Marshall here
Attachment #651716 - Flags: review?(jonas) → review?(marshall)
(In reply to Jonas Sicking (:sicking) from comment #23)
> Comment on attachment 651716 [details] [diff] [review]
> Part 1: DOM API - v1.
> 
> I'll leave the API up to Marshall here

Marshall, before going ahead and since it seems you are allowed to decide what expose to content here have you already considered what latest comment #22 from Beatriz suggests? FYI, I have a version of that implementation ready for review.
I agree with Beatriz, IMSI is used as shared secret between device and network by some services, exposing it might be risky. 

ICC should do the work for checking changes in SIM Card whereas MCC and MNC should suffice for the operator variant thing.
Summary: Expose International Mobile Subscriber Identity (IMSI) to certified apps. → B2G RIL: Expose International Mobile Subscriber Identity (IMSI) in privileged DOM API
I requested to Marshall to change the goal of this bug in favour of exposing only MCC and MNC codes from ICC card because we need them to identify the subscriber's home network. Exposing IMSI number has security implications as Daniel commented above (comment #25). I know you guys -both Marshall and you- are really busy hacking on other V1 blockers but could you consider and think about my comment #24 please?
(In reply to Beatriz Rodríguez [:brg] from comment #22)
> I will suggest to use ICC identification instead of IMSI. ICC is stored on
> the SIM and provides a unique identification. This number has no security
> concerns.

How so? (I also asked the same question in bug 785072.)
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #26)
> I requested to Marshall to change the goal of this bug in favour of exposing
> only MCC and MNC codes from ICC card because we need them to identify the
> subscriber's home network. Exposing IMSI number has security implications as
> Daniel commented above (comment #25). I know you guys -both Marshall and
> you- are really busy hacking on other V1 blockers but could you consider and
> think about my comment #24 please?

After reading Daniel's comment [1], it sounds like exposing the ICCID would be a good alternative to the IMSI (since it exposes a device ID, and not subscriber).

In either case though, I agree with you that we should change the purpose of this bug (or open a new one) to just expose the SIM MCC/MNC.
Changing the purpose of this bug. Since there are security implications with IMSI we are going to expose MCC and MNC codes from ICC card. The Home Network Identity (HNI) is the combination of the MCC and the MNC and identifies the subscriber's home network.
Summary: B2G RIL: Expose International Mobile Subscriber Identity (IMSI) in privileged DOM API → B2G RIL: Expose Home Network Identity (HNI) in privileged DOM API
Attached patch Part 1: DOM API - v2. (obsolete) — Splinter Review
Attachment #651716 - Attachment is obsolete: true
Attachment #651717 - Attachment is obsolete: true
Attachment #651718 - Attachment is obsolete: true
Attachment #652399 - Attachment is obsolete: true
Attachment #651716 - Flags: review?(marshall)
Attachment #652399 - Flags: feedback?(marshall)
Attached patch Part 3: RIL impl - v2. (obsolete) — Splinter Review
Attached patch Part 4: Tests - WIP. (obsolete) — Splinter Review
Attachment #654992 - Flags: review?(marshall)
Attached patch Part 2: DOM impl (C++) - v2. (obsolete) — Splinter Review
Attachment #654993 - Attachment is obsolete: true
Attachment #655030 - Flags: review?(bugs)
Attachment #654992 - Attachment description: Part 1: DOM API - WIP. → Part 1: DOM API - v2.
Attachment #654994 - Attachment description: Part 3: RIL impl - WIP. → Part 3: RIL impl - v2.
Attachment #654994 - Flags: review?(marshall)
Comment on attachment 654992 [details] [diff] [review]
Part 1: DOM API - v2.

Note, DOM APIs must be reviewed by DOM peers.
(In reply to Olli Pettay [:smaug] from comment #36)
> Comment on attachment 654992 [details] [diff] [review]
> Part 1: DOM API - v2.
> 
> Note, DOM APIs must be reviewed by DOM peers.

Oops, sorry for my ignorance but I request review at Marshall since Jonas left the API up to Marshall. (See comment #23.) Should I change it? Could you please make that review?
Attachment #655030 - Flags: review?(bugs) → review+
Comment on attachment 654994 [details] [diff] [review]
Part 3: RIL impl - v2.

Review of attachment 654994 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good! r- just so we can address the ICC updating code (see below)

::: dom/system/gonk/RILContentHelper.js
@@ +209,5 @@
>                                                   Ci.nsIRILContentHelper]}),
>  
> +  updateICCInfo: function updateICCInfo(srcInfo, destInfo) {
> +    destInfo["mcc"] = srcInfo["mcc"];
> +    destInfo["mnc"] = srcInfo["mnc"];

nit: any reason this doesn't just use literal syntax? :) i.e..

destInfo.mcc = srcInfo.mcc

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +995,5 @@
> +    if (oldIcc && (oldIcc.mcc == message.mcc || oldIcc.mnc == message.mnc)) {
> +      return;
> +    }
> +    this.rilContext.icc = message;
> +    ppmm.sendAsyncMessage("RIL:IccInfoChanged", message);

This change makes me a little nervous. It's good that you're checking that MCC / MNC have changed before firing RIL:IccInfoChanged, but now |this.rilContext.icc| won't get updated when non-MCC/MNC fields are changed. 

To get this right, we should probably retain the previous behavior of always updating |this.rilContext.icc|, but only fire RIL:IccInfoChanged when the MCC or MNC have changed. Also, could you make sure to comment this code to indicate that RIL:IccInfoChanged corresponds to a DOM event, with only specific properties?
Attachment #654994 - Flags: review?(marshall) → review-
Comment on attachment 654992 [details] [diff] [review]
Part 1: DOM API - v2.

Review of attachment 654992 [details] [diff] [review]:
-----------------------------------------------------------------

Let's look into the feasibility of reusing nsIDOMMozNetworkInfo here, see below.

::: dom/network/interfaces/nsIDOMMobileConnection.idl
@@ +24,5 @@
>  
>    /**
> +   * Information stored in the device's ICC card.
> +   */
> +  readonly attribute nsIDOMMozMobileICCInfo icc;

minor bikeshed: Technically all we're really representing here is a mobile network (MNC / MCC combo). I would prefer if we reused nsIDOMMozNetworkInfo here, and name the attribute something like |cardNetwork|. Since we only have the MCC and MNC codes, shortName and longName could remain null, and we could add a new state string, to indicate the source of the network (i.e. "card"?)

Side rant: Part of me wonders if it would make more sense to move all of these card APIs into one place like "MobileCard"? That's definitely outside the scope of this bug, though.
Attachment #654992 - Flags: review?(marshall) → review-
Comment on attachment 654996 [details] [diff] [review]
Part 4: Tests - WIP.

Review of attachment 654996 [details] [diff] [review]:
-----------------------------------------------------------------

Tests look good so far

::: dom/network/tests/marionette/test_mobile_iccinfo.js
@@ +4,5 @@
> +MARIONETTE_TIMEOUT = 30000;
> +
> +const WHITELIST_PREF = "dom.mobileconnection.whitelist";
> +let uriPrePath = window.location.protocol + "//" + window.location.host;
> +SpecialPowers.setCharPref(WHITELIST_PREF, uriPrePath);

I just wanted to add a note that you'll need to change your test to use the new permissions code rather than whitelists. If you pull the latest from m-c, you can take a look at the voicemail tests which have now been updated :)
Attachment #654996 - Flags: feedback+
(In reply to Marshall Culpepper [:marshall_law] from comment #39)
> Comment on attachment 654992 [details] [diff] [review]
> Part 1: DOM API - v2.
> 
> Review of attachment 654992 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Let's look into the feasibility of reusing nsIDOMMozNetworkInfo here, see
> below.
> 
> ::: dom/network/interfaces/nsIDOMMobileConnection.idl
> @@ +24,5 @@
> >  
> >    /**
> > +   * Information stored in the device's ICC card.
> > +   */
> > +  readonly attribute nsIDOMMozMobileICCInfo icc;
> 
> minor bikeshed: Technically all we're really representing here is a mobile
> network (MNC / MCC combo). I would prefer if we reused nsIDOMMozNetworkInfo
> here, and name the attribute something like |cardNetwork|. Since we only
> have the MCC and MNC codes, shortName and longName could remain null, and we
> could add a new state string, to indicate the source of the network (i.e.
> "card"?)

IMHO having something like nsIDOMMozMobileICCInfo allows us to gather together all the information coming from the ICC card to be exposed to content. This bugs deals with subscriber's home network codes but next could be other properties (e.g. ICCID from bug 785072). That's idea behind nsIDOMMozMobileICCInfo object. What do you think about that? 

> 
> Side rant: Part of me wonders if it would make more sense to move all of
> these card APIs into one place like "MobileCard"? That's definitely outside
> the scope of this bug, though.

Fully agree. mozMobileConnection is a great idea (thanks philikon) for dealing with both voice and data network status but it also contains some ICC card related stuff that IMHO should life in another API as you suggested.
(In reply to Marshall Culpepper [:marshall_law] from comment #39)
> Side rant: Part of me wonders if it would make more sense to move all of
> these card APIs into one place like "MobileCard"? That's definitely outside
> the scope of this bug, though.

So I never told you guys my grand master plan which was to unify all card-related functionality in mozMobileConnection.icc. Yoshi is creating this object as part of the STK in bug 744714. Once that has landed we can slowly unify all card-related things there, including the `cardState` property etc.

But let's do this step by step. We need to get all these pieces landed somehow. So I'd be ok with landing this stuff in its current form (modulo renaming `icc` to `iccInfo` in this bug so we don't collide with bug 744714), but be sure to file follow-ups for unifying them.

Sound good?
(In reply to Philipp von Weitershausen [:philikon] from comment #42)
> So I never told you guys my grand master plan which was to unify all
> card-related functionality in mozMobileConnection.icc.

You never tell me your plans, especially the grand master ones :(

> Sound good?

Sounds good to me -- Jose, if you want to make Phil's suggested change I will r+ (also don't forget to update the test to use permission manager)
Attached patch Part 1: DOM API - v3. (obsolete) — Splinter Review
Attachment #654992 - Attachment is obsolete: true
Attachment #654994 - Attachment is obsolete: true
Attachment #654996 - Attachment is obsolete: true
Attachment #655030 - Attachment is obsolete: true
Attachment #656474 - Flags: review?(marshall)
Attached patch Part 2: DOM impl (C++) - v3. (obsolete) — Splinter Review
Do I need to request review at smaug again?. I'm setting r+ since smaug did it.
Attachment #656476 - Flags: review+
Attached patch Part 3: RIL impl - v3. (obsolete) — Splinter Review
Attachment #656477 - Flags: review?(marshall)
Attached patch Part 4: Tests - V1. (obsolete) — Splinter Review
I was not able to test this test suite on the emulator. It's almost impossible. I can try again, Marshall please tell me what to do.
Attachment #656480 - Flags: review?(marshall)
Comment on attachment 656474 [details] [diff] [review]
Part 1: DOM API - v3.

Review of attachment 656474 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, r+ with the comment below

::: dom/network/interfaces/nsIDOMMobileConnection.idl
@@ +344,5 @@
> +[scriptable, uuid(109c1117-1199-47aa-aad2-ea9f456220fa)]
> +interface nsIDOMMozMobileICCInfo : nsISupports
> +{
> +  /**
> +   * Mobile Country Code (MCC) of the network operator

minor nit: can we make sure this (and the comment for MNC) are updated to mention that this is the MCC / MNC of the device's home network / ICC
Attachment #656474 - Flags: review?(marshall) → review+
Comment on attachment 656477 [details] [diff] [review]
Part 3: RIL impl - v3.

Review of attachment 656477 [details] [diff] [review]:
-----------------------------------------------------------------

Good work! r+ with minor nits below :)

::: dom/system/gonk/RILContentHelper.js
@@ +251,5 @@
>  
>    // nsIRILContentHelper
>  
>    cardState:           RIL.GECKO_CARDSTATE_UNAVAILABLE,
> +  iccInfo: null,

nit: can you line up |null| with the other values in this block?

::: dom/system/gonk/RadioInterfaceLayer.js
@@ +997,5 @@
> +    this.rilContext.icc = message;
> +    if (oldIcc && (oldIcc.mcc == message.mcc || oldIcc.mnc == message.mnc)) {
> +      return;
> +    }
> +    // RIL:IccInfoChanged corresponds to a DOM event that gets fired only 

nit: trailing space
Attachment #656477 - Flags: review?(marshall) → review+
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #47) 
> I was not able to test this test suite on the emulator. It's almost
> impossible. I can try again, Marshall please tell me what to do.

Yeah, it is really flaky. My general workflow for marionette testing is:

- Make sure you're on the ARM emulator config (./config.sh emulator) -- Emulator x86 is problematic
- ./build.sh && ./test.sh $PWD/gecko/dom/network/tests/marionette/test_mobile_iccinfo.js

While the build is running or the emulator is starting, in another terminal:
- adb kill-server; adb -e logcat

If logcat doesn't start printing soon after the emulator window opens, kill logcat, then do this again:
- adb kill-server; adb -e logcat;

If you are fast enough, marionette should be able to connect after the 2nd kill-server (but this is not always necessary)
Comment on attachment 656480 [details] [diff] [review]
Part 4: Tests - V1.

Review of attachment 656480 [details] [diff] [review]:
-----------------------------------------------------------------

r+ so long as you can run the test and verify it passes. Also, you will need to make the change I mentioned below

::: dom/network/tests/marionette/test_mobile_iccinfo.js
@@ +13,5 @@
> +// See it here {B2G_HOME}/external/qemu/telephony/android_modem.c#L2465.
> +is(connection.iccInfo.mcc, 310);
> +is(connection.iccInfo.mnc, 260);
> +
> +SpecialPowers.clearUserPref(WHITELIST_PREF);

This needs to be:

SpecialPowers.removePermission("mobileconnection", document);
Attachment #656480 - Flags: review?(marshall) → review+
Attached patch Part 1: DOM API - v4. (obsolete) — Splinter Review
Comments addressed, final patch.
Attachment #656474 - Attachment is obsolete: true
Attachment #656476 - Attachment is obsolete: true
Attachment #656477 - Attachment is obsolete: true
Attachment #656480 - Attachment is obsolete: true
Attached patch Part 2: DOM impl (C++) - v4. (obsolete) — Splinter Review
Final patch.
Attached patch Part 3: RIL impl - v4. (obsolete) — Splinter Review
Fixed a typo and comments are addressed. Final pacth.
Attached patch Part 4: Tests - V2. (obsolete) — Splinter Review
Latest tests implementation.
Attached patch Part 1: DOM API - v5. (obsolete) — Splinter Review
Rebasing patch.
Attachment #656915 - Attachment is obsolete: true
Attachment #656917 - Attachment is obsolete: true
Attachment #656920 - Attachment is obsolete: true
Attachment #656922 - Attachment is obsolete: true
Attachment #657014 - Flags: review+
Attached patch Part 2: DOM impl (C++) - v5. (obsolete) — Splinter Review
Rebasing patch.
Attachment #657015 - Flags: review+
Rebasing patch.
Attachment #657016 - Flags: review+
We need to run these tests on the emulator.
Attachment #657069 - Flags: review+
Rebasing path after latest Kyle Huey's changes.
Attachment #657014 - Attachment is obsolete: true
Attachment #657336 - Flags: review+
Rebasing path after latest Kyle's changes. Requesting review at smaug since I think that It would be nice to have a double check that everything is right.
Attachment #657015 - Attachment is obsolete: true
Attachment #657337 - Flags: review?(bugs)
Attachment #657337 - Attachment is patch: true
Attachment #657337 - Flags: review?(bugs) → review+
Using your patches and https://bugzilla.mozilla.org/show_bug.cgi?id=787967, extending a bit (nothing very complex, just adding new fields spn and msisdn in your iccInfo object), and then extending Gaia settings app, I'm now able to display the MCC/MNC, SPN and MSISDN from SIM card in Settings application :)

SPN is the carrier name in the SIM card, and MSISDN is your phone number. The last one is already available in gecko, and it's definitively useful I think to expose it (Android does show the phone number in "Settings -> About -> Phone").
Attached image With ICC info exposed
Just FYI, this is what I can get by adding spn and msisdn.
(In reply to Alexandre LISSY :gerard-majax from comment #64)
> Created attachment 657944 [details]
> With ICC info exposed
> 
> Just FYI, this is what I can get by adding spn and msisdn.

Awesome. Thanks. Can you file a new bug for this and attach the patch there since this bug is resolved? I think you're already exposing SPN in bug 787967, so maybe just file one for the MSISDN?
You need to log in before you can comment on or make changes to this bug.