T-Mobile Is Flat Out Lying: It's Throttling Video Even Though It Says It's Not
from the that's-not-true dept
Big companies often have a way of tap dancing around the truth. It's rarely lying, because they will choose their words carefully, in a manner that clearly misleads or distorts, but is not necessarily outright lying. T-Mobile, however, appears to be flat out lying. We recently wrote about the charges from YouTube that T-Mobile was throttling YouTube videos as part of its Binge On program that zero rates video on mobile phones so it doesn't count against data caps. We noted the problems with this program when it launched, but YouTube's claims take it even further.Again, the program supposedly "optimizes" video streams down to a lower resolution, with the promise that partner videos will not count against T-Mobile's data caps. However, YouTube pointed out that it is not a partner and its videos were being throttled, in clear violation of the clear "no throttling" rules from the FCC. T-Mobile took exception to my post about it and demanded corrections and clarifications, making a few different claims. After investigating the claims, I can say (1) that we will not be clarifying or correcting anything in the original post and (2) more importantly, it appears that T-Mobile is flat out lying in some of its claims. It's not dancing around the truth, it is claiming things that are simply untrue. This is the key claim that T-Mobile's PR person made to me:
Using the term “throttle” is misleading. We aren’t slowing down YouTube or any other site. In fact, because video is optimized for mobile devices, streaming from these sites should be just as fast, if not faster than before. A better phrase is “mobile optimized” or “lower resolution.”This is clearly not true. While you can have a semantic debate about whether "throttling" is "optimizing," the facts with T-Mobile are pretty clear: it is NOT optimizing YouTube videos at all. It is 100% throttling them.
When Binge On first launched without YouTube as a partner, many people asked why, and T-Mobile's VP of Engineering, Grant Castle, explained that the reason was because it could not identify YouTube videos, since nearly all YouTube traffic is encrypted. Thus, T-Mobile admitted that it had no way to "optimize" YouTube videos:
T-Mobile says the problem is technical. The software it is using to deliver streaming video at lower-definition quality needs to be able to identify the incoming traffic as being video as opposed to, say, photographs or email. It can’t always do that with YouTube.Thus, the only thing that T-Mobile can do for many YouTube encrypted streams is not to "optimize" it at all, but to flat out throttle it down to speeds around 1.5 mbps. You can see this in the tests done by Dualsim.us and the following video.
Most YouTube traffic uses a protocol called HTTPS, which T-Mobile can detect, but some portions may be using a less-used protocol called UDP that the wireless company has more difficulty reading, according to Grant Castle, vice president of engineering at T-Mobile. That means the carrier isn’t certain about the format of some streams coming from YouTube.
“YouTube is a little difficult,” said Mr. Castle.
Remember how T-Mobile in their message to me said that the "optimized" videos should show up "just as fast, if not faster than before." Yeah, that's bullshit. Watch the video below (I start the video about 5 minutes in -- the first five minutes mostly just show that the two phones are both on T-Mobile's unlimited network with similar speed connections -- at which point the video comparison is shown):
That's absolutely 100% throttling. There is no "optimization" going on because T-Mobile cannot optimize those videos, since they're encrypted.
T-Mobile is lying. Flat out lying.
And... in a bit of perfect timing, just as I was completing this post, I see that EFF has published the results of its own technical tests of BingeOn, which also confirm that there is no "optimization" here -- and got T-Mobile to admit it was lying. It's purely throttling:
Our last finding is that T-Mobile’s video “optimization” doesn’t actually alter or enhance the video stream for delivery to a mobile device over a mobile network in any way. This means T-Mobile’s “optimization” consists entirely of throttling the video stream’s throughput down to 1.5Mbps. If the video is more than 480p and the server sending the video doesn’t have a way to reduce or adapt the bitrate of the video as it’s being streamed, the result is stuttering and uneven streaming—exactly the opposite of the experience T-Mobile claims their “optimization” will have.In fact, the EFF study compared a hash of the download to a version that was on the server and found the files were identical (i.e., no "optimization" -- just purely throttling). Again, this is the exact opposite of what T-Mobile's PR person told me in demanding a correction. T-Mobile is lying.
Given the difference between what T-Mobile implies they do and what we found, we contacted them to get clarification. They confirmed that they don’t do any actual optimization of video streams other than reducing the bandwidth allocated to them (and relying on the provider to notice, and adapt the bitrate accordingly).
EFF also discovered that T-Mobile's earlier statement that it can't detect encrypted video is also misleading, as the company now claims it can:
The second major finding in our tests is that T-Mobile is throttling video downloads even when the filename and HTTP headers (specifically the Content-Type) indicate the file is not a video file. We asked T-Mobile if this means they are looking deeper than TCP and HTTP headers, and identifying video streams by inspecting the content of their customers’ communications, and they told us that they have solutions to detect video-specific protocols/patterns that do not involve the examination of actual content.Finally, EFF realized that even if you're just downloading the video (i.e., not streaming, but downloading for later viewing), you STILL get throttled:
The first result of our test confirms that when Binge On is enabled, T-Mobile throttles all HTML5 video streams to around 1.5Mps, even when the phone is capable of downloading at higher speeds, and regardless of whether or not the video provider enrolled in Binge On. This is the case whether the video is being streamed or being downloaded—which means that T-Mobile is artificially reducing the download speeds of customers with Binge On enabled, even if they’re downloading the video to watch later. It also means that videos are being throttled even if they’re being watched or downloaded to another device via a tethered connection.A separate claim in the email from T-Mobile is more of the "tap dancing around the truth" variety. And it's the claim that T-Mobile made it clear from the beginning that it would be doing this to non-partner videos as well. Here's what the T-Mobile rep said in the email to me:
This is how Binge On has always worked. We said it from the stage, in press materials, on the web, and in customer notifications last month, and media covered it last month, as well.This is extremely misleading. Nearly everyone I've spoken to among people who follow these issues had no idea that the "throttling" (not optimization) applied to non-partner videos. I, as a T-Mobile customer, also never received any such notice (though the PR person then forwarded me the "notification" email, so I guess technically I have now received it). Either way, I went back to look at the press release and T-Mobile's own page about Binge-On to see about how clearly the company really revealed that it would also be throttling non-partner video. And the company was not at all clear about it.
In the press release (not surprisingly), T-Mobile focuses on all the Binge On partners. To realize that it's also throttling other videos you have to carefully parse some confusing text buried in the 8th paragraph of the press release, which most people won't even recognize. Here are paragraphs four through eight -- with the relevant mention bolded (without that, you might miss it):
With Binge On, video now streams free for viewers and subscribers of Crackle, Encore, ESPN, Fox Sports, Fox Sports Go, HBO Now, HBO Go, Hulu, MLB, Movieplex, NBC Sports, Netflix, Sling TV, Sling Box, SHOWTIME, STARZ, T-Mobile TV, Univision Deportes, Ustream, Vessel, Vevo, VUDU—with more streaming services on the way—without ever touching their 4G LTE data on Simple Choice plans with extra data. T-Mobile is also including Verizon’s Go90 and AT&T’s DirecTV streaming services in Binge On, so even the Duopoly’s video services stream without fear of overages.So basically all of the press release is talking about how Binge On is about "free" video from partners, and then in the second half of a sentence, buried in the middle of a paragraph (eight paragraphs into the press release) is a tidbit about how "for all other videos" the bandwidth is downgraded (what T-Mobile falsely calls "optimized"). That is the farthest thing from being clear about what is happening.
Binge On is open to any streaming video provider who meets the technical requirements, which are available online at www.t-mobile.com/bingeon. And it’s completely free for video streaming providers to join.
“With Binge On, no one pays—not the customers, not the video streaming services—and everyone wins,” said Legere.
Powered by new technology built in to T-Mobile’s network, Binge On optimizes video for mobile screens, minimizing data consumption while still delivering DVD or better quality (e.g. 480p or better). That means more reliable streaming for services that stream free with Binge On, and for almost all other video, it means T-Mobile Simple Choice customers can watch up to three times more video from their data plan. And, as always, T-Mobile has put customers in total control with a switch to activate or deactivate Binge On for each line in their My T-Mobile account. Binge On is all about customer choice.
Similarly, on the website for Binge On itself, this is far from clear. Most of the page goes on and on and on about how "you can stream all you want for FREE without using your data." The clear implication is that video streaming doesn't count against a datacap. Lower down it has the following:
It's only if you go all the way to the bottom of the page and click to expand the first "question" about Binge On that it finally explains what this means:
Now, the big question: will the FCC actually do anything about this?
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: bingeon, lying, net neutrality, throttling, video, youtube, zero rating
Companies: t-mobile, youtube
Reader Comments
Subscribe: RSS
View by: Time | Thread
I spent much of the holidays writing a client to monitor UDP audio and meta-data streams from a (radio) scanner. I'm understandably curious: How is it more difficult to read the widely used UDP protocol?
[ link to this | view in chronology ]
Re:
I think the simple answer would be when you are squirting bullshit out of both sides of your mouth at once, there is little brainpower left with which to craft an honest answer.
[ link to this | view in chronology ]
Re:
https://en.wikipedia.org/wiki/QUIC
Specifically:
"QUIC supports a set of multiplexed connections between two endpoints over User Datagram Protocol (UDP), and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion."
Now I don't know for sure why their stuff can't detect it for sure but I would dare say the software they bought for this throttling/shaping purpose does not have the detection code build in.
[ link to this | view in chronology ]
Re: Re:
In other words, the problem isn't UDP, but a custom protocol they're using over it. But you'd have that problem with TCP also, where there are many protocols used over it. Including custom protocols used by Netflix, etc.
In any case the throttling is being done on HTML5 video from YouTube. HTML5 video should have been the *easiest* to decode. Where is QUIC even mentioned?
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
Your question applies to Netflix and T-Mobile's other partners, who no doubt HTTPS also. And yet T-Mobile has no problem detecting their partners' video.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Detecting video in HTTPS?!
So how in the blue blazes does T-mobile detect video served over HTTPS? If their DPI gear can penetrate HTTPS, then either they're mucking about with certificates so they can decrypt the stream, or else HTTPS is leaking information about the content, which in turn raises questions about how secure it is at protecting that content from observers.
[ link to this | view in chronology ]
Re: Detecting video in HTTPS?!
[ link to this | view in chronology ]
Re: Re: Detecting video in HTTPS?!
Edit: I would not be surprised to learn that the first few MB of each file transfers quickly, and then the throttling kicks in. This would let webpages load quickly.
[ link to this | view in chronology ]
Re: Re: Re: Detecting video in HTTPS?!
[ link to this | view in chronology ]
Re: Re: Re: Re: Detecting video in HTTPS?!
[ link to this | view in chronology ]
Re: Detecting video in HTTPS?!
[ link to this | view in chronology ]
Re: Detecting video in HTTPS?!
[ link to this | view in chronology ]
Re: Detecting video in HTTPS?!
[ link to this | view in chronology ]
A Darker Shade of Pink
[ link to this | view in chronology ]
Re: A Darker Shade of Pink
Perhaps this is a "Fuck NA markets" thing, as opposed to a "fuck Youtube" thing.
[ link to this | view in chronology ]
Consumer protection: FCC v FTC
However —this starts getting complicated— 15 U.S.C. § 45(a)(2) actually makes an exception to the FTC's jurisdiction for “common carriers subject to the Acts to regulate commerce”. Thus, the FCC's recent decision to reclassify broadband providers as common carriers has had an impact on the FTC's jurisdiction. For a little bit of discussion, see FTC v AT&T Mobility (N.D. Cal. Mar 31, 2015).
Now, I vaguely understand that “FTC and FCC agree to coordinate law enforcement efforts” (Nov 18, 2015): So, does anyone know whether the FTC's complaint wizard is still the right place to complain about T-Mobile's (allegedly) unfair and deceptive practices?
[ link to this | view in chronology ]
It was never "partners only"
[ link to this | view in chronology ]
Re: It was never "partners only"
[ link to this | view in chronology ]
Re: Re: It was never
[ link to this | view in chronology ]
Re: Re: Re: It was never
[ link to this | view in chronology ]
Note to T-Mobile. The only way to alleviate network congestion is to upgrade your networks infrastructure. Stop trying to Quality of Service (QoS) your way out of the problem. That only leads to high latency, packet loss, and slow download speeds. As we're currently seeing with YouTube videos.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
Yeah, really! Who cares that the company lied to the public and its customers, and broke the regulations against throttling. Who cares that it's purposely downgrading the internet that people paid for.
I mean, really what's the concern here?
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
oh, hush my mouth! i forgot briefly that those members of Congress actually endorse what is happening, in return for some 'campaign favors'! silly me!!
[ link to this | view in chronology ]
Re:
15 U.S.C. § 52 (Federal Trade Commission Act of 1914, as amended) So what do you want Congress to do? What's wrong with the FTC Act, as it's currently amended?
[ link to this | view in chronology ]
Poor mean throughput could still be caused by Binge On users being pointed to an overloaded server located thousands of miles and several additional router hops from them.
Identical routes and graphs proving traffic shaping would be more damning evidence.
[ link to this | view in chronology ]
You're already on T-mo's radar...
[ link to this | view in chronology ]
A: When their lips are moving.
[ link to this | view in chronology ]
To be fair...
BUT I still feel what they are doing is not in line with network neutrality. If I am requesting a full 1080p video, they should deliver that 1080p video, not a downgraded resolution. The video quality should be my choice.
At one point, I seriously considered switching to T-Mobile. With news like this, I'm glad I stayed with my current pre-paid carrier.
[ link to this | view in chronology ]
Re: To be fair...
[ link to this | view in chronology ]
Re: To be fair...
And yet, if you read the article...
and from the EFF...
So technically, yeah, they are throttling. And then taking the credit for any upstream optimisation, to boot!
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Recently in Mexico City and surrounding metropoles
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
Running Android/iOS versions of tcpdump & traceroute and having the phone stream something from YouTube would be much better.
[ link to this | view in chronology ]
bold...
This could have been packaged as non-discriminatory QoS. Keeping youtube and other sites from chewing up your data allocation by sending high res video to your tiny screen does have some value. If they wanted to do people a solid there and offer that, it would be optional. Aside from that, video/non-video is a red herring. They're slowing down content from sites. That's what people argued so hard against when we demanded net neutrality.
[ link to this | view in chronology ]
This is crap
[ link to this | view in chronology ]
Re: Detecting video in HTTPS?!
[ link to this | view in chronology ]
I have a recording of exactly what's up
Every single person's video over 480p counts as "high speed data", after your " high speed data" (read teather allowance) is up, then every single person enrolled in this *feature* will get video over 480p as throttled at 3g (128kbps).
You must call or sign into the T-Mobile app to decline this feature.
Every single T-Mobile user IS effected unless you opt out.
I've been working on getting my sound clip online, but I haven't gotten around to Censoring my personal info out of it.
It's from a high tier support, after I called with some iftop logs.
"*it's free stop complaining!!" Commenters, you are enrolled as well. Sure 480p video is "free", but also degrades your PAID service and 480p or higher video is calculated in your " high speed data" tethering data limit.
This part is an educated guess after playing with some family members sim cards in different states with different usage patterns. but, in order to keep numbers not matching other users I believe they have a customer data usage rating, throttling times/amounts/% are done based on our usage scales. (Who's a higher risk of using more data). Which sounds all conspiracy-ish, but would make it hard to prove this all.
Also, I the FCC said internet providers are utilities for cables and fiber kinda places. Cell companies can still. Unfortunately do this type of thing..
Hope to have this on my blog soon, check it out please? 😁
[ link to this | view in chronology ]