6,254 karma · joined June 8, 2012
[ my public key: https://keybase.io/gsnedders; my proof: https://keybase.io/gsnedders/sigs/mzGxtKUO-Q2yYme3MggWJzaLZS6USlZuc8xRrS7iQi4 ]
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.
> illegal values, or values with illegal parts, are treated as if the declaration weren't there at all
So a conforming implementation would ignore that max-width property declaration, not raise an error.
And those earlier versions of ePub which defined a required subset of given CSS standards? The forwards-compatible parsing rules were part of their subset.
PDF is not somehow immune to this either — a non-conforming implementation could similarly break what are meant to be forward-compatible extension points by raising an error on an unknown stream or object instead of (as required by the standard) ignoring it.
And I know a lot of that lies on the vendors, but it does feel unfortunate (from a standardisation/conformance/certification point of view) that Windows requiring it doesn’t make it easy to boot other OSes!
I’m unaware of this ever being the case in the UK — the lack of closed shop units means that even when collective agreements cover promotion they cannot meaningfully set this based on dues paid, both because they don’t necessarily know how long each employee has been a member of the union, and regardless that would be illegal discrimination based on union membership vs not.
In the common case for private-sector white-collar collective agreements in the UK, promotion is mostly just required to be transparent, rather than setting out procedural rules for promotion.
Your focus on union dues also makes me suspect you’re commenting from the US, expecting a union environment much more like the US — and US unions are outliers in many ways.
Per https://iwgb.org.uk/en/join/game-worker/ union dues max out at £35/month for those earning £80k and more — this is vastly less than unions require as dues in the US, and that almost certainly reduces the impact that union dues have, even beyond the illegality of closed shop units.
And Dave Winer was strongly against ever clarifying the spec, and that’s part of what led to Atom.