5 ms·

> Norwegian PNs have your birth date (in DDMMYY format) as the first six digits. Surely that doesn't change, right? Well, wrong, since although the date doesn't

by ralferoo 10mo ago

> Norwegian PNs have your birth date (in DDMMYY format) as the first six digits. Surely that doesn't change, right? Well, wrong, since although the date doesn't change, your knowledge of it might. Immigrants who didn't know their exact date of birth got assigned 1. Jan by default... And then people with actual birthdays on 1 Jan got told, "sorry, you can't have that as birth date, we've run out of numbers in that series!" To me, what your example really shows is the problem with incorrect default values, not a problem with encoding data into a key per se. If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear. But in case, the intention for encoding a timestamp into a UUID isn't for any implied meaning. It's both to guarantee uniqueness with a side effect that IDs are more or less monotonically increasing. Whether this is actually desirable depends on your application, but generally if the application is as a indexed key for insertion into a database, it's usually more useful for performance than a fully random ID as it avoids rewriting lots of leaf-nodes of B-trees. If you insert a load of these such keys, it forms a cluster on one side of the tree that can the rebalance with only the top levels needing to be rewritten.

tyre 10mo ago
And then have to enter/handle a non-date through all systems? How do you know if this non-dated person is over the age of minority? Eligible for a pension? Maybe the answer is to evenly spread the defaults over 365 days.
- ralferoo 10mo ago
  If you don't know their birthday, you can presumably never answer that question in any case. If you only know the birth year and keyed 99 as the month for unknown, then your algorithm would determine they were of a correct age on the start of the year after that was true, which I guess would be what you want for legal compliance. If you don't even know if the birth year is correct, then the correct process depends on policy. Maybe they choose any year, maybe they choose the oldest/youngest year they might be, maybe they just encode that as 0000/9999. Again, if you don't know the birth year of someone, you would have no way of knowing their age. I'm not sure that means that the general policy of putting a birthday into their ID number is flawed. Many governments re-issue national IDs to the same person with different numbers, which is far less problematic that the many governments who choose to issue the same national ID (looking at you USA with your SSN) to multiple individuals. It doesn't seem like a massive imposition on a person who was originally issued an ID based on not knowing when their birthday to be re-issued a new ID when their birthday was ascertained. Perhaps even give them a choice of keeping the old one knowing it will cause problems, or take the new one instead and having the responsibility to tell people their number had changed. Presumably the governments that choose to embed the date into a national ID number do so because it's more useful for their purposes to do so than just assigning everyone a random number.
  - notpushkin 10mo ago
    > or take the new one instead and having the responsibility to tell people their number had changed Or have the opportunity to scam people into thinking you’re a different person. (E.g. take a $1M loan, go bankrupt, remember your birthday, and take a loan again.)
OptionOfT 10mo ago
Belgium's national register number is similar: YY.MM.DD-AAA.BB In either the AAA or BB component there is something about the gender. But it does mean that there is a limit of people born per day of a certain gender. But for a given year, using a moniker will only delay the inevitable. Sure, there are more numbers, but still limited as there are SOME parts that need to reflect reality. Year, gender (if that's still the case?) etc.
- hyperman1 10mo ago
  BB is a mod-97 checksum. The first A of AAA encodes your gender in an even/odd fashion, I forgot if its the first or last A doing that. MM or DD can be 00 if unknown. Also MM has +20 or +40 in some cases. If you know someones birth date and gender, the INSZ is almost certainly 1 in 500 numbers, with a heavy skew to the lower AAA. Luckily, you can't do much damage with someones number,unlike an USA SSN (but I'd still treat it confidential).
  - notpushkin 10mo ago
    > I'd still treat it confidential Estonian isikukood is GYYMMDDNNNC, and is relatively public. You can find mine pretty easily if you know where to look (no spoilers!). It’s relatively harmless. Kazakh IIN is YYMMDDNNNNNN (where N might have some structure) and is similarly relatively public: e.g. if you’re a sole proprietor, chances are you have to hang your license on the wall, which will have it. It’s a bit more serious: I’ve got my mail at the post office by just showing a barcode of my IIN to the worker. They usually scan it from an ID, which I don’t have, but I’ve figured out the format and created a .pkpass of my own. Zero questions – here’s your package, no we don’t need your passport either, have a nice day! (Tangential, but Kazakhs also happen to have the most peculiar post office layout: it looks exactly like a supermarket, where you go in, find your packages (sorted by the tracking number, IIRC), and go to checkout. I’ve never seen it anywhere else.)
nonethewiser 10mo ago
>To me, what your example really shows is the problem with incorrect default values, not a problem with encoding data into a key per se. If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear. You still have that problem from organic birthdays and also the problem of needing to change ids to correct birth dates.
- jonny_eh 10mo ago
  To add to that, birthdays can clump, just like any seemingly "random" data.
  - lovich 10mo ago
    A million dots scattered randomly over a graph can all land on the exact same coordinate if it’s truly random. What most people intuit as random is some sort of noise function that is generally dispersed and doesn’t trigger the pattern matching part of their brain
    - Dylan16807 10mo ago
      > A million dots scattered randomly over a graph can all land on the exact same coordinate if it’s truly random. It won't happen though. 0.00000000% chance it happens even once in a trillion attempts. > What most people intuit as random is some sort of noise function that is generally dispersed and doesn’t trigger the pattern matching part of their brain Yes, people intuit the texture of random wrong in a situation where most buckets are empty. But when you have orders of magnitude more events than buckets, that effect doesn't apply. You get pretty even results that people expect.
      - lovich 10mo ago
        > It won't happen though. 0.00000000% chance it happens even once in a trillion attempts. It has the same odds as any other specific configuration of randomly assigned dots. The overly active human pattern matching behavior is the only reason it would be treated as special.
croes 10mo ago
> If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear > Norwegian PNs have your birth date (in DDMMYY format) as the first six digits. You can already feel the disaster rising because sone program expects always the latter. And it doesn’t fix the problem, it just makes it less likely.
PunchyHamster 10mo ago
> To me, what your example really shows is the problem with incorrect default values, not a problem with encoding data into a key per se. If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear. well, till you run out of numbers for the immigrants that don't have exact birth date

tyre 10mo ago

And then have to enter/handle a non-date through all systems? How do you know if this non-dated person is over the age of minority? Eligible for a pension? Maybe the answer is to evenly spread the defaults over 365 days.

ralferoo 10mo ago
If you don't know their birthday, you can presumably never answer that question in any case. If you only know the birth year and keyed 99 as the month for unknown, then your algorithm would determine they were of a correct age on the start of the year after that was true, which I guess would be what you want for legal compliance. If you don't even know if the birth year is correct, then the correct process depends on policy. Maybe they choose any year, maybe they choose the oldest/youngest year they might be, maybe they just encode that as 0000/9999. Again, if you don't know the birth year of someone, you would have no way of knowing their age. I'm not sure that means that the general policy of putting a birthday into their ID number is flawed. Many governments re-issue national IDs to the same person with different numbers, which is far less problematic that the many governments who choose to issue the same national ID (looking at you USA with your SSN) to multiple individuals. It doesn't seem like a massive imposition on a person who was originally issued an ID based on not knowing when their birthday to be re-issued a new ID when their birthday was ascertained. Perhaps even give them a choice of keeping the old one knowing it will cause problems, or take the new one instead and having the responsibility to tell people their number had changed. Presumably the governments that choose to embed the date into a national ID number do so because it's more useful for their purposes to do so than just assigning everyone a random number.
- notpushkin 10mo ago
  > or take the new one instead and having the responsibility to tell people their number had changed Or have the opportunity to scam people into thinking you’re a different person. (E.g. take a $1M loan, go bankrupt, remember your birthday, and take a loan again.)

OptionOfT 10mo ago

Belgium's national register number is similar: YY.MM.DD-AAA.BB In either the AAA or BB component there is something about the gender. But it does mean that there is a limit of people born per day of a certain gender. But for a given year, using a moniker will only delay the inevitable. Sure, there are more numbers, but still limited as there are SOME parts that need to reflect reality. Year, gender (if that's still the case?) etc.

hyperman1 10mo ago
BB is a mod-97 checksum. The first A of AAA encodes your gender in an even/odd fashion, I forgot if its the first or last A doing that. MM or DD can be 00 if unknown. Also MM has +20 or +40 in some cases. If you know someones birth date and gender, the INSZ is almost certainly 1 in 500 numbers, with a heavy skew to the lower AAA. Luckily, you can't do much damage with someones number,unlike an USA SSN (but I'd still treat it confidential).
- notpushkin 10mo ago
  > I'd still treat it confidential Estonian isikukood is GYYMMDDNNNC, and is relatively public. You can find mine pretty easily if you know where to look (no spoilers!). It’s relatively harmless. Kazakh IIN is YYMMDDNNNNNN (where N might have some structure) and is similarly relatively public: e.g. if you’re a sole proprietor, chances are you have to hang your license on the wall, which will have it. It’s a bit more serious: I’ve got my mail at the post office by just showing a barcode of my IIN to the worker. They usually scan it from an ID, which I don’t have, but I’ve figured out the format and created a .pkpass of my own. Zero questions – here’s your package, no we don’t need your passport either, have a nice day! (Tangential, but Kazakhs also happen to have the most peculiar post office layout: it looks exactly like a supermarket, where you go in, find your packages (sorted by the tracking number, IIRC), and go to checkout. I’ve never seen it anywhere else.)

nonethewiser 10mo ago

>To me, what your example really shows is the problem with incorrect default values, not a problem with encoding data into a key per se. If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear. You still have that problem from organic birthdays and also the problem of needing to change ids to correct birth dates.

jonny_eh 10mo ago
To add to that, birthdays can clump, just like any seemingly "random" data.
- lovich 10mo ago
  A million dots scattered randomly over a graph can all land on the exact same coordinate if it’s truly random. What most people intuit as random is some sort of noise function that is generally dispersed and doesn’t trigger the pattern matching part of their brain
  - Dylan16807 10mo ago
    > A million dots scattered randomly over a graph can all land on the exact same coordinate if it’s truly random. It won't happen though. 0.00000000% chance it happens even once in a trillion attempts. > What most people intuit as random is some sort of noise function that is generally dispersed and doesn’t trigger the pattern matching part of their brain Yes, people intuit the texture of random wrong in a situation where most buckets are empty. But when you have orders of magnitude more events than buckets, that effect doesn't apply. You get pretty even results that people expect.
    - lovich 10mo ago
      > It won't happen though. 0.00000000% chance it happens even once in a trillion attempts. It has the same odds as any other specific configuration of randomly assigned dots. The overly active human pattern matching behavior is the only reason it would be treated as special.

croes 10mo ago

> If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear > Norwegian PNs have your birth date (in DDMMYY format) as the first six digits. You can already feel the disaster rising because sone program expects always the latter. And it doesn’t fix the problem, it just makes it less likely.

PunchyHamster 10mo ago

> To me, what your example really shows is the problem with incorrect default values, not a problem with encoding data into a key per se. If they'd chosen a non-date for unknown values, maybe 00 or 99 for day or month components, then the issue you described would disappear. well, till you run out of numbers for the immigrants that don't have exact birth date