In any case, the fact you need access to an existing hash to not select something stupid like DES is all due to crypt(3) being a wacky API and while callers could work around it by selecting more reasonable defaults it's a pretty big foot gun.

Though I am surprised that all of the code examples do not use constant-time strcmp(). Actually, I wonder if even constant-time strncmp() would still leak information about whether the account is disabled because in that case both arguments are much shorter? Food for thought.

But yeah, the crypt(3) API is very 80s C, the man page even features a lengthy description of a long-deprecated and utterly broken hashing algorithm using DES that is even implied to be broken in the text itself (and the warning message is so old it refers to "parallel computers" as though they were a new concept). Given that the default mode is to use a broken hashing algorithm, I'm shocked anyone actually uses the libc crypt(3) -- surely it's trivial to just write your own that isn't awful...?

No, because good understanding of design comes from programming experience. Atrophied skills mean you lose touch with the actual nuts and bolts of what you are building.

This is also the worst kind of lock-in you can imagine, by outsourcing all of your understanding of a codebase and your skills you are now completely at the mercy of LLM providers. Even if you switch to open weight models you're at the mercy of graphics cards producers and scalpers.

> Sure, if LLMs are producing shit code you need to have an understanding of what it should do instead. But I think that day is already gone.

Maybe your standards are too low. By my standard, they still produce shit code and require lots of iterations to get reasonable designs (I often end up just rewriting the bits that are obviously wrong rather than trying to figure out how to "prompt engineer" the right output).

They do often produce passable code but my experience is the longer you spend reading the code the more things you find wrong with it, almost like an uncanny valley.

At least that's my experience with Opus and Fable. Maybe it's too old-fashioned at this point to complain about code quality, but I find it very strange how many people have started proclaiming that their code quality is good.

I still think the original point I was replying to ("don't stand out") doesn't apply to systems with "soft" anonymity like Signal. Even more importantly, arguing that specific features like custom servers or non-Firebase notifications are problematic because they "stand out" is particularly silly -- those features are the exact kind that are already fingerprintable by virtue of Signal's inbox design. Even if the social graph is somewhat anonymised, Signal does not attempt to hide that you are using Signal. (You could argue custom servers leak some data about your social graph but I'm not sure it is much worse than the theoretical leaks we spoke about earlier. And it's kinda notable that when Moxie argued against federated servers as a concept, that wasn't among the arguments he made.)

My point is that by construction they are not an anonymity tool, no centralised server can be. They can add features to make it less easy to track users but that's not the same as providing anonymity, and it's important to not confuse the two.

To give an example: my email provider has a feature to auto-encrypt all inbound emails to a PGP public key. Is this a nice feature to make it harder for someone to read my past emails if someone gets access to their infrastructure? Sure. Does this make my emails end-to-end encrypted? Absolutely not. In a similar vein, Signal making social graph correlation harder is a welcome feature but is not the same as making it anonymous.

They intentionally store very little data about their users but their "mailbox" model explicitly means that the server (or an attacker) can figure out who is talking to whom. And that's fine! Signal isn't trying to be an anonymity network, so while stuff like sealed sender are nice features it's important to remember that anonymity breaks are explicitly not part of the Signal threat model.

"Don't stand out" only makes sense as advice for anonymity tools to avoid bifurcating the anonymity set -- it doesn't make much sense when you're taking about a service which links your account to your phone number and thus every server request is explicitly identifying you.

> The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

I would've thought the implication was kind of obvious? And I'm not sure why you mention Dodd-Frank -- there were many bailouts throughout 2007-2010 and the point of Dodd-Frank was to put an end to that scheme.

It's also not at all a given that website owners would prefer the national CAs -- as an obvious example, most Rust projects (foo.rs) would probably not trust the Serbian CAs as much as they would LetsEncrypt. Even for website owners that live in the country, it seems possible that Chinese website owners might prefer to use non-Chinese CAs. And again, if the solution is to just special-case one American legal entity then we have just moved back to the original VeriSign-signs-everything model.

The real issue is that the CA model has been obviously broken since at least the days of the Comodo hack -- the trust decision for who can certify the website identity is made by the website owner but really clients are the ones that actually care (it's their data at the end of the day) and they have no input. Moxie had a proposal in 2011 to fix this by letting clients decide the policies for how a certificate should be trusted[1] and I think it is a far more workable solution than the alternatives. If one of the LetsEncrypt intermediates was compromised none of the alternative proposals would have any real hope of providing a workable mitigation.

[1]: https://en.wikipedia.org/wiki/Convergence_%28SSL%29

This incident was obviously comically bad but the Comodo hack had a more painful impact on the mitigation that should give everyone pause -- their CA had signed a quarter of the internet's certificates so the trust couldn't just be revoked. Imagine one of the LetsEncrypt intermediates got compromised -- our mitigation strategies really cannot cope with that kind of disaster scenario. Browsers would be in the unenviable position where they'd be forced to make huge portions of the internet go dark for potentially months.

[1]: https://en.wikipedia.org/wiki/Convergence_(SSL)

This push for centralisation without the infrastructure to back it up has always been the most frustrating aspect of Docker Inc over the past >10 years I've worked on container runtimes.

> Shigeru Miyamoto: For every Zelda game we tell a new story, but we actually have an enormous document that explains how the game relates to the others, and bind them together. But to be honest, they are not that important to us. We care more about developing the game system… give the player new challenges for every chapter that is born.

So I don't think this is as clear cut as "a different group of people decades later make a timeline". The least charitable view might be that they never intended the unified timeline thing to became public and didn't consider it "lore", but I'm not sure I buy that either (since they talked about some details in other interviews, including the Victorious/Fallen Hero split most people object to).

[1]: https://www.nintendoforums.com/articles/40/super-play-magazi...

Maybe they did release the timeline because of fan pressure but some sort of timeline did exist for at least a decade before they released it which doesn't fit your theory they just came up with something and released it in secondary media because of fan pressure.

[1]: https://www.nintendoforums.com/articles/40/super-play-magazi...

I would be surprised if it did not have some impact on the writing of the games, though of course there is (as of yet) no explicit reference to the timeline in the games.

[1]: https://zelda.fandom.com/wiki/The_Legend_of_Zelda_timeline [2]: https://zelda.nintendo.com/about/

The irony. Perhaps the Bene Gesserit were just trying to "pace the frontier" of the eugenics market? Who can say?

If you know someone with N logins has N passwords it's a decent indication they use a password manager and so passwords are unlikely to be weak, if they have 1 password it's probably shared elsewhere and weak.

I also wasn't responding to a question asking about practical exploits, I was responding to a question that claimed the k-anonymity model is "provably anonymous" and "harmless". Since it clearly leaks some information it's definitely not the former and one could argue it's not the later though the "harm" is minimal.

> My browser fingerprint leaks, what, thousands of times more information than that - surely fixing applications like Chrome ...

I fail to see how the privacy nightmare of modern browsers is relevant to a discussion on whether opt-out signalling to third-party services is a reasonable stance for an open source project? By that metric no privacy bug is worth reporting because Chrome continues to exist. If only there was a term for this kind of non-sequitur...

I don't think these are /critical/ issues and the latter is basically just an argument against the HIBP service, but the point is that a user should opt-in to sharing their data in cases like this so they have a chance to make an informed decision. The k-anonymity design of the HIBP service has a degree of anonymity, it's not "provably anonymous" like homomorphic encryption or similar schemes would be.

1. Only a very small number of valid seeds were discarded when compared to the number of n values. It seems we don't yet know why about half of the valid seeds were discarded but the explanation of a buggy curve validity checker doesn't seem implausible to me.

2. Directly to your point, most of the prime192 and prime239 curves required larger n values to find a valid seed and they are both smaller and used an earlier timestamp.

[1]: https://words.filippo.io/seeds-solved/