gsnedders

Header parsing, sure. But message framing bugs are much more likely with HTTP/1.1.

There’s both request compression (no negotiation) and response compression (negotiated).

I’ll point out that Servo was always a research project — any thought of it replacing Gecko was an incredibly long-term stretch goal. It was _a lot_ more interested in “can we write a high-performance browser engine in Rust” (there’s a reason why it significantly predates Rust 1.0 — they were very much developed together!) and “can we implement parallelism in places where browsers historically have not” (because you have more guarantees of safety).

Chromium _has_ been replacing certain components with ones in safe languages, and it seems like that will continue slowly (with integrating them into the existing codebase, with web compatibility risk of any changes in behaviour, with the risk of performance and power regressions).

A cooldown is a coarse way to deal with “supply chain security” — and that’s mostly a question of how much you trust your dependencies.

You may well (and probably should) trust the maintainers and release process of Brotli, Node.js, PHP, etc. security releases more than you trust some-random-JS package deep in your front end dependency graph.

You want to reduce the risk of introducing a compromised dependency into your product, and that’s largely a question of how much you trust upstream.

From a browser point-of-view, the real questions are about data size (if you can get the wireless interface back to a low power state, you’re winning on power benchmarks), about decompression cost (again, power benchmarks), and decompression time (for performance benchmarks and user-perceived performance).

Storage and compression compute costs aren’t really relevant — only insofar as if there’s very little adoption, the security risk of exposing the code is there but isn’t providing user benefit.

Things like Rust in Chromium weren’t even being talked about back when Brotli was introduced to Chromium.

I think Chromium as a project would be happier if they had less unsafe code in general, and holding new dependencies (especially those like media formats, which have a long history of security issues) to that standard doesn’t seem particularly surprising.

There’s always going to be trade-offs: how much benefit does this provide (users, developers) compared with how much risk does it incur (safe/unsafe code, quantity of code you’re now on the line for the security of).

(And that’s taking that reason to not support JPEG XL at face value, ignoring any debate about it.)

It’s clear from anyone trying to adopt MTE on ARM that there are just _a lot_ of memory-related bugs all over the place.

There’s plenty of things you can very deterministically verify — if the LLM writes a test case which causes an ASan violation, you probably have a bug; if the LLM writes a test case which run the various corruption checking tools and they find corruption then you either have corruption or you have a bug in the corruption checking tool; etc.

There’s plenty of ways in which you can guide LLMs, and sandbox them, to get a much higher hit rate.

And that’s before the increase of validity of bugs compared with a year ago — we’re past the peak of slopageddon, and maybe even at a point where a higher percentage of security bugs reported are valid than was the case pre-LLMs.

> The unfortunate fact is that a fully sound Python type system would be a pain to use.

Even beyond Python, most gradual type systems are unsound by design.

What I don’t get from this article is why strands-decider-2b v10 and strands-decider-2b v11 are shown as “other systems”, and with v11 notably outperforming v19 — why are these other systems, and why is v11 not the path taken?

OHTTP is designed for a relatively narrow use case: stateless requests where you don't want the gateway to be able to correlate multiple requests from the same client (i.e., it's not just about hiding the IP address).

A clear example of when this might be a good idea is DNS-over-HTTPS — you don't want the resolver being able to correlate multiple requests from the same client.

You _can_ try and do this with SOCKS5, however you need to be very careful to avoid sharing any state:

* You must use a new TCP connection for each request, with a new TLS and HTTP connection atop.

* You must ensure you do not use TLS Session Resumption or 0-RTT data.

* You must, to the maximum extent possible, be very conservative with what you send in the TLS ClientHello to avoid exposing fingerprinting data.

SOCKS5 is also unencrypted, and the request contains the destination: the hostname if the proxy resolves it, or the IP if the client resolved it itself (and ECH doesn't help here, since it only protects the SNI inside the TLS handshake that follows). With OHTTP, that's all inside the TLS connection to the relay.

OHTTP doesn't have the client sending up-front metadata about all the different encryption methods it supports to the gateway (it relies on the gateway to tell it what it supports, and the client just picks one); the gateway doesn't get to see any of the TLS fingerprinting surface (because that is only visible to the relay).

OHTTP also doesn't require there to be multiple new TCP connections made for every request (whereas with SOCKS5 you're looking at a new TCP connection from the client to the proxy, and from the proxy to the server, per request) — you can have a long-lived connection to the relay, and the relay can have a long-lived connection to the gateway (shared by many clients). That's a big latency win for applications like DNS-over-HTTPS.

The risks of key disclosure also differ between the two — with OHTTP, disclosure of the gateway key essentially means the relay can decrypt recorded traffic that used that key (as there is no forward secrecy), whereas disclosure of the client <-> relay and relay <-> gateway keys matters a lot less (because there is forward secrecy); with SOCKS5, you have forward secrecy via the end-to-end TLS connection.

For the use-case of a general-use proxy, work such as MASQUE provides a multi-hop approach to limit exposure to any single party, and that does provide an end-to-end TLS connection — but you with that you're back to exposing all the fingerprinting associated with it, though for a general use proxy you may also be sending session-specific data (like auth tokens) that clearly tie requests together anyway.

From that meta article:

> For most people with ADHD, many genetic and environmental risk factors accumulate to cause the disorder.

i.e., for most people, there is no singular cause.

My reading of the docs is that when fetching/pushing from a SHA-256 repo, all objects are referred to (in the packfile fetched) by their SHA-256 names — then, when fetching, you locally compute the SHA-1 of each object for the translation table.

Presuming there’s some validation that SHA-1 names are unique, then that should be safe — the only way I can see one could do a pre-image attack is either fetching from a SHA-1 server (because then you don’t get the SHA-256 object name), which requires a second pre-image attack on SHA-1 (known to be feasible); or by having a second pre-image attack against both SHA-1 and SHA-256 simultaneously (and SHA-256 is still believed to be secure).

AVIF _is_ AV1 in the HEIF container.

(.heif is sometimes used as a file extension generically, but HEIF is itself a container that can support various payloads.)