Become a fan of Slashdot on Facebook


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Synopsis (Score 5, Informative) 102

I'm not a fan of that article summary.

New summary:
It is the same as CRIME, but we're using your browser's performance timing JS API as the man-in-the-middle.

A review:
Stick sensitive info into compressed stuff, and you make that sensitive info less private. If the encryption is zlib-like, then the attacker can guess the information quite quickly-- a good compressor compresses substrings, not just the whole thing.
That means that if you have a SSN in there, the attacker can guess some substrings of your SSN, and the response won't be much bigger.
Guesses that don't share substrings with your SSN will be larger-- the attacker can reject those as bad guesses and not try those substrings again.

With HTTP2's HPACK compressor (only used for info in the headers), this side-channel is eliminated-- only an exact guess of the data will allow this to happen.This is completely unrelated, however, to someone using entity-body compression with HTTP2. If you mix sensitive data with everything else in the compressed-entity body... side channel attacks galore!

A mitigation: Don't put the sensitive data in the same resource as the non-sensitive data, and then don't compress the sensitive data.
HTTP2 makes this cheaper. If sites do this, then these attacks simply do not work any better than the brute-force guessing would.
Ensuring that this happens (no sensitive data compressed) isn't necessarily the most easy thing...

Another obvious one is disable the timing API for 3rd party stuff. This is not as effective theoretically, but it is way easier to deploy and makes these kinds of attacks require an external 3rd party.

Comment Re:Not a problem, nothing to see here (Score 1) 218

They throttle providers who've not opted in even when you're paying for the bytes, however.
So, they're exactly doing what you're saying should be unacceptabe:
There charging you for X bytes, but not providing them at the same level of service because those providers didn't reduce the quality to an arbitrary resolution (instead of bitrate, which MAY have made some sense), and didn't make the content modifiable and snoopable (HTTP is *required* if video is to be unthrottled).

Comment Re:Nope (Score 1) 218

Their "technical requirements" don't actually make technical sense, however, and distort the market by putting an arbitrary cap on resolutions (instead of bitrate) and requiring the video to be snoopable and modifiable.

If they said: Hey, the user can opt in (instead of opting out) to "Free" service, and all they need to do is opt-in, and have the content provider react to whatever throttling that t-mobile is doing, then it'd be fine. That isn't what they're doing.

Incidentally, *someone* has to pay for the bandwidth capacity. The end-user always ends up paying either directly, or indirectly for this.
All zero-rating does in this case is allow the provider leverage to pick winners and losers (and so extort money from the content provider and/or users).

Comment Re:That is utterly stupid (Score 1) 218

You pay higher costs either way because someone needs to pay for the bandwidth.
With zero-rating, however, the carrier gets to extract concessions out of either the user or the content provider, increasing overall costs at higher rates because they can do things that actively harm the user when they want to extract more "value" from the content provider.

Comment Re:That is utterly stupid (Score 1) 218

Oh boy.

Lets pare this down to the mechanics of what is happening:
Users pay money to carrier, which builds infrastructure which supports X bandwidth.
Instead of giving everyone (n people) X/n bandwidth, they say that they'll offer some fixed bandwidth.. unless you're watching video.
If you're watching video, they'll screw with the packets (even if you're paying for them) unless you've opted out entirely of the binge-on program.
A provider must provide 720p video (even if they could have provided 1080p or better with the same bandwidth), unsecured (you must use HTTP only), and allow t-mobile to modify the content.

It reduces user choice: They CANNOT receive the video they are quite literally paying for unless that video provider has opted in by reducing security and providing shittier quality.

Comment Re:Wha? (Score 1) 218

This is amusing.

Carrier: We're going to raise the rates for everyone (someone has to pay for the bandwidth, and this always ends up coming from the consumer), but then we're going to give you insecure, lower-quality video for "free". .... and, apparently, people cheer.

They shouldn't be happy with this. They're paying more for worse service, and letting the carrier dictate the terms of their user experience instead of the market.

Comment Re:Wha? (Score 1) 218

Correct. They throttle video streams even for those services that have not opted in.
Oh, and for a service to opt in, you need to disable serving over HTTPS, and you have to allow T-mo to modify the video, etc.

So, it is entirely not neutral.

Zero rate content inevitably comes back to cost consumers more. Work out the game theory: Someone always pays for this, and since the consumers are the money source in this every time, they inevitably pay one way or another. Zero-rating simply provides an easy way to distort the market, which benefits only the carrier.

A more reasonable plan would be to throttle everyone after they use some amount of bytes, and ignore content type, etc. and not require the providers to use insecure protocols, modification, etc.

Comment Re:Wha? (Score 1) 218

Nope, you're wrong. It isn't a universal good. It is a way for T-mo to blackmail providers into "opting in" because they eff-up the packets from providers who don't.

This isn't theoretical.

Oh, and they require that you don't use HTTPS, which means that they're saying FU to your privacy, etc.

So, no, you're really wrong.

Slashdot Top Deals

Asynchronous inputs are at the root of our race problems. -- D. Winker and F. Prosser