When users of their network visit a site O2 inject the mobile phone number of the user into the request. This is then available to the website host, which raises obvious data protection issues. O2 does this by modifying the HTTP request and inserting the number in the 'x-up-calling-line-id' HTTP header.
Alarmingly, it does this to all unencrypted site visits (i.e. 'http' not 'https'), and these end-sites can trivially harvest the mobile numbers of visitors and link these to content visited.
This can be verified by visiting http://lew.io/headers.php on an O2 mobile device. The site serves as a tool to show the visitor the HTTP headers received by the server when the user requests that particular page.
COVERING LETTER WITH EMAIL TO casework@ico.gsi.gov.uk:
To whom it may concern,
Please find attached my complaint against O2 under the Data Protection Act.
When users of their network visits a site O2 inject the mobile phone number of the user into the request. This is then available to the website host, which raises obvious data protection issues.
Just been looking into this and from the little info I can find, it looks like your phone number would be classed as personal information and so covered by the data protection act.
Yeah. Just submitted a form as well and got response from ICO that case work has been received. According to the law, companies that break Data Protection, can be fined up to £500,000 per case.
Technically the organisation in breach would receive a penalty, not a fine. I realise that's a bit pedantic but there is a difference (fines can usually only be made and enforced by the courts).
The ICO can also prosecute the company and officers in the criminal courts under some situations, including: "unlawfully obtaining, disclosing, or procuring the disclosure of personal data;" (I don't know whether this would count as unlawful disclosure or not).
You should absolutely expect a response. The ICO was set up exactly for cases like these and is funded by the taxes you are paying.
Make sure you have filled in the correct complaint forms and provided your personal details. Sending an email with a link to the lew.io site or this HN thread is useless to them.
That page suggests you can only complain if you've been personally affected.
Although I've been on O2 in the past, I don't have any evidence that the problem occurred during that time. I'm on Orange now, which appears to be unaffected.
It's a pain, because I'd been thinking about switching back to O2 to get Visual Voicemail, which no other UK provider appears to be able to support.
I am in the process of doing this now, also my contract expires this month with them and I will be moving to another provider - do we know it if only affects 02?
Here's a statement from the Information Commissioner's Office:
"When people visit a website via their mobile phone they would not expect their number to be made available to that website.
"We will now speak to O2 to remind them of their data breach notification obligations, and to better understand what has happened, before we decide how to proceed."
"The Information Commissioner's Office said it is considering whether to investigate further, although a spokesman said there was no immediate breach of the Data Protection Act. A mobile phone number on its own is not classed as "personally identifying information" (PII), because it does not identify an individual on its own; but the spokesman said the office would consider whether other personal data was being processed at the same time."
I just google my phone number and found all my other details though, better fix that.
Firstly I don't work for O2 but I work in the mobile industry. O2 should only be passing your number to trusted sites (and to get on that list is pretty hard).
We have reported it to them via various internal contacts we have. Hopefully they will fix this soon!
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".
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.
Glad this is being brought to attention finally (as it seems it's been discovered before), but this is just yet another case of a UK mobile operator losing my trust.
O2: Send number in plain-text to every website visited. [1]
Orange: Increase fixed contract price by RPI through use of dodgy contract clause. [2]
Three: Place a non-payment flag on my credit report for no apparent reason. When I realise years later, they remove it and don't even apologise.
I'm running out of operators which haven't negatively impacted me, and to be honest, I think some of the blame must land with OFCOM.
Let's not forget Vodafone, who released an update for Android at about the same time 2.2 was arriving. Only it wasn't 2.2, it was a whole load of Vodafone-branded cruft for 2.1 that couldn't be removed.
The only way to reliably work around operators messing around with what you access (inserting their own client side code and such) and potentially inserting stuff into the headers like this too is to use a VPN for all Internet traffic that isn't otherwise tamper proof (i.e. HTTPS with a properly signed cert).
I use OpenVPN when I have my netbook tethered to my phone (or when I use any other "untrusted" wireless network for that matter) and route all traffic through my home fibre (I'm with an ISP that I know doesn't mess with my traffic).
There are problems with that though:
* installing OpenVPN on Android is a faf (I've still not got around to it on my device) [see http://vpnblog.info/android-openvpn-strongvpn.html and similar] - most users are not going to want to mess around like that
* there is no garantee that it will even work (or work efficiently enough) on all networks, or they could classify all encrypted traffic in the same lump as encrypted P2P connections and shape/block accordingly
* any VPN adds overheads (at least a set of headers per packet, and keep-alive packets when the connection is otherwise inactive), so if you don't have a cheap data plan that could be a consideration
You need to reboot after changing the APN + username (going into airplane mode, etc, isn't enough), then it stops sending the password, or at least did for me.
A lot of mobile network operators wash this information about or have it hashed into some other form (which means it can still be used as a unique identifier)
In his webpage he also says "They downgrade all images and insert a javascript link into the HTML of each page."
The image downgrading has been know about for ages, the JS I have not heard about before. I have asked for more info on Twitter but will investigate myself if I can find time today.
We got aware of that problem in October 2011 during relaunch of our website and we faced it also with t-mobile in germany. After digging around helpful sources have been
Besides injecting the bmi.js they also do their own javascript compression. At that time we had our own minified version of jquery, which got corrupted by their compression. They assume that /* always denotes a starting comment. This is wrong for the jquery lib, which contains some strings containing /* to denote mime type patterns. Anyways, we solved those compression issues with cache-control:no-transform. Also gzip compressing the HTTP responses worked.
As Lewis replies, "@O2 User-agent header ID's the device. Passing mobile number to third party sites is not ok! Seems like a data protection act breach to me?"
Being charitable, that could be clueless support rather than official policy response but hopefully the storm coming their way will get an official response soon.
From the oracle (Wikipedia),
Data must not be disclosed to other parties without the consent of the individual whom it is about, unless there is legislation or other overriding legitimate reason to share the information (for example, the prevention or detection of crime). It is an offence for Other Parties to obtain this personal data without authorisation.
It is in fact illegal for the website to obtain this information... Lew, you're going down... Only joking.
Their twitter has now exploded with a flurry of tweets like '@user we are investigating these reports and will provide more information as soon as we can.'
The javascript changes all image URL's to lower quality versions from O2's servers, it also provides a helpful little function which lets you use a hotkey (Alt+D I believe) to download all the images in full quality. The javascript comes from the domain //1.2.3.4/bmi-int-js/bmi.js (Not a real domain, only works behind O2's proxy)
If an image is loaded from a third-party site then presumably that request's header also includes the phone number. Can anyone confirm? That would mean that it's not just the website you're visiting that's getting your phone number, but advertisers too.
The link insertion reminds me of an ISP in another country that was rewriting HTML before sending it. If we want to get very technical, if this happened in the US, couldn't an ISP be dinged for creating a "derived work" of a copyrighted page without permission?
I think that is opening up a can of worms I would rather not see opened. Technically caching could be seen as copyright infringement.
Quite a few ISP's run transparent proxies for caching and technically every time you visit a website you are creating a copy of it on your local drive. If I disable javascript or run other scripts (like via grease-monkey) I am also technically creating "derived work".
The write-up is more charitable when it comes to the possible reason why this may be happening. The specific quote: " Our suspicion is that the feature is used by internal O2 websites to identify the user trying to make changes to the account, but that one or more of O2's proxy servers have been misconfigured."
x-up-calling-line-id (and similar headers from other gateway vendors) are typically not meant to be sent in the clear beyond internal sites. Perhaps a certain set/class of URL ACLs were (mis)configured during a maintenance window that caused this to happen.
Similar to how websites leave cookies, carriers have always had the ability to send certain identifying information to external sites. Usually, such identifying information is munged in some way that doesn't make it possible to determine the mobile number of the subscriber.
The funny thing is that people are often surprisingly willing to provide their phone number on more and more sites, which then makes it trivial for such services to link the anonymized identifier with the actual mobile number.
Regarding the customer support folks, it's highly unlikely that they know anything about HTTP headers, since they are typically level 1 support. This type of query/complaint would be filtered up to level 2 or 3 usually quite quickly once enough customers start calling in, or if somebody happens to be reading certain media outlets (e.g. HN).
Some tweets claim it isn't happening for them any more so maybe this was a mistake being fixed?
However, amusing it's a honest mistake being fixed, this still SHOULD NOT HAPPEN in the first place. Companies dealing with personal data need to be more careful when the ramifications of "honest mistakes" can be so serious. It's right that people are making a fuss about this and pressuring O2 to fix this.
> The funny thing is that people are often surprisingly willing to provide their phone number on more and more sites, which then makes it trivial for such services to link the anonymized identifier with the actual mobile number.
I would sodding hope it's illegal in the UK to! Altho as IANAL I can't think of which law exactly would cover it. Anyone know? I'm envious, you Germans have great privacy laws.
You mean "should have implemented". It's left to member countries to make the laws to match the directives, and if the EU thinks the law doesn't match the directive it's a very long legal process to sort it out.
The example in the UK I can think about is the detention in prison without trial for terrorism case. When the European court said "Ah, no." they scrapped it. And instead brought in house arrest without trial. Cue another long legal process.
But yes, I agree the EU has some great bits :-)
(Again, IANAL, and I worry I'm confusing the EU, European Commission and European court here ...)
Germany's privacy laws are pretty special and predate the EU. Privacy of post and telecommunication has been in the Federal constitution from the start (article 10; the constitution took effect in 1949 and the consisted of articles 1-18) and basically say that the privacy of communication over a distance is inviolable.
The courts have interpreted this privacy as applying not only to the carrier, but also as a duty each end of the communication has to the other. I understand that if someone outside Germany were to call me (in Germany), I could not legally record the conversation until I had informed you of what I was about to do.
Data protection act - Data must not be disclosed to other parties without the consent of the individual whom it is about, unless there is legislation or other overriding legitimate reason to share the information (for example, the prevention or detection of crime). It is an offence for Other Parties to obtain this personal data without authorisation.
I suspect any legal case would hinge on whether your mobile phone number counted as personal data or not. Again, IANAL, but the Data Protection Act is not specific on what counts as personal data and instead leaves it up to case law and I think the data registrar(?) to clarify.
On the other hand, in some contexts we hand our numbers out freely :-) I may be being pessimistic, but I suspect lawyers would have expensive "fun" with the details of this one.
Using Opera Mini seems to disable this "feature". Of course, doing so means all of my web traffic goes via Oslo. And of course, any apps using an http API are presumably affected too. I'm rather disappointed to hear about this.
Opera Mini uses its own protocol to talk to the proxy. HTTP is quite chatty, so there's a lot of mileage in reducing the headers by simply omitting a lot of unneeded information and compressing the rest.
That article is actually hilarious in how bad it is.
Lines like this one:
"The message was so convincing that the iPhone Anita was using believed it was genuine and listed it directly underneath the real message from that bank."
Show a complete misunderstanding of how SMS works. SMS is like email in that who it comes from is simply a type of header, which when sending from a mobile phone isn't editable - when a message arrives your phone can't verify where it actually came from. In particular given banks don't send from an official number, they send from a text name.
When using Skype messaging to a mobile number, you can enter your real mobile number as the 'from' address (In Skype settings). To do this Skype first sends you a confirmation message to the number you want to send from. I'm going to assume the confirmation message is Skype being curious, and that the same technology could be used without confirmation. Or is this an agreement with the mobile operators?
I disagree. SMS spoofing is a serious problem but not such a gigantic privacy issue as sending my phone number to every website I visit.
If it were merely some string that uniquely identifies me across different domains no matter how many times I reset my browse, it'd already be a privacy disaster. But making it my actual phone number? That's... just.. horrible.
Sadly I can say this is true for at least two US carriers.
One had obfuscated the number by padding it in a unique identifier header, and the other would send it along in some cases (i can't remember if it was on a partner by partner basis).
Also, almost every HTTP request on a mobile phone still passes through a HTTP Proxy. Generally, so avoiding opera, won't do any good. That is what the APN does.
What typically will get you off the carriers proxies is to use wi-fi, despite what the author says. They tend to get out of the loop if you're using someone else's network.
Wow, just tried this and my number is right there in plain text within the HTTP header.
I would never have signed the contract if I was aware that this would be happening.
Does anybody know if this is a new development or been happening forever?
Hopefully they fix this pronto, if not I'm not quite sure what to do since I'm really not comfortable using the service if this is happening and it's something I'm already signed up to pay for monthly for the next year at least!
It's quite unlikely that this has been going on forever. More likely that this was a gaffe or misconfiguration during some sort of operational maintenance.
Three (UK) don't do it, and it's worth also noting that @O2 has been in overdrive about trying to contain the twitter outrage. Good to see a large corp paying attention for once.
Called o2 support, stating I believe this is a breach of contract and wish to cancel my contract. The guy on the phone was not really sure how to handle this. Does anyone had any luck forcing o2 to cancel their contract based on this information? I kinda like Orange, no headers, and orange wednesdays
Confirmed with Samsung S2, Additionally, x-wap-profile provides phone model (GT-I9100)
Additionally, confirmed on HTC HD2 on Tesco Mobile - Custom ROM (ICS 4.03), thinks its a Nexus HD2 - Stock browser display phone number, Dolphin Mini also displays number!
To stop your o2 iPhone exposing your number through http headers, go to Settings > General -> Network -> Cellular Data Network, and change both APN to mobile.o2.co.uk and username to o2web (leaving password as is).
Apart from the obvious data protection issues, perhaps an even more interesting and frightening aspect of the issue is that that phone number is probably there for a reason. It's entirely possible that some O2 or O2 partner sites use that header field to associate a visitor with an O2 customer.
It would be interesting to see if that could be abused somehow, e.g. fake a phone number header to see if it's possible to "prank your friends" who use O2 or do something ever more malicious. (I'm not advocating anything like that, it's illegal and immoral and bad, I'm just curious if that would really work.)
I just checked again and it's not there any more. Anyone else seen the same pattern of seeing it in the past but not now?
Hopefully that means fixes are being rolled out.
Isn't this information used as an extra security layer when using your mobile phone for payments or bank transactions?
Here in The Netherlands when I want to use my mobile phone to log in to my bank account and do transactions, I first need to confirm my phone number and a special code. I can imagine that then they need the phone number in the header to verify it is my phone.
And how is this information different then an IP adress that they also have with each request?
>And how is this information different then an IP adress that they also have with each request?
Unscrupulous marketers can't do much with your IP address. They can do a lot more evil with your mobile number: SMS spam, cold calls, re-sell your data, etc, etc...
IP address does not always personally identify someone without extra information, usually obtainable only with a court order. Your IP address does not move with you, your number does. IP can not be used to personally bother you at any point in the future. This also makes a mockery of any "safe mode" browsing you do, enabling you to be tracked regardless.
Also, just because this can be used for good does not mean
A) it can't be used for bad
B) it is sharing private data that should only happen with your knowledge and consent
I can imagine a bank fraud detection system being more suspicious of unusually large transactions if they originate from an unusual phone number or ip address, yes.
Mobile networks seem to do all sorts of horrendous shit to peoples Internet connections. I found out this morning that T-Mobile UK's transparent web proxy breaks web sockets. They also break some websites by minifying javascript badly.
This is exactly why my phone has a VPN to my Linode server and routes out all Internet traffic over it. Mobile phone companies don't provide a clean Internet connection.
What they do is traffic shaping / policy management / caching to reduce the amount of traffic delivered to the device via the mobile network.
The issues here are part of the overall network neutrality theme besides privacy & user experience issues.
Key technologies used are DPI (deep packet inspection) and PCRF (policy & charging rule function) within their IMS and even on the edge of their networks (mostly caching plus location capture etc). There are whole application ecosystems around these providing specialized solutions depending on the infrastructure (provider) used by the TelCom.
Leaders of the pack providing such technology are Sandvine, Ericsson, NSN, Cisco, Procera, Allot & Arbor Networks. CDN providers like Akamai or Level3 are tmk also active here.
Beyond the above there are pure HW players that e.g. provide TCP/ IP processing equipment which allows real-time inspections of 10/100Gbps streams together with development stacks - typical development providers include Continuous Computing (they have some nice posters to familiarize you with normal TelCom infrastructure) and smaller ones like Cavium Networks.
Besides all of the above commercial tools there is the so-called Lawful-Inspection where who-god-knows is peeking into the telcom traffic with special installations (now also in almost all western countries) so that even the Telcos don't know where the data is going to.
To get an overview what is happening in that industry segment have a look at http://broabandtrafficmanagement.blogspot.com/ - be aware that the TelComs are using a special lingo and acronym soup!
I must say I am encouraged to see that some media coverage and, what seems to be an influx of emails to 02 by worried customers has managed to prompt a response from the company. Sadly, the concerns of who these nameless "trusted partners" are will no doubt have some people concerned.
They have a twitter bot that responds to everyone who tweets about the issue - "we are investigating these reports and will provide more information as soon as we can.'
Actually it does for me. Perhaps its the handset that determines this issue? I have a O2 PAYG HTC HD7 WP7.5 device that I use with GiffGaff and the page clearly lists the header and my phone number.
I had the header at 9.30 this morning. I just refreshed the page and my number has gone, so either they've fixed it or I'm using a different proxy that doesn't have the issue.
Now that is how a web page should look! It uses my preferred font at the preferred size and fills the entire width of the page with text. Congratulations!
slightly OT: there was a page that displays your full http request but I forgot the name. It was on the HN front page not too long ago. (I'm curious to see what my phone/provider sends)
A: In between the 10th of January and 1400 Wednesday 25th of January, in addition to the usual trusted partners, there has been the potential for disclosure of customers’ mobile phone numbers to further website owners.
Q: Has it been fixed?
A: Yes. It was fixed as of 1400 on Wednesday 25th January 2012.
[edited to add]
I find this a bit weaselly:
Q: Which websites do you normally share my mobile number with?
A: Only where absolutely required by trusted partners who work with us on age verification, premium content billing, such as for downloads, and O2's own services, have access to these mobile numbers.
When you browse from an O2 mobile, we add the user's mobile number to this technical information, but only with certain trusted partners. This is standard industry practice.
If you have ever used any payforit service to pay for goods, the intermediary you went through will at the very least have your MSISDN hashed and most likely in the clear (depends on your mobile network operator)
