[...] customer support (god, am I that customer?) followed by Google. I then found this blogpost “T-Mobile rewrites image urls” which is 13 months old, but I never noticed T-Mobile doing this. So they must have recently [...]
I have just discovered this, due to BT breaking my wired broadband connection and not bothering to fix it; a T-Mobile USB G3 adaptor was the cheapest way to get back online.
They don’t just rewrite the image URLs. They apply an extra level of compression to JPEG images. Lossy compression, of course. This results in very noticeably increased level of compression artefacts on the images… the image quality is ruined.
It is necessary to route all HTTP traffic via an encrypting proxy to keep T-Mobile’s noses out of my data and prevent them from rewriting image URLs and ruining the image quality with extra compression. This slows things down and adds an extra layer of nuisance.
I wouldn’t mind the lossy compression so much, but RFC1918 exists for a reason! 1.2.3.* is not theirs to play around with!
(Note that although the real 1.2.3.* is in Queensland in Australia, the 1.2.3.12 you see from T-Mobile is a fake one on their own network. This means that any site that happens to be hosted at the real 1.2.3.* is invisible to T-Mobile customers. Sigh.
@endashcunning don't put such pictures in iPhoto ;)February 7, 2012 7:26
@avbelow how could I! They usually need flash ;)February 7, 2012 7:10
Oh, I didn't know that Safari on iOS also has a p0rn mode. However, it's a little inconvenient to switch on. (thanks @fzwob, @CastIrony)February 7, 2012 6:54
xcodearchive archives an Xcode project... wait! Apple did not ship an xcodearchive command. But there is one now. https://t.co/fBWdKO2CFebruary 7, 2012 6:36
@antifuchs interesting - gonna try that one!February 7, 2012 6:02
7 Responses to T-Mobile rewrites image urls!
alex
March 3rd, 2010 at 12:20 am
Just checked, can’t confirm, are you sure?
D
March 7th, 2010 at 1:18 pm
Not just T-Mobile Austria. T-Mobile UK does it too and on every image URl in every site. What’s the craic?
studpete
March 10th, 2010 at 10:37 am
In Autstria, it seems to be only active on Egde.
@D
What’s de craic? If you scape data, you sometimes count on the full url. And such deep data change just stinks, sth like this should not be done.
Gerben
April 16th, 2011 at 2:26 pm
T-Mobile the Netherlands does this too.
What is ‘edge’?
It really is out-rageous, because they get redirected to a server in Australia.. which is the worst possible solution. I doubt it’s a CDN..
T-Mobile traffic through http://1.2.3.12
April 16th, 2011 at 4:25 pm
[...] customer support (god, am I that customer?) followed by Google. I then found this blogpost “T-Mobile rewrites image urls” which is 13 months old, but I never noticed T-Mobile doing this. So they must have recently [...]
Pigeon
May 22nd, 2011 at 2:05 am
I have just discovered this, due to BT breaking my wired broadband connection and not bothering to fix it; a T-Mobile USB G3 adaptor was the cheapest way to get back online.
They don’t just rewrite the image URLs. They apply an extra level of compression to JPEG images. Lossy compression, of course. This results in very noticeably increased level of compression artefacts on the images… the image quality is ruined.
It is necessary to route all HTTP traffic via an encrypting proxy to keep T-Mobile’s noses out of my data and prevent them from rewriting image URLs and ruining the image quality with extra compression. This slows things down and adds an extra layer of nuisance.
Basically, the whole thing sucks.
Thomas Thurman
September 9th, 2011 at 1:52 pm
I wouldn’t mind the lossy compression so much, but RFC1918 exists for a reason! 1.2.3.* is not theirs to play around with!
(Note that although the real 1.2.3.* is in Queensland in Australia, the 1.2.3.12 you see from T-Mobile is a fake one on their own network. This means that any site that happens to be hosted at the real 1.2.3.* is invisible to T-Mobile customers. Sigh.