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

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[José Antonio Olivera Ortega [:jaoo]]

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.

Comment 1

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 1: DOM API - v1.

Comment 2

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 2: DOM impl (C++) - v1.

Comment 3

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 3: RIL impl - v1.

Comment 4

[José Antonio Olivera Ortega [:jaoo]]

Nom'ed for basecamp since it should be a MUST have for v1.

Comment 5

[Marshall Culpepper [:marshall_law]]

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|?

Comment 6

[Marshall Culpepper [:marshall_law]]

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.

Comment 7

[Philipp von Weitershausen [:philikon]]

(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 8

[Marshall Culpepper [:marshall_law]]

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 9

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

So is this a legal requirement then?

Comment 11

[Beatriz Rodríguez [:brg]]

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.

Comment 12

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

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?

Comment 13

[José Antonio Olivera Ortega [:jaoo]]

(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

Comment 14

[Salvador de la Puente González [:salva]]

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

Comment 15

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 4: Tests - WIP v1.

WIP not tested yet since I'm not able to run the emulator and make tests. It builds successfully but doesn't boot.

Comment 16

[Marshall Culpepper [:marshall_law]]

(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?

Comment 17

[Marshall Culpepper [:marshall_law]]

(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?

Comment 18

[José Antonio Olivera Ortega [:jaoo]]

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

Comment 19

[Philipp von Weitershausen [:philikon]]

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

Comment 20

[Philipp von Weitershausen [:philikon]]

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

Comment 21

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(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).

Comment 22

[Beatriz Rodríguez [:brg]]

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 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 651716 [details] [diff] [review]
Part 1: DOM API - v1.

I'll leave the API up to Marshall here

Comment 24

[José Antonio Olivera Ortega [:jaoo]]

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

Comment 25

[Daniel Coloma:dcoloma]

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.

Comment 26

[José Antonio Olivera Ortega [:jaoo]]

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?

Comment 27

[Philipp von Weitershausen [:philikon]]

(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.)

Comment 28

[Marshall Culpepper [:marshall_law]]

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

Comment 29

[Marshall Culpepper [:marshall_law]]

Whoops, forgot to link to Daniel's comment:
https://bugzilla.mozilla.org/show_bug.cgi?id=785072#c5

Comment 30

[José Antonio Olivera Ortega [:jaoo]]

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.

Comment 31

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 1: DOM API - v2.

Comment 32

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 2: DOM impl (C++) - WIP.

Comment 33

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 3: RIL impl - v2.

Comment 34

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 4: Tests - WIP.

Comment 35

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 2: DOM impl (C++) - v2.

Comment 36

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 654992 [details] [diff] [review]
Part 1: DOM API - v2.

Note, DOM APIs must be reviewed by DOM peers.

Comment 37

[José Antonio Olivera Ortega [:jaoo]]

(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?

Comment 38

[Marshall Culpepper [:marshall_law]]

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?

Comment 39

[Marshall Culpepper [:marshall_law]]

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.

Comment 40

[Marshall Culpepper [:marshall_law]]

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 :)

Comment 41

[José Antonio Olivera Ortega [:jaoo]]

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

Comment 42

[Philipp von Weitershausen [:philikon]]

(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?

Comment 43

[Marshall Culpepper [:marshall_law]]

(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)

Comment 44

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 1: DOM API - v3.

Comment 45

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 2: DOM impl (C++) - v3.

Do I need to request review at smaug again?. I'm setting r+ since smaug did it.

Comment 46

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 3: RIL impl - v3.

Comment 47

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 4: Tests - V1.

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.

Comment 48

[Marshall Culpepper [:marshall_law]]

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

Comment 49

[Marshall Culpepper [:marshall_law]]

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

Comment 50

[Marshall Culpepper [:marshall_law]]

(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 51

[Marshall Culpepper [:marshall_law]]

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);

Comment 52

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 1: DOM API - v4.

Comments addressed, final patch.

Comment 53

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 2: DOM impl (C++) - v4.

Final patch.

Comment 54

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 3: RIL impl - v4.

Fixed a typo and comments are addressed. Final pacth.

Comment 55

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 4: Tests - V2.

Latest tests implementation.

Comment 56

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 1: DOM API - v5.

Rebasing patch.

Comment 57

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 2: DOM impl (C++) - v5.

Rebasing patch.

Comment 58

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 3: RIL impl - v5.

Rebasing patch.

Comment 59

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 4: Tests - V2.

We need to run these tests on the emulator.

Comment 60

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 1: DOM API - v6.

Rebasing path after latest Kyle Huey's changes.

Comment 61

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Part 2: DOM impl (C++) - v6.

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.

Comment 62

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d3afe713492d
https://hg.mozilla.org/integration/mozilla-inbound/rev/50a52c605969
https://hg.mozilla.org/integration/mozilla-inbound/rev/83285f6e4499
https://hg.mozilla.org/integration/mozilla-inbound/rev/56bee901049d

Comment 63

[:gerard-majax]

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").

Comment 64

[:gerard-majax]

Attachment: With ICC info exposed

Just FYI, this is what I can get by adding spn and msisdn.

Comment 65

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d3afe713492d
https://hg.mozilla.org/mozilla-central/rev/50a52c605969
https://hg.mozilla.org/mozilla-central/rev/83285f6e4499
https://hg.mozilla.org/mozilla-central/rev/56bee901049d

Comment 66

[Philipp von Weitershausen [:philikon]]

(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?

Comment 67

[:gerard-majax]

Done, see bug 788191.