No site served over unencrypted HTTP can be considered trusted. So there's no circumstance under which they should insert this header, since they can't modify HTTPS requests.

Consider the circumstance where a carrier portal sits on subnets owned by the carrier. In this case, unencrypted HTTP requests to the portal originating from the carrier's proxy are usually considered trusted.

In such a circumstance, carriers may consider this "trusted".

That's true. I imagine they'll be considering some third-party sites trusted too.

I believe that in cases where the third party site lies outside the carrier infrastructure and the header is plain text (some carriers encrypt the value), a carrier<->site operator VPN is required.

People shouldn't really be surprised that ALL mobile web traffic is heavily proxied (and transformed, by default). You probably wouldn't want to experience a direct net connection as flaky as mobile ones actually are.

Can you tell us more about the kind of people who count as a trusted site, how you get on this list, and if this is made public/opt-outable anywhere? (Thanks for reporting!)

The criteria varies per carrier. In most cases, a trusted site is one run or owned by the carrier (e.g. carrier portal site). Getting on this list usually (from what I understand) requires a whole lot of paperwork and approvals.

In terms of being made public or opt-outable, I'm not aware of any carriers that do this. I guess it depends on which 3rd party sites have negotiated agreements and obtained appropriate opt-ins from you and/or the carrier in various Terms of Agreements. For example, banking sites probably get a free pass when it comes to your mobile number because you may have entered it in to the banking application for verification purposes (just an example).

It's the 3rd party sites I'm more interested in - I can see that carriers may want it as a security function for internal websites and as they already have your number and all your details anyway, it's not really an issue then.

For instance with your banking example, yes, I may have given my number and probably have if I'm a customer. But what if I'm just browsing a banks website thinking about opening an account? Should they have my number then? (but of course banks are unlikely to abuse this for spam or anything.)

But can you see how people would think this is a grey area with potential for abuse? So basically, we just have to trust our carriers not to sell us out with no way of checking up on them?

> For instance with your banking example, yes, I may have given my number and probably have if I'm a customer. But what if I'm just browsing a banks website thinking about opening an account?

Sorry I wasn't clearer. I was referring to the use-case where you have an HTTPS connection open with the banking site, and the carrier has agreed to send your mobile number to the banking site only under these conditions (perhaps for security/tracing/auditing purposes).

>Should they have my number then? (but of course banks are unlikely to abuse this for spam or anything.)

I'm not a carrier, but I'm pretty sure that we're on same page here when I say that ideally no egress HTTP request destined beyond/outside of the carrier network should contain a plaintext mobile number.

> But can you see how people would think this is a grey area with potential for abuse?

Yes. This is the same grey area with the potential for abuse that every single company must deal with whenever we hand them our personal information (Google, Facebook, etc).

> So basically, we just have to trust our carriers not to sell us out with no way of checking up on them?

I'm not sure why you're implying that I hold this opinion. It seems we're in violent agreement here.

EDIT: In essence, we do trust carriers not to sell our data and "sell us out" too much. Given the amount of personal data and habits that telecom companies have on us, I'm surprised that they haven't sold our records, logs and patterns to marketing firms. For all we know, they might be doing that already. </tinhat>

>Sorry I wasn't clearer. I was referring to the use-case where you have an HTTPS connection open with the banking site, and the carrier has agreed to send your mobile number to the banking site only under these conditions (perhaps for security/tracing/auditing purposes).

I'm confused, how do they insert headers in to HTTPS?

> Yes. This is the same grey area with the potential for abuse that every single company must deal with whenever we hand them our personal information (Google, Facebook, etc).

Of course, and in all these cases having a way to check up on what is done would be good.

> I'm not sure why you're implying that I hold this opinion. It seems we're in violent agreement here.

I wasn't trying to imply anything about your opinions at all, sorry, bad grammar. I was strictly talking about my own opinions.

I forget the details, but mostly all I remember was that it was a huge PITA to work with HTTPS connections (all the more reason to try to use it more often, given the lack of other alternatives).

A few of possible methods of inserting a mobile number into a HTTPS connection:

1) Instead of negotiating a TLS end-to-end tunnel with the banking site, have the device negotiate the tunnel with the proxy, and then the proxy initiates a second tunnel with the banking site. This require[d|s] a lot of finangling with the trusted certs on the device (usually burned in via firmware for older phones). I don't know anybody that does this today; I only list it here as a possibility.

2) Believe it or not, some older devices actually sent the mobile number as part of the HTTP headers originating from the device browser user-agent. For these devices, content sites using HTTPS connections were almost always guaranteed to receive the mobile number (the irony is rich). In these scenarios, carrier proxies would actually strip the mobile number or other identifying characteristics from the outbound HTTP requests.

3) More straight-forward, a bank installs a native user-agent on the device (e.g. banking app) that injects the mobile number after negotiating an e2e TLS tunnel.

#2 didn't admittedly answer your question, but I threw it in there for the sake of completeness.

Yes, where I am it's often used to direct-to-bill services such as purchasing ringtones. The user clicks on 'purchase ringtone / song etc' and doesn't have to enter any payment information. The partner site has access to the number that they have to bill to. Since this is not controlled for or re-checked, there have been incidents of billing fraud (just set the header yourself with someone else's number).

The same thing could be acheived using a one-way hashed version of the mobile number, which removes the personal information and still allows the carrier to identify the handset customer.

There's no good reason to include the actual mobile number in the headers, internal or not.