[otoburb]

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

[jarofgreen]

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

[otoburb]

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.