zzq1015

From the Datatracker, I can see that it was called SEARCH until draft-2 (Nov 2021), and then changed to QUERY.

Also, the previous SEARCH method was proposed in Apr 2015 (!!), but nobody took it seriously, and it never gained traction back then. A lot of software was developed/updated during the last decade, and a lot of opportunities were missed. Even if the QUERY method is turned into a formal RFC right now, expect 10+ years for everyone to adopt it, without running into HTTP-405 or 501's.

PSA: When posting an RFC or (especially) an RFC-draft, please use the IETF Datatracker URL.

For example, this one is: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met...

The best way to view an RFC, IMHO, is to use the "htmlized" format: you can view and compare different versions, view errata for a formal RFC, and go back to Datatracker at any time.

Also, the Datatracker URL is version-insensitive, so unlike the pure HTML format, it will not be stuck on draft-14 forever.

I mean, when your business is big enough, you'll naturally start to hire more people. Small businesses don't require a large staff and typically don't generate a substantial amount of revenue. The size of a company (i.e., its revenue) generally needs to be in proportion to the number of staff it has, with some flexibility, but not too much.

What if we implement UBI in a way that:

1. Companies not participating in UBI: they have to hire people, even for nothing, but all the staff have to be paid.

2. The others: they are focused on making money without hiring people ("efficient money-making machines"), so they are forced to participate in UBI, and therefore distribute their wealth towards society.

So long with "efficient money-making machines".

It's a mess when you learn there are also 6in4, 6rd and teredo...

For Linux, there's a kernel setting for that.

Just run

  sysctl -w net.ipv6.bindv6only=1

so IPv6 will not include IPv4-mapped addresses.

https://www.kernel.org/doc/Documentation/networking/ip-sysct...

Yeah, despite what it says, I really think Google is gonna ditch 3DES across the board, starting from Gmail.

0.38% of what?

For sites like Google, it's still too large to ignore.

Also, a fun fact: Google still serves plain HTTP for really old clients, just in case the client barely supports HTTPS.

Oh, I meant on Gmail servers.

I always customize TLS versions and cipher suites because I don't trust the defaults.

AFAIK you can customize them on:

- Chrome & Firefox (can only enable/disable ciphers, no reordering, PQ ciphers supported since 2024)

- OpenSSL (by customizing openssl.cnf, PQ ciphers supported since 3.5)

- curl

- nginx/apache

- OpenSSH (I enabled PQ ciphers too)

- Multiple programming libraries

- and others...

Also, clients and servers don't "pick the strongest cipher that they both support". Servers select the cipher ultimately, and they can be misconfigured to pick, for example, 3DES over AES.

"The obvious way to avoid these attacks is to stop using legacy 64-bit block ciphers. Alternatively, the attack can be mitigated by rekeying the session frequently."

- https://sweet32.info/

Although I doubt the older clients even implement rekeying at all...

DES is weak because it only uses 56 bits, and you can brute force it. 3DES has 168 (56*3) bits with the security of 112 (56*2) bits.

I had no idea that you can filter/reject certain TLS versions/ciphers (on Gmail servers) before seeing this on the HN front page.

https://support.google.com/a/answer/9795993

Probably not just that. 3DES is the last cipher supported by "old" clients (I'm talking Windows XP). If you remove 3DES, the TLS connection will simply fail.

You can never imagine how many people are still using WinXP, or other forgotten legacy clients/servers that only support up to TLS 1.0 and RC4/DES/3DES without realizing it.