At least we know KilledByGoogle will never be starved for content.

What is Google's CC supposed to even stand for?

Carbon Copy? As in, a rip-off?

Whatever hellhole committee named this did a poor job.

According to other comments on this thread:

Yes! That's it exactly! Carbon Copy!

Except from email, not rip-offs :)

/s

(And: agreed on this being a terrible name!)

Are they trying to kill look-ups for CC meaning “creative commons”?

I mean this with absolutely no shade but: That was objectively good advice.

(Not to detract from anyone's cleverness or hard work.)

Definitely. I wasn't aware about constant time constraints at the time.

You can write algorithms that leak every bit of your secrets, trivially. The npm "elliptic" package does this. Daniel Bleichenbacher has tested several packages' timing leakage in Rooterberg that are easily exploited: https://github.com/bleichenbacher-daniel/Rooterberg/blob/mai...

You can use algorithm implementations that do not have secret-dependent timing differences in any language, as long as you are clear that your guarantees do not extend to the underlying runtime or to compiler optimizations. This isn't perfect, but it's better.

You can go further Rust-to-WASM and use tools like https://github.com/trailofbits/skills/tree/main/plugins/cons... to check the assembly and the runtime that the assembly runs in. (Most of the linked Claude skill is a Python program. It just relies on AI to eliminate false positives.)

The real question is: What's your threat model?

> Nobody was evil you just tried to rely on a property that V8 never promised.

Tell me you didn't read past the headline without telling me you didn't read past the headline.

Read the whole thing, but OK you didn't accuse anyone of being evil yet. But let me clarify that even if a later optimization breaks your constant time property that still wouldn't be evil.

You walked back putting an accusation of evil in my mouth while following up with warning me not to make an accusation I would not make to begin with. Incredible.

I don't know if you are the author but he wrote:

The only things that can easily go wrong now are:

The compiler turns out to be evil and introduces an “optimization” that I don’t anticipate

The V8 developers turn out to be evil and modify how this logic works and break my assumptions in a future release

Ah, right. That was clearly tongue-in-cheek and easily forgettable, not an actual accusation on either party.

I've added an important clarification in case anyone else missed the rest of the prose that discussed how this was entirely my own fault to zero in on a sarcastic turn of phrase: https://soatok.blog/2026/09/12/the-v8-javascript-runtime-und...

Requiring manual key verification is a bad design that doesn't scale or benefit most people.

People seem to get on with Discord invite links just fine. You don't have to do the "confirm that all these emoji are the same on both your devices" dance to stop spam.

> People seem to get on with Discord invite links just fine.

Discord is used by a narrow group of technically literate people. Signal is for everyone. Your grandparents probably don't use Discord, but if they can text then they can use Signal.

If your concern is "muh phone number", then you can pay and not have to give the phone number to sign up.

It's already the case today (and has been for years) that you don't need to give strangers your phone number to chat on Signal. My username is soatok.45; try to get my phone number if you can.

If you want absolutely no info to be collected, ever, and there to be zero cost on the end user too, be prepared to welcome your new spam overlords. Because the people who will benefit the most from a zero cost signup that only requires a username are spammers.

I'm a bit surprised by this dismissal. Of course some info must be collected, or there must be some cost to enter (probably both I mean phone number is also a cost, but one most people already sunk). But we can still debate the best way, right?

For example:

* Are you absolutely positive signal will never have a bug that let attackers reveal contact phone numbers? I really trust in their secure coding skills, but this class of vulnerabilities (like 2fa leaj) happened to even the biggest players.

* One of the reasons signal collects phone numbers (and asks for a contacts permission) is to check which contracts are already on signal. For some people or in some governments even having a signal account is an opsec problem (to be fair, they have a secure privacy-preserving protocol for this - as you know - and it's possible to avoid this footgun if necessary)

> Together with how low a profile they keep, I'm not convinced they aren't a honeypot.

You don't need to be convinced of such things. In fact, it's better if technical people remain skeptical and check.

I did in 2025. https://soatok.blog/2025/02/18/reviewing-the-cryptography-us...

This helps put my mind at ease, thanks.

Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.