My understanding is that it's likely somewhere around 7.5% for men and women. Including bisexual people brings it closer to 10%. That's based on self-reporting, I think. I'm not sure how significant that would be in Meta's world.
Among men this would only be 3 or 4%. Probably not that significant given how coarse the strategy itself is.
And no one can even give a concrete answer why root certificates need expiration dates. It's just because reasons.
IMO the whole PKI thing is a terrible idea to begin with. It would make much more sense to tie the trust in TLS to DNS somehow, since the certificates themselves depend on domains anyway. Then you would only have a single root of trust, and that would be your DNS provider (or the root servers). And nothing will expire ever again.
Root certificates need expiration dates for the same reason that LetsEncrypt certs need an expiration date: risk of cert compromise and forgery increases over time.
Over a long enough timeline, there will be vulns discovered in so much of the software that guards the CA certs in RAM
> risk of cert compromise and forgery increases over time.
And what if the certificate is compromised before it expires? Right, there's a revocation mechanism for that. So why expire them then if they can be revoked anyway IF they get compromised?
The reason why domain TLS certificates expire is that domains can change owners. It makes sense that it should not be possible for someone to buy a domain for one year, get a non-expiring TLS certificate issued for it, and then have the ability to MitM its traffic if it ever gets bought by someone else later.
Domain certificates are sent as part of the connection handshake, so them expiring is unnoticeable for the end users. However, root certificates rely on the OS getting updates forever, which is unsustainable. Some systems lack the ability to install user-provided root CAs altogether, and some (Android) do allow it but treat them as second-class.
Because the most dangerous secret is one that has been compromised and you don’t know it. This sets a time limit for their usefulness. Sometimes the stories about terrible default choices that are insecure sink in and architects choose a better path.
Also, details about the certs and the standards for them change over time. This makes it easier for the browser venders (via the CA forum) to force cert providers to update over time.
The instant we bound encrypted connections with identity we failed. And decades later we're still living with the mistake.
I'm completely serious when we need to abandon the ID verification part of certificates. That's an entirely separate problem from encryption protocol. An encryption protocol needs absolutely no expiration date, it's useful until it's broken, and no one can predict that. Identity should be verified in a separate path.
Do certificate revocation lists need to keep including certificates that have long since expired? I don't see why root certificates need to expire as long as the certificates signed by those roots all have reasonable expiration windows, unless someone is doing something strange about trusting formerly-valid certificates, or not checking root certificates against revocation lists.
Of course they do, they have to. But it's okay for things that are sent to you over the network to expire. It's not okay for things built into your potentially abandoned OS to expire.
Or maybe, you know, we should stop writing security-critical software in memory-unsafe languages. Mobile devices not treating their owner as an adversary would also be nice.
That's only part of it. That all security issues would be gone after writing code in a memory-safe language is a fairytale (though it does help a lot).
The other parts layered defense, reducing the number of privileged/non-sandboxed applications/processes, not shipping spyware/adware, etc.
Only Apple/GrapheneOS and to a slightly lesser extend Google Pixel are good at this. Many phone manufacturers still use the TrustZone TEE on the main CPU (rather than a separate security processor), isolated radios, hardware memory tagging, and dozens of other defense-in-depth features.
If you mean the software supply chain, minimize third-party dependencies and carefully review any updates. I mean read and understand code diffs before you bump versions.
If you mean the hardware supply chain, has that ever actually happened? I've only ever seen it mentioned as a theoretical possibility so far.
I worked at Russia's largest social media company as the founding Android developer. I quit as soon as I realized it was only going to get worse from now on after an acquisition and a very noticeable shift in user treatment. But that job was never about the money for me. The salary was just a nice yet optional bonus.
He encodes bits as signs of DCT coefficients. I do feel like this is not as optimal as it could be. A better approach IMO would be to just ignore the AC coefficients altogether and instead encode several bits per block into the DC. Not using the chrominance also feels like a waste.
This actually won't work against YouTube's compression. The DC coefficient is always quantized, rounded, scale, and any other things. That means that these bits are pretty much guaranteed to be destroyed immediately. If this is the case for every single block, then data is unrecoverable. Also, chrominance is not used on purpose, because chrominance is compressed much more aggressively compared to luminance.
I meant choosing multiple values, e.g. 4 to represent 2 bits. Say, 0.25, 0.5, 0.75, and 1. Then when decoding you would pick the closest valid value, so for example for 0.20 it would be 0.25. Not using AC coefficients would mean that theoretically you would get more bitrate for the DC ones.
I’ve been told this many times in the comments, but this again is not reliable. Simply put, compression doesn’t necessarily follow a pattern, so specifying “ranges” or rounding to a specific place will not work. Compression optimizes for the eye, and doesn’t do the same thing for every value. It will round some down, some other mores, others less. Giving a range is simply not enough.
The one related thing that has always driven me a bit crazy on iOS (which I hardly ever use, only for testing) compared to Android (which I've been using daily since 2011) is how touches register slightly higher than where you're physically tapping. This alone makes hitting small-ish targets, including keyboard keys, quite challenging and infuriating. This does seem intentional too, as it depends neither on the device model nor on the OS version, it's been like that for over a decade at this point.
reply