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.
Huh? They're throttling bytes that you're paying for because a content provider didn't accept some arbitrary restrictions (remove encryption, make video resolution (not bitrate) some arbitrary value, etc).
This means they're not treating the bytes you're *paying for* the same.
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).
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).
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.
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.
Incorrect. You must also disable any HTTPS, and allow t-mobile to modify your content. Who knows what else they are able to do with the content now that they can snoop on it and modify it.
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.
This is incorrect. They throttle any video site down, even if you're paying for the bandwidth unless you, the consumer, opt out of bing-on completely, which requires jumping through hoops.
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.
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.
Not to mention that it is basically impossible to deploy any new feature or new protocol over port 80 (i.e. unencrypted) thanks to the 'help' of these proxies.
This is why you'll see that HTTP2 is deployed basically only over encrypted:443.
Amusingly, because of the 'helpful' proxies, HTTPS can be faster than HTTP. With the advent of QUIC (i.e. HTTP2 plus improvements), HTTP will almost always be slower unless the carrier is doing something (intentionally?) to screw things up.
Having seen the result of design-by-committee (i.e. design by politics instead of designing to fit a functional need), I can say that it doesn't work.
The outcome is almost always better when the protocol has actually been implemented, the kinks worked out, and then you ask others to use it....You know, useful is a necessary component of reusable... But, if you're interested in FUD and a lack of progress instead of something which actually works, by all means do design-by-committee and get nearly useless protocols that implementers ignore.
There were 2 of these 10Kw units required to cruise at 75Mph, so the efficiency, assuming 35% thermal efficiency, is 22mpg.
Given that they're small and easy to maintain, perhaps that doesn't matter if they're only backups, or if this is just a first-iteration technology that may get substantially better.
The big concern imho, is vibration. Unlike a crankshaft-based engine/motor, there is no physical coupling of the pistons if you deploy two of these in a horizontal configuration (as TFA suggests would counter vibration). The lack of coupling means that the pistons are not mechanically synchronized, which means they don't create forces which act against each other.
I'd have to imagine that one could approximate the physical coupling by varying the timing and mixture, but.. I have no idea how actually effective that'd be.
Price controls don't do anything to increase the amount of available housing. It just means that people cannot find housing at all, and that the buildings aren't updated. Eliminating Prop 13, and making the market more liquid and reasonable would help a bit..
A couple decades back the impact of Prop 13 wasn't yet horribly visible. Worse, thanks to Prop 13, corporations pay far far less, and thus are less likely to give up property for sale.
No, they are NOT investors. If they were investors,they'd be in trouble with the FTC, which hasn't yet setup regulations allowing such.
People who use Kickstarter are pre-purchasing whatever it is they're being sold. That can act as income for a company, and thus a funding source, but that does not make people who purchase things via Kickstarter investors.
One of these days, we will be able to invest in this manner, but not yet.
Kickstarter doesn't do investing. It is a pre-purchase... I challenge you to find the word "invest" in the below (hint, it isn't there, nor is it *anywhere* on the Kickstarter page)
From Kickstarter:
Pledge $35 or more
22997 backers
You will receive a digital version of the movie within a few days of the movie’s theatrical debut, plus the T-shirt, plus the pdf of the shooting script. Naturally, you will also receive regular updates and behind-the-scenes scoop throughout the fundraising and movie making process. Available to US, Canada, Australia/New Zealand, Mexico, Brazil, and Select EU countries (Now including Norway and Switzerland! See Project Description for full list)
Slashdot Mirror
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.
Huh?
They're throttling bytes that you're paying for because a content provider didn't accept some arbitrary restrictions (remove encryption, make video resolution (not bitrate) some arbitrary value, etc).
This means they're not treating the bytes you're *paying for* the same.
This.
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).
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).
It isn't FUD when it is happening.
Troll on man, troll on!
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.
They *are* throttling providers not on the list, though!
You get to pay for the bytes *and* have them throttled.
In which case they should opt-in. But paying for the bandwidth and not getting it is clearly not what I paid for.
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.
Incorrect.
You must also disable any HTTPS, and allow t-mobile to modify your content.
Who knows what else they are able to do with the content now that they can snoop on it and modify it.
Yeay!?
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.
This is incorrect.
They throttle any video site down, even if you're paying for the bandwidth unless you, the consumer, opt out of bing-on completely, which requires jumping through hoops.
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.
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.
Not to mention that it is basically impossible to deploy any new feature or new protocol over port 80 (i.e. unencrypted) thanks to the 'help' of these proxies.
This is why you'll see that HTTP2 is deployed basically only over encrypted :443.
Amusingly, because of the 'helpful' proxies, HTTPS can be faster than HTTP. With the advent of QUIC (i.e. HTTP2 plus improvements), HTTP will almost always be slower unless the carrier is doing something (intentionally?) to screw things up.
Dude, the code is open. Then a spec is written, potentially with modifications, if it proves useful.
You *don't* have to use it.
RFCs no longer mean request-for-comments, at least in the IETF context.
Having seen the result of design-by-committee (i.e. design by politics instead of designing to fit a functional need), I can say that it doesn't work.
The outcome is almost always better when the protocol has actually been implemented, the kinks worked out, and then you ask others to use it. ...You know, useful is a necessary component of reusable...
But, if you're interested in FUD and a lack of progress instead of something which actually works, by all means do design-by-committee and get nearly useless protocols that implementers ignore.
There were 2 of these 10Kw units required to cruise at 75Mph, so the efficiency, assuming 35% thermal efficiency, is 22mpg.
Given that they're small and easy to maintain, perhaps that doesn't matter if they're only backups, or if this is just a first-iteration technology that may get substantially better.
The big concern imho, is vibration. Unlike a crankshaft-based engine/motor, there is no physical coupling of the pistons if you deploy two of these in a horizontal configuration (as TFA suggests would counter vibration).
The lack of coupling means that the pistons are not mechanically synchronized, which means they don't create forces which act against each other.
I'd have to imagine that one could approximate the physical coupling by varying the timing and mixture, but.. I have no idea how actually effective that'd be.
Anyway.. vibration. Big deal.
.. and how efficient is at as compared to a turbine?
Price controls don't do anything to increase the amount of available housing. It just means that people cannot find housing at all, and that the buildings aren't updated.
Eliminating Prop 13, and making the market more liquid and reasonable would help a bit..
A couple decades back the impact of Prop 13 wasn't yet horribly visible.
Worse, thanks to Prop 13, corporations pay far far less, and thus are less likely to give up property for sale.
No, they are NOT investors.
If they were investors,they'd be in trouble with the FTC, which hasn't yet setup regulations allowing such.
People who use Kickstarter are pre-purchasing whatever it is they're being sold. That can act as income for a company, and thus a funding source, but that does not make people who purchase things via Kickstarter investors.
One of these days, we will be able to invest in this manner, but not yet.
Kickstarter doesn't do investing. It is a pre-purchase...
I challenge you to find the word "invest" in the below (hint, it isn't there, nor is it *anywhere* on the Kickstarter page)
From Kickstarter:
Pledge $35 or more
22997 backers
You will receive a digital version of the movie within a few days of the movie’s theatrical debut, plus the T-shirt, plus the pdf of the shooting script. Naturally, you will also receive regular updates and behind-the-scenes scoop throughout the fundraising and movie making process. Available to US, Canada, Australia/New Zealand, Mexico, Brazil, and Select EU countries (Now including Norway and Switzerland! See Project Description for full list)