gsnedders
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).
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.
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.
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.)
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.
Even beyond Python, most gradual type systems are unsound by design.
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.
> 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.
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).
(.heif is sometimes used as a file extension generically, but HEIF is itself a container that can support various payloads.)
Note that Han Unification has a history predating Unicode, and the Unicode work very much followed on from that.
The most notable is CCCII, developed in Taiwan in the early 80s, and then standardised in various places.
That's not to say that it hasn't been controversial (it has!), nor to say that it hasn't caused problems (it has!), but it's also unfair to say that it's just Unicode doing its own special thing.
In the US case specifically, I always wonder how much of the benefit is just “here’s a free appointment with a doctor once a year”.
It’s maybe got slightly more extreme recently, with an even larger percentage of them being inscrutable to me as someone who both works in tech and has a decent grasp of current industry trends.
I’ve never really got it — if even I don’t know what you’re advertising (or often, who is advertising!), how does this help your sales?
The most obvious case is something like adding a Reviewed-By/Signed-off-by trailer based on reviewers, but there’s also a decent number of big projects that want more semantically meaningful commit identifiers (think more revision, in a numeric sense).
It seems like making merges async should make it a lot more possible to implement that!
There’s enough ways you can match up commits, with plenty of prior art in this space.
An obvious example is web browsers, where a vulnerability can easily be uninteresting because it lives in a sandboxed process… until you find a sandbox escape, then it is critical.
As long as you suspect there may be other vulnerabilities in the other layers, it is worthwhile investigating and fixing them, because defence in depth only works until someone manages to put together a full chain.
Personally, I find it somewhat less effective on larger screens, simply because my eyes are more likely to be further from the dots.