Does that comparison make sense? You're comparing investments into the national grid with energy prices set by international trade. Power is imported and exported all the time, and the lack of affordable fossil fuels abroad will put pressure on cheaper local prices.

I don't think going nuclear would've made a difference here. Someone is making a lot of money selling power locally for prices that only make sense in an international context. Whether that's done by wind farm operators or nuclear plants, the result will still be the same.

DNSSEC alone is obviously useless because any attacker interested in SNI hostnames can just as easily monitor DNS traffic.

However, DoH/DoT without record integrity is about as useful as self-signed HTTPS certificates. You need both for the system to work right in every case.

To quote the spec:

> Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but encrypted DNS transport is also a defense against DNS attacks by attackers on the local network, which is a common case where ClientHello and SNI encryption are desired. Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit.

Only if the attacker has a valid certificate for the domain to complete the handshake with.

Relying on HTTPS and SVCB records will probably allow a downgrade for some attackers, but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult.

DNSSEC can also protect against malicious SVCB/HTTPS records and the spec recommends DoT/DoH against local MitM attacks to prevent this.

> and couldn't upgrade because Apple didn't support my hardware anymore

I'd classify that as an Apple problem rather than a Homebrew problem. If Apple themselves cannot be arsed to support an OS version, why would a volunteer project take on such a challenge?

For every piece of software I've fetched using Homebrew, there's a "compile from source" option available on Github or some other source repo.

I disagree. Raw UDP is about as useful as raw TCP if your application matches the protocol's features and weaknesses. Plenty of protocols work by spamming packets around the network where it doesn't matter if half of them go missing or arrive out of order.

TCP is also barely enough to be a real "protocol". It does a bunch of useful stuff but in the end raw text is pretty useless as a protocol. That's why everything from IRC to HTTP has its own protocol on top.

SCTP is a bit of a weird outlier to be placed at the level of TCP and UDP, but there's no need to go all QUIC and reinvent TCP if you want to use UDP. DNS, NTP, and plenty of other protocols don't need to rebuild reliability and streams to be useful.

Matrix allows for unencrypted messages so it's inherently less encrypted than Signal. The federation capability also means messages leak metadata. Furthermore, encrypted messages also contain some metadata in the unencrypted envelope. Some protocol features (emoji reactions) also ended up outside of the encrypted envelope because of that. It's a risk with any protocol that has encryption bolted on and optional.

On the other hand, you can host your own Matrix server and still participate in the network, whereas Signal will have you convince your friends and family to install a custom Signal client if you want to run your own Signal server, for instance because you don't want to rely on Amazon's servers (Signal was down when Amazon went down this morning).

Signal sacrifices network openness for encryption capabilities.

There's also the MLS/MIMI side of things, but AFAIK that work hasn't been completed yet (MIMI isn't even a full RFC yet).

Element/Matrix, with some modifications, has been chosen as the messenger of choice by the French government (Tchap) as well as the German military (BwMessenger, BundesMessenger) and healthcare (TI-Messenger).