And make sure to specify what exactly you mean by that. base64url-encoding is incompatible with base64+urlencoding in ~3% of cases, which is easily missed during development, but will surely happen in production.
Though that is quite a bit (~830 km / ~1250 km from the center of the square around 30S 87E) off to the (north)west of the most recent search proposal from mh370search.com:
Oh, indeed, that's quite surprising. A TLSv1.3 Client Hello always contains the supported_versions extension, which should allow wireshark to label it correctly, regardless of whether or not the handshake actually finishes. Though, tbf, it does say TLSv1 and not TLSv1.0. I wonder how it would look had TLSv1.3 been named TLSv2.0 after all...
Certainly weird that wireshark shows TLSv1 while curl shows TLSv1.3. That shouldn't happen unless something interfered with the Client Hello. (or the wireshark version is outdated)
That's why there's OCSP stapling and OCSP must staple. Ever seen an nginx server fail HTTPS connection exactly once after rotating the certificate? That's nginx lazily fetching the OCSP response from upstream for stapling purposes.
Besides all the points other people already made, the money saved by being able to switch to deploying the Starlink constellation via SuperHeavy/Starship (very likely to be cheaper in $ per satellite-to-orbit) instead of F9 earlier makes taking risks and iterating faster even more appealing.
You could try inputting your name as [Latin Small Letter E][Combining Acute Accent]:
e◌́
=>
é
Which should keep the `e` intact, while the combining acute accent (0xCC 0x81) may "only" get converted to a `Ì` which may be stripped. 0x81 is undefined in Windows-1252, so I have no idea what would happen to that, but probably be stripped as well, keeping just Leon.
If someone else is in the habit of randomly selecting text and they're using linux, they may want to disable at least `clipboard.autocopy` if they don't use it. No reason to simply tell websites every selection you do, IMHO.
As long as `chrome://global/content/config.xul` still exists, you can use it. I certainly do, since the new interface is horrible and Mozilla constantly dismisses the obvious usability issues.
`privacy.resistFingerprinting.letterboxing` is currently a separate setting since it's still rough around the edges. Not sure if it works on Release, I have it set on Nightly.
It seems Mozilla is in the process[0] of moving the signature scheme to COSE, which allows timestamping[1]. A code comment[2] says that the current package format doesn't allow it.
And make sure to specify what exactly you mean by that. base64url-encoding is incompatible with base64+urlencoding in ~3% of cases, which is easily missed during development, but will surely happen in production.