Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compression efficiency with shared dictionaries in Chrome

developer.chrome.com

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Compression efficiency with shared dictionaries in Chrome

#31

Post by twotwotwo »

frankjr wrote: post #24
saagarjha wrote: post #17

Even putting aside CORS because I don’t even want to think about how this plays well with requests to another (tracking?) domain, this still doesn’t seem worth it. The explicit use case seems to be that it basically tells the server when you last visited the site based on which dictionary you have and then it gives you the moral equivalent of a delta update. Except, most browsers are working hard to expire data of th…

> Dictionary entries (or at least the metadata) should be cleared any time cookies are cleared. So it seems it should not get you anything you cannot already do with cookies. https://github.com/WICG/compression-dictionary-transport/blo...

It's interesting this is mentioned specifically about the metadata used by this feature: fingerprinting using this feature has similarities with other cache fingerprinting (wrote a sibling comment about that).

It's not actively bad to have defense-in-depth measures at the level of the dictionary feature. But if your implementation of dictionaries using your browser's existing cache policies is a privacy problem, I'd consider changing the cache, not just the shared-dictionary implementation.

Re: Compression efficiency with shared dictionaries in Chrome

#32

Post by jsnell »

cuckatoo wrote: post #27

What stands out to me is that this creates another 'key' that the browser sends on every request which can be fingerprinted or tracked by the server. I do not want my browser sending anything that looks like it could be used to uniquely identify me. Ever. I want every request my browser makes to look like any other request made by another user's browser. I understand that this is what Google doesn't want but why can'…

The obvious answer is that they are not lying.

You're making three assertions, none backed by any evidence. That this is a tracking vector, that it's primarily intended to be a tracking vector, and that they're lying about their motivations.

But your reasoning fails already at the first step, since you just assumed malice rather than do any research. This is not a useful tracking vector. The storage is partitioned by the top window, and it is cleared when cookies are cleared. It's also not really a new tracking vector, it's pretty much the same as ETags.

Re: Compression efficiency with shared dictionaries in Chrome

#33

Post by adgjlsfhk1 »

kevingadd wrote: post #29
skybrian wrote: post #26

I wonder if this would be a good alternative to minimizing JavaScript and having separate sourcemaps?

JS minification will probably never die, because it makes parsing meaningfully faster.

the fact that the default on the web is to ship something that needs a parser is very silly.

Re: Compression efficiency with shared dictionaries in Chrome

#34

Post by kevingadd »

adgjlsfhk1 wrote: post #33
kevingadd wrote: post #29

Earlier quoted context omitted.

JS minification will probably never die, because it makes parsing meaningfully faster.

the fact that the default on the web is to ship something that needs a parser is very silly.

Depending on how you look at it, Java, .NET and WebAssembly all need parsers too, they just happen to be parsing a binary format instead of text.

Re: Compression efficiency with shared dictionaries in Chrome

#35

Post by sethev »

TacticalCoder wrote: post #7

> Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: The savings are nice in the best case (like in TFA: switching from version 1.3.4 to 1.3.6 of a lib or whatever) but that Base64 encoded hash is not compressible and so this line basically adds 60+ bytes to the request. Kinda ouch for when it's going to be a miss?

If 60 bytes per request is a material overhead, then your workload is unlikely to benefit from general purpose compression of any kind.

Re: Compression efficiency with shared dictionaries in Chrome

#36

Post by pornel »

sethev wrote: post #35
TacticalCoder wrote: post #7

> Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: The savings are nice in the best case (like in TFA: switching from version 1.3.4 to 1.3.6 of a lib or whatever) but that Base64 encoded hash is not compressible and so this line basically adds 60+ bytes to the request. Kinda ouch for when it's going to be a miss?

If 60 bytes per request is a material overhead, then your workload is unlikely to benefit from general purpose compression of any kind.

Upload is usually slower, more latency sensitive, and suffers from tcp cold start. Pages also make lots of small requests, so header overhead can add up. HTTP/2 added header compression for these reasons.

Re: Compression efficiency with shared dictionaries in Chrome

#37

Post by lozenge »

TacticalCoder wrote: post #7

> Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=: The savings are nice in the best case (like in TFA: switching from version 1.3.4 to 1.3.6 of a lib or whatever) but that Base64 encoded hash is not compressible and so this line basically adds 60+ bytes to the request. Kinda ouch for when it's going to be a miss?

It might be compressible. HTTP/3 includes compression of request headers. Base64 doesn't use the top two bits in a byte so it's compressible.

Re: Compression efficiency with shared dictionaries in Chrome

#38

Post by cuckatoo »

jsnell wrote: post #32
cuckatoo wrote: post #27

What stands out to me is that this creates another 'key' that the browser sends on every request which can be fingerprinted or tracked by the server. I do not want my browser sending anything that looks like it could be used to uniquely identify me. Ever. I want every request my browser makes to look like any other request made by another user's browser. I understand that this is what Google doesn't want but why can'…

The obvious answer is that they are not lying. You're making three assertions, none backed by any evidence. That this is a tracking vector, that it's primarily intended to be a tracking vector, and that they're lying about their motivations. But your reasoning fails already at the first step, since you just assumed malice rather than do any research. This is not a useful tracking vector. The storage is partitioned by…

[flagged]

Re: Compression efficiency with shared dictionaries in Chrome

#39

Post by madeofpalk »

skybrian wrote: post #26

I wonder if this would be a good alternative to minimizing JavaScript and having separate sourcemaps?

Not really.

Compressing JavaScript already gives you tonnes of benefits, but syntax-aware compression (modify js) gives you more.

Besides, this is a form of more efficient caching on that it only benefits subsequent visits.

Re: Compression efficiency with shared dictionaries in Chrome

#40

Post by [deleted] »

cuckatoo wrote: post #27

What stands out to me is that this creates another 'key' that the browser sends on every request which can be fingerprinted or tracked by the server. I do not want my browser sending anything that looks like it could be used to uniquely identify me. Ever. I want every request my browser makes to look like any other request made by another user's browser. I understand that this is what Google doesn't want but why can'…

[deleted]
Post reply on HN