patrickmeenan

As far as I can tell, the messaging around Mythos is that it takes the expertise of the top security experts and top-level language, protocol and code experts and makes that available to anyone with access. The danger was in giving that access to the world before the defenders had access to that level of expertise.

Curl HAS had security, protocol and language experts poking at it for years because of how central it is to everything. That Mythos found anything is interesting but not a sign that it's been marketing hype and isn't dangerous.

You can bet that 99.99% of projects aren't nearly as secure as curl and it doesn't matter if they are open or closed source (LLM's will happily decompile closed-source projects and explore). Unless your project has been fuzzed and gone over with existing AI tooling and by experts, expect that it can already be hacked - even with the tooling that is out there now and that something like Mythos makes it accessible for an even wider population pool with less expertise to use.

There is some level of data exposure even if you can't tell which site, specifically, a user has visited. You can tell that "this user has been to at least one page that used X".

Depending on what the common resource is, most people wouldn't necessarily care but there may be some cases where they would.

If I can tell that you used facebook login at one point, even though it is used by a good chunk of the web, I could tailor a phish targeted at FB credentials for example.

Even a simple case of loading more than 2-3 pages from a given site over a few weeks could benefit from a dictionary for the HTML content (compressing out all of the common template code).

Just about any e-commerce site will involve a few pages to go through search, product pages and checkout.

Most news sites will likely see at least 2-3 pages loaded by a given user over the span of a few months. Heck, even this site could shave 20-50% for each of the pages a user visits by compressing out the common HTML: https://use-as-dictionary.com/generate/result.php?id=d639194...

Any place you'd justify building a SPA, by definition, could also be a multi-page app with dictionaries.

If you have a site that visitors always bounce immediately and only visit one page in their lifetime then it can't help, but those tend to be a lot less common.

It doesn't have to be a huge site to benefit, it just needs users that regularly visit to show large gains.

As CDNs implement support, the effort involved in supporting it will also drop, likely to the point where it can just be a checkbox to generate and use dictionary-based compression.

Sorry, I should provide more context. The language in the IETF draft is a bit generic because it is a HTTP spec intended to be used more broadly than just web content in browsers and each should evaluate the risks for their use case.

For browsers specifically, the fetch spec changes will be explicit about the cache clearing and partitioning (partitioned by both top-level document site and frame origin). You can see Chrome's implementation here: https://source.chromium.org/chromium/chromium/src/+/main:net...

The fetch spec changes are in progress (just documenting, the discussions have already happened). You can follow along here if you'd like: https://github.com/whatwg/fetch/issues/1739

SDCH was removed when SPECTRE became a thing (CRIME/BREACH) because it was open to side-channel attacks.

Yes, it had other problems, not the least of which was that it would block the processing of a response while a client fetched the dictionary, but the side-channel attacks were what killed it.

The compression dictionary transport work addresses all of the known issues that we had with SDCH and we're cautiously optimistic that this will be around for a long time.

Nope. The dictionaries are partitioned the same way as the caches and cookies (whichever is partitioned more aggressively for a given browser). Usually by site and frame so there are no cross-site vectors that it opens.

Which is why they are treated as if they are cookies and are cleared any time the cache or cookies are cleared so that they can not provide an additional tracking vector beyond what cookies can do (and when 3rd party cookies are partitioned by site/frame, they are also partitioned the same).

There are LOTS of privacy teams within the respective companies, W3C and IETF that have looked it over to make sure that it does not open any new abuse vectors. It's worth noting that Google, Mozilla and Apple are all supportive of the spec and have all been involved over the last year.

FWIW, this addresses the BREACH/CRIME issues that killed SDCH by only operating on CORS-readable content.

It also solves the problem that SDCH had where the dictionary would be forced on the response and the client would have to go fetch it if it didn't have it before it could process the response.

The tooling for generating dictionaries is also WAY better than it was back in the SDCH days (and they are a much cleaner format, being arbitrary byte strings that Brotli and ZStandard can back-reference).

Lots of people involved in working on it were also involved with SDCH and have been trying to find a workable solution since it had to be turned down.

If the proxy is correctly handling the Accept-Encoding (rewriting it with only encodings that it understands), it can either remove the `dcb` and `dcz` encodings or it can check if it knows the announced dictionary and only allow them through if it has the dictionary.

MITM devices that just inspect and fail on unknown content-encoding values will have a problem and will need to be updated (there is an enterprise policy to disable the feature in Chrome for that situation until the proxies can be updated).

Absolutely, for the use cases where it makes sense. There are some examples here: https://github.com/WICG/compression-dictionary-transport/blo...

In the web case, it mostly only makes sense if users are using a site for more than one page (or over a long time).

Some of the common places where it can have a huge impact:

- Delta-updating wasm or JS/CSS code between releases. Like the youtube player JavaScript or Adobe Web's WASM code. Instead of downloading the whole thing again, the version in the user's cache can be used as a "dictionary" and just the deltas for the update can be delivered. Typically this is 90-99% smaller than using Brotli with no dictionary.

- Lazy-loading a site-specific dictionary for the HTML content. Pages after the first one can use the dictionary and just load the page-specific content (compresses away the headers, template, common phrases, logos, inline svg's or data URI's, etc). This usually makes the HTML 60-90% smaller depending on how much unique content is in the HTML (there is a LOT of site boilerplate).

- JSON API's can load a dictionary that has the keys and common values and basically yield a binary format on the wire for JSON data, compressing out all of the verbosity.

I expect we're still just scratching the surface of how they will be used but the results are pretty stunning if you have a site with regular user engagement.

FWIW, they are not "pre-shared" so it doesn't help the first visit to a site. The can use existing requests for delta updates or the dictionaries can be loaded on demand but it is up to the site to load them (and create them).

It will probably fall over if it gets hit too hard, but there is some tooling here that can generate dictionaries for you (using the brotli dictionary generator) and let you test the effectiveness: https://use-as-dictionary.com/

Maybe eventually (as a different spec). We've talked about wanting to support it in the DecompressionStream API or something similar at some point.

If you need it to be able to do compression though then it might be a harder sell since the browser doesn't ship with the compression code for zstd or brotli and would have to justify adding it.

How so? SDCH had sidechannel issues which is part of why it was unshipped. I don't know that someone won't find a way to attack it but the CORS requirement already requires that the dictionary and compressed-resource be readable and the dictionary has to be same-origin as the resources that it compresses.

Combined they mitigate the known dictionary-specific attack vectors.

The brotli repo on github has a dictionary generator: https://github.com/google/brotli/blob/master/research/dictio...

I have a hosted version of it on https://use-as-dictionary.com/ to make it easier to experiment with.

For a delta update of one version of a resource to the next, the resource itself is the dictionary (i.e. JS file).

For stand-alone dictionaries, the brotli code on github has a dictionary_generator that you can use to generate a dictionary. You give it a dictionary size and a bunch of input files and it will generate one. I have a version of it hosted on https://use-as-dictionary.com/ that you can pass up to 100 URLs to and it will generate a dictionary for you (using the brotli tool).

You determine how far back you want to build deltas for. If you build deltas for the last 3 versions then you can send diffs for those users as well (as long as the dictionary hasn't expired). Or, you could just send the full response just like if dictionaries weren't supported.

Each site can decide what a "good" number of releases to build against based on typical release cycles and user visitation patterns.

Even in the "documents" case of the web there can be pretty significant savings if users tend to visit more than one page and they share some amount of structure.

On the first entry to the site you trigger the load of an external dictionary that contains the common parts of the HTML across the site and then future document loads can be delta-compressed against the dictionary, effectively delivering just the page-specific bits.

You need to amortize the cost of loading the dictionary across the other page loads but it's usually pretty compelling once users visit more than 2-3 pages.

The dictionaries are partitioned by document and origin so a "tracking" domain will only be able to correlate requests within a given document origin and not across sites.

They are also cleared any time cookies are cleared and don't outlive what you can do today with cookies or Etags (and are using the most restrictive partitioning for that reason).

It is more site-dependent than browser dependent but by default (unless the dev overrides) most browsers will leave the text blank for 3 seconds after the font is discovered before falling back. In most (all?) of the cases in the blog post, the actual font loading is within that 3-second window, the issue is that the layout-blocking content (preventing the browser from discovering the font) is what is slow.

Yep, hopefully a lot of the default improvements will make their way into all of the browsers. Until then, this also evens the field across all of the browsers but for me the really exciting part is exposing it to Workers so sites can customize the logic specific to their needs. Boosting the priority of hero images or async scripts that are important for the site but the browser's default logic has no way to know. Priority hints (also Chrome-only currently) will eventually bring that to browsers natively.

Full disclosure, I'm the article author and I also spent several years on the Chrome team working on the resource loading/scheduler so it's probably not too surprising that there are similarities.

Functioning HTTP/2 prioritization takes more than just a server that supports priorities. Here's a deep dive into why and how to make sure it's working for your site (and yes, it is broken more often than you might hope).

Completely ignoring TTFB would be a BAD idea. There is no single metric that conveys the user experience (or performance).

Certainly optimizing for 1ms because of the overhead for gzip compression isn't where you should be spending your time but I have dozens of cases in the WebPagetest forums where users have had 5+ second TTFB times and needed help figuring out what was going on. I have even seen cases where it was over 20 seconds (search for TTFB in the forums and you'll be shocked). It is usually a combination of shared hosting and excessive database queries by their CMS but it is common enough that completely ignoring it would be a very BAD idea.

Companies like Cloudflare can help the real TTFB (without cheating) by optimizing the conection between the end user and the origin site. Most CDN's call it DSA where they maintain a persistent connection back to the origin and eliminate some of the round trip times. Cloudflare's recently-launched Railgun feature should have a similar benefit.

It's actually a pretty well-known best-practice for web performance to "flush the document early" if you have any expensive back-end processing to do. This isn't cheating and involves sending as much of the HTML content as possible to give the browser a head-start downloading external resources (css, js, etc).

Doing it with just the HTTP headers in order to cheat the metric itself is not in anybody's interest.