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!
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.
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)
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.
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.
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.
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.
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)
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...
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.
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
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.
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.
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.
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!
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.
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.
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.
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).
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?
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?
179 comments
[ 2.5 ms ] story [ 209 ms ] threadAdditionally, 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!
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.
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.
It is in fact illegal for the website to obtain this information... Lew, you're going down... Only joking.
...and for people using iPod Touches or similar?
This tag is inserted in the head:
<script src="http://1.2.3.4/bmi-int-js/bmi.js language="javascript">
This is inserted at the end:
<script language="javascript"><!-- bmi_SafeAddOnload(bmi_load,"bmi_orig_img",0);//-->
</script>
The external JS is here: http://pastebin.com/rv3k4meX
Analysis please. At an initial glance it seems to just be about the image compression.
My quick glace at it agrees with you, it looks like it replaces the URLs of the images, presumably to load compressed versions.
http://stackoverflow.com/questions/4113268/how-to-stop-javas...
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.
Our boss saw errors loading the site on his iPad, but whenever we brought him into the office to try and replicate it, the problems disappeared.
We finally figured out it only happened when he was out the office, so on 3G not WiFi, and then managed to find the stackoverflow post you mention.
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).
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.
Sure, but that still doesn't excuse this.
However, I think it is generally percieved as personal.
A lot of these laws are from EU Directives, which the UK would have implemented aswell. Brussles isn't all bad! :P
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 ...)
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.
Cf. (in fairly straightforward German) http://www.gesetze-im-internet.de/gg/art_10.html
http://blog.silktide.com/2011/05/cookie-law-makes-most-uk-we...
Edit: It still includes your phone number, thanks msmithstubbs.
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
Thanks
Some popular headers to check
X-UP-CALLING-LINE-I
X_NOKIA_MSISDN
X_H3G_MSISDN
MSISDN
X_MSISDN
X_NETWORK_INFO
X-WAP-MSISDN
X-UP-SUBNO
Anyone any idea what it is?
(Edit: Looks like a big bunch of binary)
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...
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
*edit scratch that it is happening now. Both attempts were on 3G only. Seems it doesn't always happen.
Which probably means that your phone number is going to Oslo instead. At least it's not being proxied onwards from there.
and
http://community.giffgaff.com/t5/Contribute-Innovation-Promo...
and
http://community.giffgaff.com/t5/Contribute-Innovation-Promo...
This article seems to agree with us too: http://www.slashgear.com/o2-sharing-phone-numbers-for-mobile...
I wonder what the (de)selection criteria is then?
We have reported it to them via various internal contacts we have. Hopefully they will fix this soon!
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).
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?
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>
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.
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.
In such a circumstance, carriers may consider this "trusted".
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.
There's no good reason to include the actual mobile number in the headers, internal or not.
-------------------------
SECTION 4:
Name: Telefonica O2 UK Address: 260 Bath Road Postcode: SL1 4DX Phone: 0800 089 0202 email: peter.erksine@o2.com website: http://www.o2.co.uk
SECTION 6:
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.
SECTION 10:
Online utility that will show you the headers sent in your page request: http://lew.io/headers.php
Discussion on technical forum 'hacker news': http://news.ycombinator.org/item?id=3508857
Official O2 Twitter responding to (and misunderstanding/misrepresenting) the problem: https://twitter.com/#!/O2/status/161872584634408960
-------------------------
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.
Regards,
> "Hi Lewis. The mobile number in the HTML is linked to how the site determines that your browsing from a mobile device #O2Guru"
Wow.
They seem to have taken down the header now though.
http://blog.o2.co.uk/home/2012/01/o2-mobile-numbers-and-web-...
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).
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.
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.