News for hackers. Stuff that matters.
Re:Type-safe, K-sortable, globally unique identifier inspire... by dloreto on Wednesday June 28, 2023 @05:52PM (#36513149)
The checksum idea is interesting. I'm considering whether it makes sense to add it as part of the TypeID spec.
Re:Type-safe, K-sortable, globally unique identifier inspire... by veec_cas_tant on Wednesday June 28, 2023 @08:38PM (#36514813)
What value does the checksum provide? I think I'm missing something because I really don't see a benefit.
Re:Type-safe, K-sortable, globally unique identifier inspire... by bumbledraven on Wednesday June 28, 2023 @11:13PM (#36515895)
Checksums facilitate error detection. For typed UUIDs, checksums help detect errors introduced by changing the prefix/type or changing a “digit”.
Re:Type-safe, K-sortable, globally unique identifier inspire... by diroussel on Sunday July 02, 2023 @04:13PM (#36565196)
The benefit is that you can reject bad requests to an API more easily.

For one application I used a base 58 encoded value. Part of it was a truncated hmac, which I used like check digits. This meant I could validate IDs before hitting the DB. As an attacker or script kiddie could otherwise try a resource exhaustion attack.

So in the age of public internet faceing APIs and app urls, I think built in optional check digit support is a good idea.

Re:Type-safe, K-sortable, globally unique identifier inspire... by veec_cas_tant on Monday July 03, 2023 @04:32AM (#36570303)
I struggle to see how 10 bits of check data will help much. I guess if the extra bits aren’t persisted to storage it doesn’t hurt so why not?
Re:Type-safe, K-sortable, globally unique identifier inspire... by diroussel on Monday July 03, 2023 @05:07PM (#36578843)
Storage can get corrupted, columns can be truncated. For the applications I tend to touch correctness and the ability to detect errors and tamper are more important that a couple of bytes per row. But every application and domain is different.