Agreed, but I don't think that has to do with either it's "vanillaness" or the 6 month release schedule. Fedora does a lot of compatibility work behind the scenes that distros not backed by a large company more than likely couldn't afford.
But QUIC doesn’t use 443/TCP; it uses 443/UDP. So it’s unsurprising that middleboxes that care about 443/TCP would ignore it. That doesn’t support your claim that “non-TLS 1.2 traffic to 443 is OK.”
The point I was trying to make, probably badly, was that there was no need to make TLS 1.3 pretend to be TLS 1.2 going to TCP/443. They could have picked some new port, called it TLS 2.0 (which is what it actually is), and run with that. If QUIC can pick its own port and, by the looks of it, not run into massive problems, there's no reason why TLS 2.0 can't do so too.
Throughout history, the hedonic treadmill has always triumphed. Competition and envy conjure their own objects.
Even if you want to allege that the proverbial pie will become infinitely large, any one person’s slice is finite. However big my neighbor’s slice might be, I can strive to make mine even bigger.
However, I understood GP's mention of "embarrassment" to speak more to their own feelings of responsibility. Which would be more or less decoupled from the pressure that a particular client exerts.
In a nutshell, the useful fiction of computer-as-Von-Neumann-meaning doesn’t adequately reflect the reality of modern hardware. Not only does the CPU itself not fit that model (with things like speculative execution, sophisticated power and load management…), but the system as a whole is increasingly an amalgamation of different processors and address spaces.
> That exfiltration is one-time and it's quite hard to recover from.
Not quite true with Signal's double ratchet though, right? Because keys are routinely getting rolled, you have to continuously exfiltrate the new keys.
No I said signing keys. If you're doing MITM all the time because there's no alternative path to route ciphertexts, you get to generate all those double-ratchet keys. And then you have a separate ratchet for the other peer in the opposite direction.
Last time I checked, by default, WhatsApp features no fingerprint change warnings by default, so users will not even notice if you MITM them. The attack I described is for situations where the two users would enable non-blocking key change warnings and try to compare the fingerprints.
Not saying this attack happens by any means. Just that this is theoretically possible, and leaves the smallest trail. Which is why it helps that you can verify on Signal it's not exfiltrating your identity keys.
Ah right, I didn't think about just outright MitMing from the get-go. If WhatsApp doesn't show the user anything about fingerprints, then yeah, that's a real hole.
Yeah, that has societal cost too, to be sure. Which implies prima facie that such infra (roadways, high-frequency train lines) should be minimized. Since the throughout of mass transit is so much higher (iow, the societal cost per-user), mass transit is a better way to minimize those costs than cars.
I think you’re misattrubuting causation here. There are numerous factors that distinguish those two places. Chiefly, they are among the densest places in the world.
Generally speaking, cars are at odds with such extreme density, simply due to geometry (i.e. how much space driving requires); it’s super easy to saturate driving supply in such places.
Think of mass transit and driving as being in an equilibrium with each other. Depending on where the bottleneck is in driving supply, shifting driving demand to transit demand (via improved transit infrastructure) should most often improve driving.
Extreme density like the places you mentioned is challenging just because space is at such an extreme premium. I would argue (and I’m not alone here) that it’s especially challenging because driving is consistently underpriced; the fair value of driving there is likely far higher than the cost that drivers pay. In such circumstances, oversubscribed car infrastructure is the natural outcome.
PowerShell’s syntax Is just fine. Very few special characters, minimal escaping, easy to read. If you understand PowerShell semantics, the syntax comes quite naturally.
reply