Re: [hybi] deflate-stream and masking

[David Endicott <[e-mail]>]

Unlurking to agree.

When it was optional it was avoidable and non-impairing.   It should not be
mandatory.

+6.02 x10^23 votes for removal from specification (which when deflated is
just +1, I believe)



On Wed, Jul 20, 2011 at 5:50 AM, Brian <[e-mail]> wrote:

> +500.  deflate-stream has always been utterly ridiculous in light of
> masking.  It really should get the axe, and with extreme prejudice.  Why is
> it still in the spec?  I don't recall anyone citing a reasonable reason for
> keeping it, but there have been many very good arguments against it.  It's
> not even very clearly specified in the document -- when I implemented it in
> my Flash client, I had to read the source code of Andy Green's
> implementation to figure out how it was supposed to work -- his
> implementation became my specification for the extension.
>
> Brian
>
>
> On Tue, Jul 19, 2011 at 7:34 PM, Greg Wilkins <[e-mail]> wrote:
>
>> I've just noticed that the w3c is currently intending to make support
>> for deflate-stream mandatory!
>>
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
>>
>> This moves this extension from being useless, but mostly harmless, to
>> being a major impost on servers and intermediaries.
>> If the browser make this mandatory, then servers will obviously have
>> to support it at a cost of extra CPU, extra buffers but for no
>> significant savings in bandwidth.
>> Intermediaries that wish to act on frame boundaries will also have to
>> implement it.
>>
>> This illustrate that having silly options always puts you at risk of
>> people taking you up on those options.
>>
>> This extension is demonstrably broken and needs to be either fixed or
>> removed.
>>
>> regards
>>
>>
>>
>> On 20 June 2011 16:33, Greg Wilkins <[e-mail]> wrote:
>> > As part of my continuing campaign against including deflate-stream in
>> > the specification as a standard extension, I did a quick test of how
>> > well it works when applied to masked frames.
>> >
>> > I took a days worth of traffic from an IRC channel and wrapped it up
>> > as JSON messages sent as websocket frames.
>> > There were 487 message that looked like:
>> >
>> >     {channel:"#webtide", username:"tbecker", text:"joakime: jenkins
>> > had issues pulling from github a couple of times  last week"}
>> >
>> > As an unmasked WS stream, it was 50675 bytes, and as a masked stream
>> > is was 52623 bytes.
>> > I then compressed both these streams with gzip and got 13306 bytes for
>> > unmasked and 51704 bytes for the masked!!!!
>> >
>> > So for this very typical example, masking was sufficiently random to
>> > completely negate the benefits of compression.
>> >
>> > So the deflate-stream "extension" is:
>> >
>> >  + next to useless for inbound traffic
>> >  + breaks all the rules of what an extension can do
>> >  + is potentially vulnerable to injection as attackers can send
>> > repeated patterns that may subvert masking
>> >  + can be replaced by the in-frame compression extension already
>> proposed.
>> >  + was inserted in the draft with little or no discussion and without
>> > clear consensus.
>> >
>> > Can I call for a straw poll of who wants to keep this extension in the
>> spec?
>> >
>> >
>> >
>> > regards
>> >
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>