Serial numbers...

[Don Y]

Any rules on designing a \"serial numbering\" scheme?

Strictly speaking, you only want to have a way of uniquely
identifying a particular unit. It should be readable by
a human as well as a machine.

The former likely means:
- a legible typeface with maximal spatial difference between glyphs
- set in a size large-enough to not require a magnifying glass

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can be mistaken as a \'6\'.
Or a \'9\'. Or a \'3\'.

Of course, mixed alpha and numeric have additional problems -- not
the least of which is there often isn\'t any obvious *cue* that
tells the human \"this glyph is intended to be alpha so constrain
your recognition choices accordingly\".

But, there\'s nothing that says \"serial numbers\" have to be sequentially
issued. And, some value to having a sparse identifier space as it
helps catch minor mistakes. E.g., a credit card number of
1234 5678 9012 3456 is most likely invalid (who owns the \'1\' block?)
but 1234 5678 9012 4356 might be valid!

(Validity could be encoded in the design of the identifier space
*or* could just be verified by tracking all the *issued* identifiers)

 

[Ian]

On 2023-05-03, Don Y <blockedofcourse@foo.invalid> wrote:

Any rules on designing a \"serial numbering\" scheme?

Strictly speaking, you only want to have a way of uniquely
identifying a particular unit. It should be readable by
a human as well as a machine.

The former likely means:
- a legible typeface with maximal spatial difference between glyphs
- set in a size large-enough to not require a magnifying glass

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can be mistaken as a \'6\'.
Or a \'9\'. Or a \'3\'.

Of course, mixed alpha and numeric have additional problems -- not
the least of which is there often isn\'t any obvious *cue* that
tells the human \"this glyph is intended to be alpha so constrain
your recognition choices accordingly\".

But, there\'s nothing that says \"serial numbers\" have to be sequentially
issued. And, some value to having a sparse identifier space as it
helps catch minor mistakes. E.g., a credit card number of
1234 5678 9012 3456 is most likely invalid (who owns the \'1\' block?)
but 1234 5678 9012 4356 might be valid!

(Validity could be encoded in the design of the identifier space
*or* could just be verified by tracking all the *issued* identifiers)

Is it also worth considering that sequential serial numbers may reveal
how many units have been made, which may be commercially sensitive?
(or, with limited editions, may increase the value of early units!)

My usual trick for unique, opaque, identifiers is to have an internal
count, 1,2,3,..., which is then bit-scrambled (move all of the bits
around), then XOR\'d with some random constant, and than append a check
digit. Format as a fixed number of digit groups (e.g. 12-345-678-9) for
readability (with leading zeros if necessary). This is reversible if
you want to use the original count as the database key, rather than
storing and indexing the formatted version as well.

Pick a length (number of bits) that\'s a few orders of magnitued
larger than you ever expect to need (then double it).

--
Ian

\"Tamahome!!!\" - \"Miaka!!!\"

 

[Martin Brown]

On 03/05/2023 08:36, Don Y wrote:
> Any rules on designing a \"serial numbering\" scheme?

I can think of a few followed by more than on maker:

Make it impossibly long and print it in a 2pt fussy font on some
inaccessible plate that requires dismantling to access. (Wifi Router).
Underside of something also labelled this way up is almost as good.

Be sure to us ink that smudges when printing or fades with time or glue
on the label that slowly fails due to heat generated by the kit so that
it falls off and is lost long before any anticipated failure is likely.

Strictly speaking, you only want to have a way of uniquely
identifying a particular unit.  It should be readable by
a human as well as a machine.

The former likely means:
- a legible typeface with maximal spatial difference between glyphs
- set in a size large-enough to not require a magnifying glass

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can  be mistaken as a \'6\'.
Or a \'9\'.  Or a \'3\'.

Avoid all of 1l|0OQS5B8
Delete all symbols that could be mistaken from the lexicon.
Otherwise you end up in the obfuscated C competition.

Add spaces every 4 or 5 characters too. Groups are easier to recall.
It really annoys me so many websites won\'t accept spaces in CC numbers.

Of course, mixed alpha and numeric have additional problems -- not
the least of which is there often isn\'t any obvious *cue* that
tells the human \"this glyph is intended to be alpha so constrain
your recognition choices accordingly\".

But, there\'s nothing that says \"serial numbers\" have to be sequentially
issued.  And, some value to having a sparse identifier space as it
helps catch minor mistakes.  E.g., a credit card number of
1234 5678 9012 3456 is most likely invalid (who owns the \'1\' block?)
but 1234 5678 9012 4356 might be valid!

Sequentially issued but with a credit card style check byte isn\'t a bad
compromise. Luhn algorithm is the got for this.

https://en.wikipedia.org/wiki/Luhn_algorithm

Our rail ticketing system has exactly this problem. After presenting the
card used to buy the ticket you are then required to enter a high
entropy impossible to remember 20 character password to get the tickets.
The bank card itself is protected only by a puny 4 digit numeric PIN and
you have justshown the machine that you have physical possession of it.

(Validity could be encoded in the design of the identifier space
*or* could just be verified by tracking all the *issued* identifiers)

It is handy to be able to recognise the date of manufacture from a
serial number sometimes so you might want that in there somewhere.

--
Martin Brown

 

[Don Y]

On 5/3/2023 1:02 AM, Ian wrote:

On 2023-05-03, Don Y <blockedofcourse@foo.invalid> wrote:
Any rules on designing a \"serial numbering\" scheme?

Strictly speaking, you only want to have a way of uniquely
identifying a particular unit. It should be readable by
a human as well as a machine.

The former likely means:
- a legible typeface with maximal spatial difference between glyphs
- set in a size large-enough to not require a magnifying glass

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can be mistaken as a \'6\'.
Or a \'9\'. Or a \'3\'.

Of course, mixed alpha and numeric have additional problems -- not
the least of which is there often isn\'t any obvious *cue* that
tells the human \"this glyph is intended to be alpha so constrain
your recognition choices accordingly\".

But, there\'s nothing that says \"serial numbers\" have to be sequentially
issued. And, some value to having a sparse identifier space as it
helps catch minor mistakes. E.g., a credit card number of
1234 5678 9012 3456 is most likely invalid (who owns the \'1\' block?)
but 1234 5678 9012 4356 might be valid!

(Validity could be encoded in the design of the identifier space
*or* could just be verified by tracking all the *issued* identifiers)

Is it also worth considering that sequential serial numbers may reveal
how many units have been made, which may be commercially sensitive?
(or, with limited editions, may increase the value of early units!)

The downside of this is exactly the issue you are trying to obfuscate:
there\'s no easy way for a consumer to determine if his unit is
affected by a particular problem -- unless you add something akin
to a \"hardware version\" to the identifier. ?

My usual trick for unique, opaque, identifiers is to have an internal
count, 1,2,3,..., which is then bit-scrambled (move all of the bits
around), then XOR\'d with some random constant, and than append a check
digit. Format as a fixed number of digit groups (e.g. 12-345-678-9) for
readability (with leading zeros if necessary). This is reversible if
you want to use the original count as the database key, rather than
storing and indexing the formatted version as well.

Pick a length (number of bits) that\'s a few orders of magnitued
larger than you ever expect to need (then double it).

 

[Don Y]

On 5/3/2023 1:26 AM, Martin Brown wrote:

On 03/05/2023 08:36, Don Y wrote:
Any rules on designing a \"serial numbering\" scheme?

I can think of a few followed by more than on maker:

Make it impossibly long and print it in a 2pt fussy font on some inaccessible
plate that requires dismantling to access. (Wifi Router).
Underside of something also labelled this way up is almost as good.

Not just underside: any place that requires moving a device
without disturbing its established interconnects to gain access
to that information!

Be sure to us ink that smudges when printing or fades with time or glue on the
label that slowly fails due to heat generated by the kit so that it falls off
and is lost long before any anticipated failure is likely.

Strictly speaking, you only want to have a way of uniquely
identifying a particular unit.  It should be readable by
a human as well as a machine.

The former likely means:
- a legible typeface with maximal spatial difference between glyphs
- set in a size large-enough to not require a magnifying glass

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can  be mistaken as a \'6\'.
Or a \'9\'.  Or a \'3\'.

Avoid all of 1l|0OQS5B8
Delete all symbols that could be mistaken from the lexicon.

Exactly. If 8 is disallowed, then you don\'t have to worry about
a damaged 8 being mistaken as a 6, 9 or 3. And, anyone reporting
an 8 in *their* number is obviously hallucinating!

Otherwise you end up in the obfuscated C competition.

Add spaces every 4 or 5 characters too. Groups are easier to recall.
It really annoys me so many websites won\'t accept spaces in CC numbers.

Yes, and the chunks should either be all the same (e.g., 4-4-4-4
for credit cards) or fit some patterned cadence (e.g., our SSNs
are 3-2-4, phone numbers are (3) 3-4, etc.)

And some things should NOT be numeric (e.g., is 11-02-23 the second
day of november in XX23? Or, the 11th day of the second month of xx23?
or, the 11th year, second month, 23rd day (pseudo military date)?

Of course, mixed alpha and numeric have additional problems -- not
the least of which is there often isn\'t any obvious *cue* that
tells the human \"this glyph is intended to be alpha so constrain
your recognition choices accordingly\".

But, there\'s nothing that says \"serial numbers\" have to be sequentially
issued.  And, some value to having a sparse identifier space as it
helps catch minor mistakes.  E.g., a credit card number of
1234 5678 9012 3456 is most likely invalid (who owns the \'1\' block?)
but 1234 5678 9012 4356 might be valid!

Sequentially issued but with a credit card style check byte isn\'t a bad
compromise. Luhn algorithm is the got for this.

https://en.wikipedia.org/wiki/Luhn_algorithm

Our rail ticketing system has exactly this problem. After presenting the card
used to buy the ticket you are then required to enter a high entropy impossible
to remember 20 character password to get the tickets.

Who/what created the password (presumably not you)?

The bank card itself is
protected only by a puny 4 digit numeric PIN and you have justshown the machine
that you have physical possession of it.

(Validity could be encoded in the design of the identifier space
*or* could just be verified by tracking all the *issued* identifiers)

It is handy to be able to recognise the date of manufacture from a serial
number sometimes so you might want that in there somewhere.

This gets into the problem I mentioned in my reply to Ian.

I guess you have to decide how much information the SN should
convey and to *whom*.

For example, our SSNs (used to?) indicate where they were issued
(the number-space was partitioned by region). Some states reveal
the place of issuance of license plates similarly. Is there
value in such revelations? Is there a cost to *breaking* those
rules??

 

[Ian]

On 2023-05-03, Don Y <blockedofcourse@foo.invalid> wrote:

On 5/3/2023 1:02 AM, Ian wrote:
:
Is it also worth considering that sequential serial numbers may reveal
how many units have been made, which may be commercially sensitive?
(or, with limited editions, may increase the value of early units!)

The downside of this is exactly the issue you are trying to obfuscate:
there\'s no easy way for a consumer to determine if his unit is
affected by a particular problem...

True, but that\'s conflating two things - design version and build instance

...unless you add something akin to a \"hardware version\" to the
identifier. ?

I\'d have model number (including revison, -001 etc.) and serial number.
Maybe also date, batch number, etc, though that could all be derived
from the serial number, depending on how much space there is and what
the requirements are.

--
Ian

\"Tamahome!!!\" - \"Miaka!!!\"

 

[Don Y]

On 5/3/2023 4:12 AM, Ian wrote:

On 2023-05-03, Don Y <blockedofcourse@foo.invalid> wrote:
On 5/3/2023 1:02 AM, Ian wrote:
:
Is it also worth considering that sequential serial numbers may reveal
how many units have been made, which may be commercially sensitive?
(or, with limited editions, may increase the value of early units!)

The downside of this is exactly the issue you are trying to obfuscate:
there\'s no easy way for a consumer to determine if his unit is
affected by a particular problem...

True, but that\'s conflating two things - design version and build instance

But the design drawings can (likely do!) contain a reference to
\"effectivity\" -- expecting this to be a serial number. Implicit
in that is the expectation that SN\'s greater than the specified value
will be produced after the design change.

...unless you add something akin to a \"hardware version\" to the
identifier. ?

I\'d have model number (including revison, -001 etc.) and serial number.
Maybe also date, batch number, etc, though that could all be derived
from the serial number, depending on how much space there is and what
the requirements are.

Again, it boils down to what you want the *user* to be able to deduce
from the \"identifier\". The manufacturer can (with good recordkeeping)
tell you which *components* went into any given SN, where it was
assembled, when, who it was sold to (disti), under which PO, etc.

Which (if any) of these things is necessary for the *customer* to
be able to ascertain is a different matter.

 

[server]

On Wed, 3 May 2023 00:36:00 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

Any rules on designing a \"serial numbering\" scheme?

Strictly speaking, you only want to have a way of uniquely
identifying a particular unit. It should be readable by
a human as well as a machine.

The former likely means:
- a legible typeface with maximal spatial difference between glyphs
- set in a size large-enough to not require a magnifying glass

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can be mistaken as a \'6\'.
Or a \'9\'. Or a \'3\'.

Skip those serial numbers that contain _only_digits 0,1,6,8 and 9.

Is a sequence of digits 19086 (or 98061 upside down) ?

Of course, mixed alpha and numeric have additional problems -- not
the least of which is there often isn\'t any obvious *cue* that
tells the human \"this glyph is intended to be alpha so constrain
your recognition choices accordingly\".

If you are on the international market, do not use alpha in the serial
number. People with different native languages tend to pronounce the
letters quite differently causing problems in the phone support.

If a product is to be sold in counties using either Latin or Cyrillic
letters. One way is to use the system used in car registration plates.
In Cyrillic countries only letters that looks similar to some Latin
letter are used in the registration plate.Thus, even if a police on
the street doesn\'t know the foreign letters, the car can finally
identified later by a more intelligent person.

 

[Don Y]

On 5/3/2023 12:35 PM, upsidedown@downunder.com wrote:

On Wed, 3 May 2023 00:36:00 -0700, Don Y <blockedofcourse@foo.invalid
wrote:

Any rules on designing a \"serial numbering\" scheme?

Strictly speaking, you only want to have a way of uniquely
identifying a particular unit. It should be readable by
a human as well as a machine.

The former likely means:
- a legible typeface with maximal spatial difference between glyphs
- set in a size large-enough to not require a magnifying glass

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can be mistaken as a \'6\'.
Or a \'9\'. Or a \'3\'.

Skip those serial numbers that contain _only_digits 0,1,6,8 and 9.

Is a sequence of digits 19086 (or 98061 upside down) ?

I suspect there is enough other context on a label (e.g., \"S/N:\")
to unambiguously resolve the number.

Of course, mixed alpha and numeric have additional problems -- not
the least of which is there often isn\'t any obvious *cue* that
tells the human \"this glyph is intended to be alpha so constrain
your recognition choices accordingly\".

If you are on the international market, do not use alpha in the serial
number. People with different native languages tend to pronounce the
letters quite differently causing problems in the phone support.

If a product is to be sold in counties using either Latin or Cyrillic
letters. One way is to use the system used in car registration plates.
In Cyrillic countries only letters that looks similar to some Latin
letter are used in the registration plate.Thus, even if a police on
the street doesn\'t know the foreign letters, the car can finally
identified later by a more intelligent person.

Hmmmm... interesting observation!

 

[Martin Brown]

On 03/05/2023 11:13, Don Y wrote:

On 5/3/2023 1:26 AM, Martin Brown wrote:
On 03/05/2023 08:36, Don Y wrote:

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can  be mistaken as a \'6\'.
Or a \'9\'.  Or a \'3\'.

Avoid all of 1l|0OQS5B8
Delete all symbols that could be mistaken from the lexicon.

Exactly.  If 8 is disallowed, then you don\'t have to worry about
a damaged 8 being mistaken as a 6, 9 or 3.  And, anyone reporting
an 8 in *their* number is obviously hallucinating!

I\'m more inclined never to use any of the confusable ones.

And some things should NOT be numeric (e.g., is 11-02-23 the second
day of november in XX23?  Or, the 11th day of the second month of xx23?
or, the 11th year, second month, 23rd day (pseudo military date)?

That can be a double edged sword. The Mormons do a lot of scanning of UK
church baptism, marriage and death records and internally clearly use US
style MM/DD/YYYY date format but some UK entries have ended up
transcribed as if DD/MM/YYYY with MM described in text JAN/FEB/MAR etc.
Somehow it seems absolute as JAN instead of 1 and transposed dates happen.

It only affects a small fraction of actual data where this has happened
*and* the day of birth is also a valid month. But it happens often
enough that if the microfilm of the right parish record isn\'t found at
MM/DD/YYYY and DD<12 it is always worth looking at DD/MM/YYYY.

For my money IBM had the right idea with dates and times YYYYMMDDHHMMSS.

Our rail ticketing system has exactly this problem. After presenting
the card used to buy the ticket you are then required to enter a high
entropy impossible to remember 20 character password to get the tickets.

Who/what created the password (presumably not you)?

You get sent an email with the high entropy code (in an impossibly small
font to cause trouble for anyone with less than 20:20 vision). You can
also now get an e-ticket on a smart phone which is much less hassle.

It is handy to be able to recognise the date of manufacture from a
serial number sometimes so you might want that in there somewhere.

This gets into the problem I mentioned in my reply to Ian.

I guess you have to decide how much information the SN should
convey and to *whom*.

Unless you expect large numbers of your customers to compare notes to
figure out your SN logic I really wouldn\'t worry about it.

I picked a random 8 digit start number and a random 3 digit prime number
as the increment for serial numbers. You can work out the sequence but
it is relatively well obfuscated for all but a determined adversary.

For example, our SSNs (used to?) indicate where they were issued
(the number-space was partitioned by region).  Some states reveal
the place of issuance of license plates similarly.  Is there
value in such revelations?  Is there a cost to *breaking* those
rules??

IMEI\'s for mobile phones do that - particularly where exactly the same
physical hardware is sold into different markets at radically different
prices. One of my phones turned out to be a grey import from the Middle
East officially destined for UAE but I bought it from Amazon uk.

It was very hard to tell but the support guys were correct!


--
Martin Brown

 

[Lasse Langwadt Christensen]

onsdag den 3. maj 2023 kl. 12.13.41 UTC+2 skrev Don Y:

On 5/3/2023 1:26 AM, Martin Brown wrote:
On 03/05/2023 08:36, Don Y wrote:
Any rules on designing a \"serial numbering\" scheme?

I can think of a few followed by more than on maker:

Make it impossibly long and print it in a 2pt fussy font on some inaccessible
plate that requires dismantling to access. (Wifi Router).
Underside of something also labelled this way up is almost as good.
Not just underside: any place that requires moving a device
without disturbing its established interconnects to gain access
to that information!
Be sure to us ink that smudges when printing or fades with time or glue on the
label that slowly fails due to heat generated by the kit so that it falls off
and is lost long before any anticipated failure is likely.

Strictly speaking, you only want to have a way of uniquely
identifying a particular unit. It should be readable by
a human as well as a machine.

The former likely means:
- a legible typeface with maximal spatial difference between glyphs
- set in a size large-enough to not require a magnifying glass

But, it also means choosing glyphs that are ALWAYS unambiguous.
E.g., if the print can be abraded, an \'8\' can be mistaken as a \'6\'.
Or a \'9\'. Or a \'3\'.

Avoid all of 1l|0OQS5B8
Delete all symbols that could be mistaken from the lexicon.
Exactly. If 8 is disallowed, then you don\'t have to worry about
a damaged 8 being mistaken as a 6, 9 or 3. And, anyone reporting
an 8 in *their* number is obviously hallucinating!
Otherwise you end up in the obfuscated C competition.

Add spaces every 4 or 5 characters too. Groups are easier to recall.
It really annoys me so many websites won\'t accept spaces in CC numbers.
Yes, and the chunks should either be all the same (e.g., 4-4-4-4
for credit cards) or fit some patterned cadence (e.g., our SSNs
are 3-2-4, phone numbers are (3) 3-4, etc.)

And some things should NOT be numeric (e.g., is 11-02-23 the second
day of november in XX23? Or, the 11th day of the second month of xx23?
or, the 11th year, second month, 23rd day (pseudo military date)?
Of course, mixed alpha and numeric have additional problems -- not
the least of which is there often isn\'t any obvious *cue* that
tells the human \"this glyph is intended to be alpha so constrain
your recognition choices accordingly\".

But, there\'s nothing that says \"serial numbers\" have to be sequentially
issued. And, some value to having a sparse identifier space as it
helps catch minor mistakes. E.g., a credit card number of
1234 5678 9012 3456 is most likely invalid (who owns the \'1\' block?)
but 1234 5678 9012 4356 might be valid!

Sequentially issued but with a credit card style check byte isn\'t a bad
compromise. Luhn algorithm is the got for this.

https://en.wikipedia.org/wiki/Luhn_algorithm

Our rail ticketing system has exactly this problem. After presenting the card
used to buy the ticket you are then required to enter a high entropy impossible
to remember 20 character password to get the tickets.
Who/what created the password (presumably not you)?
The bank card itself is
protected only by a puny 4 digit numeric PIN and you have justshown the machine
that you have physical possession of it.

(Validity could be encoded in the design of the identifier space
*or* could just be verified by tracking all the *issued* identifiers)

It is handy to be able to recognise the date of manufacture from a serial
number sometimes so you might want that in there somewhere.
This gets into the problem I mentioned in my reply to Ian.

I guess you have to decide how much information the SN should
convey and to *whom*.

For example, our SSNs (used to?) indicate where they were issued
(the number-space was partitioned by region). Some states reveal
the place of issuance of license plates similarly. Is there
value in such revelations? Is there a cost to *breaking* those
rules??

here the civil registration number is 10 digits, first six is date of birth dd-mm-yy
last four digits encodes the century, and makes a checksum add up
last digit is even for females, odd for males

 

[Don Y]

On 5/3/2023 2:28 PM, Martin Brown wrote:

Avoid all of 1l|0OQS5B8
Delete all symbols that could be mistaken from the lexicon.

Exactly.  If 8 is disallowed, then you don\'t have to worry about
a damaged 8 being mistaken as a 6, 9 or 3.  And, anyone reporting
an 8 in *their* number is obviously hallucinating!

I\'m more inclined never to use any of the confusable ones.

If you know the number is entirely numeric, then the number of
possible conflicts is greatly reduced. If you restrict the number of
symbols too aggressively, then your S/N gets longer, quicker.
E.g., skip 1, 3, 6, 8 and 9 and you have half the number of possibilities
at any given position. When does the added length of the identifier add
more to errors than the possibility of misread digits?

And some things should NOT be numeric (e.g., is 11-02-23 the second
day of november in XX23?  Or, the 11th day of the second month of xx23?
or, the 11th year, second month, 23rd day (pseudo military date)?

That can be a double edged sword. The Mormons do a lot of scanning of UK church
baptism, marriage and death records and internally clearly use US style
MM/DD/YYYY date format but some UK entries have ended up transcribed as if
DD/MM/YYYY with MM described in text JAN/FEB/MAR etc. Somehow it seems absolute
as JAN instead of 1 and transposed dates happen.

For written dates, I prefer ## month_name ####. It\'s easier to read than
#### month_name ## and avoids the ambiguity of pure numeric representations.

For *timestamps*, the one obviously displays units in decreasing order of
significance.

It only affects a small fraction of actual data where this has happened *and*
the day of birth is also a valid month. But it happens often enough that if the
microfilm of the right parish record isn\'t found at MM/DD/YYYY and DD<12 it is
always worth looking at DD/MM/YYYY.

For my money IBM had the right idea with dates and times YYYYMMDDHHMMSS.

Yes. Or, YYYYMMDDHHMMSS.xxxxxx...

Our rail ticketing system has exactly this problem. After presenting the
card used to buy the ticket you are then required to enter a high entropy
impossible to remember 20 character password to get the tickets.

Who/what created the password (presumably not you)?

You get sent an email with the high entropy code (in an impossibly small font
to cause trouble for anyone with less than 20:20 vision). You can also now get
an e-ticket on a smart phone which is much less hassle.

But it\'s an email so you can *enlarge* the font (HTML?), right?

I\'m more annoyed with printed items that seem to have decided they
couldn\'t afford to make the document/label/etc. larger AND felt they
needed to cram all of that cruft on it. Therefore, make everything
super tiny!

Or, applying markings in places that are simply too small to host
them. E.g., the wire temples on eyeglasses can barely support a
4 pt typeface. So, keep anothe rpair of eyeglasses so you can read
the markings on the first??

It is handy to be able to recognise the date of manufacture from a serial
number sometimes so you might want that in there somewhere.

This gets into the problem I mentioned in my reply to Ian.

I guess you have to decide how much information the SN should
convey and to *whom*.

Unless you expect large numbers of your customers to compare notes to figure
out your SN logic I really wouldn\'t worry about it.

Again, it depends on what you think might be \"leaked\" from that
knowledge. I\'ve seen some devices use a S/N as a default password.
So, while it doesn\'t give you a sure-fire way to guess at passwords, it
gives you a starting point (if the alternative is \"unconstrained TEXT\")

I picked a random 8 digit start number and a random 3 digit prime number as the
increment for serial numbers. You can work out the sequence but it is
relatively well obfuscated for all but a determined adversary.

In my case, I \"consume\" hundreds (thousands?) of S/Ns per site. So,
want a way to ensure they are \"reportable\" correctly. Ideally, have
a customer take a snapshot so he doesn\'t have to \"risk\" jotting
down an incorrect number (\"was this supposed to be a 6 or a G?
I can\'t read my own handwriting, now...\")

For example, our SSNs (used to?) indicate where they were issued
(the number-space was partitioned by region).  Some states reveal
the place of issuance of license plates similarly.  Is there
value in such revelations?  Is there a cost to *breaking* those
rules??

IMEI\'s for mobile phones do that - particularly where exactly the same
physical hardware is sold into different markets at radically different prices.
One of my phones turned out to be a grey import from the Middle East officially
destined for UAE but I bought it from Amazon uk.

It was very hard to tell but the support guys were correct!

I suspect they have access to <something> that reveals a lot about the
device from just the IMEI number (e.g., make, model, original carrier, etc.)
as they don\'t seem interested in anything besides the IMEI. I\'ve also noticed
that the \"unlockable\" devices have an entirely different IMEI (e.g., beginning
with an alpha)

 

[Don Y]

On 5/3/2023 2:42 PM, Lasse Langwadt Christensen wrote:

here the civil registration number is 10 digits, first six is date of birth dd-mm-yy
last four digits encodes the century, and makes a checksum add up
last digit is even for females, odd for males

So, *twins* have identical numbers?

 

[Lasse Langwadt Christensen]

torsdag den 4. maj 2023 kl. 00.54.41 UTC+2 skrev Don Y:

On 5/3/2023 2:42 PM, Lasse Langwadt Christensen wrote:
here the civil registration number is 10 digits, first six is date of birth dd-mm-yy
last four digits encodes the century, and makes a checksum add up
last digit is even for females, odd for males
So, *twins* have identical numbers?

no, some of the last four are different

 

[Don Y]

On 5/3/2023 4:13 PM, Lasse Langwadt Christensen wrote:

torsdag den 4. maj 2023 kl. 00.54.41 UTC+2 skrev Don Y:
On 5/3/2023 2:42 PM, Lasse Langwadt Christensen wrote:
here the civil registration number is 10 digits, first six is date of birth dd-mm-yy
last four digits encodes the century, and makes a checksum add up
last digit is even for females, odd for males
So, *twins* have identical numbers?

no, some of the last four are different

But that still places a low upper bound on the number of
persons that can be represented. E.g., there are about
3M births, annually, here. Assuming (best case!) of even
distribution throughout the year, that\'s ~10,000 per day
without \"numbering space\" for check digits.

Given that some days are more likely to see higher
birth rates, this suggests 4 digits wouldn\'t be enough
to *simply* number people

 

[server]

On Wed, 3 May 2023 16:44:20 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

On 5/3/2023 4:13 PM, Lasse Langwadt Christensen wrote:
torsdag den 4. maj 2023 kl. 00.54.41 UTC+2 skrev Don Y:
On 5/3/2023 2:42 PM, Lasse Langwadt Christensen wrote:
here the civil registration number is 10 digits, first six is date of birth dd-mm-yy
last four digits encodes the century, and makes a checksum add up
last digit is even for females, odd for males
So, *twins* have identical numbers?

no, some of the last four are different

But that still places a low upper bound on the number of
persons that can be represented. E.g., there are about
3M births, annually, here. Assuming (best case!) of even
distribution throughout the year, that\'s ~10,000 per day
without \"numbering space\" for check digits.

Given that some days are more likely to see higher
birth rates, this suggests 4 digits wouldn\'t be enough
to *simply* number people

Some refugee groups are the most likely to cause havoc to this kind of
numbering systems. Some immigrating people:

* might honestly not know their date/year of birth
* try to hide their history by avoid giving correct date of birth
* give incorrect dates/year to try to get some child benefits
* give date/year in some foreign calendar (e.g. Arabic) and the
immigration officer is too lazy to find the corresponding date in
official calendar

These are then stored to have been born on xxxx-01-01. Of course most
stored as January 1st are fake, since only a small fraction is
actually born on New Years Day, but how do you tell the difference ?
Those born in a foreign country and claim xxxx-01-01 as their birth
date are more suspect.

 

[Martin Brown]

On 03/05/2023 23:09, Don Y wrote:

In my case, I \"consume\" hundreds (thousands?) of S/Ns per site.  So,
want a way to ensure they are \"reportable\" correctly.  Ideally, have
a customer take a snapshot so he doesn\'t have to \"risk\" jotting
down an incorrect number (\"was this supposed to be a 6 or a G?
I can\'t read my own handwriting, now...\")

If it is on that scale then at the expense of needing a bigger label on
the product and a bit more effort creating the labels why not add a QR
code to each one that is something along the lines of.

http://support.widget.com/SN?nnnnnnnnn

And add a support subdomain to your website. Now that most mobile phones
can read a QR code why *require* the human read it and input manually?

--
Martin Brown

 

[Don Y]

On 5/3/2023 11:59 PM, upsidedown@downunder.com wrote:

On Wed, 3 May 2023 16:44:20 -0700, Don Y <blockedofcourse@foo.invalid
wrote:

On 5/3/2023 4:13 PM, Lasse Langwadt Christensen wrote:
torsdag den 4. maj 2023 kl. 00.54.41 UTC+2 skrev Don Y:
On 5/3/2023 2:42 PM, Lasse Langwadt Christensen wrote:
here the civil registration number is 10 digits, first six is date of birth dd-mm-yy
last four digits encodes the century, and makes a checksum add up
last digit is even for females, odd for males
So, *twins* have identical numbers?

no, some of the last four are different

But that still places a low upper bound on the number of
persons that can be represented. E.g., there are about
3M births, annually, here. Assuming (best case!) of even
distribution throughout the year, that\'s ~10,000 per day
without \"numbering space\" for check digits.

Given that some days are more likely to see higher
birth rates, this suggests 4 digits wouldn\'t be enough
to *simply* number people

Some refugee groups are the most likely to cause havoc to this kind of
numbering systems. Some immigrating people:

* might honestly not know their date/year of birth
* try to hide their history by avoid giving correct date of birth
* give incorrect dates/year to try to get some child benefits
* give date/year in some foreign calendar (e.g. Arabic) and the
immigration officer is too lazy to find the corresponding date in
official calendar

These are then stored to have been born on xxxx-01-01. Of course most
stored as January 1st are fake, since only a small fraction is
actually born on New Years Day, but how do you tell the difference ?
Those born in a foreign country and claim xxxx-01-01 as their birth
date are more suspect.

<grin> EVERY place that asks me for a birthdate is told \"jan 1\"
(because it is easy to remember -- you wouldn\'t want to disclose
the other month-day that is easy to remember: your ACTUAL birthdate!)
the year is something that is chosen at random to ensure I am
at least 18.

Likewise, phone numbers are total fiction.

And, 1313 Mockingbird Lane is a memorable street address!

I then record the declared year with the other lies I\'ve told
<whomever>:
- Mother\'s maiden name: green ice
- favorite food: buick
- where born: mashed potatoes
...

C\'mon, no one said the answers have to make sense; they just have to be
memorable secrets!

 

[Don Y]

On 5/4/2023 1:37 AM, Martin Brown wrote:

On 03/05/2023 23:09, Don Y wrote:

In my case, I \"consume\" hundreds (thousands?) of S/Ns per site.  So,
want a way to ensure they are \"reportable\" correctly.  Ideally, have
a customer take a snapshot so he doesn\'t have to \"risk\" jotting
down an incorrect number (\"was this supposed to be a 6 or a G?
I can\'t read my own handwriting, now...\")

If it is on that scale then at the expense of needing a bigger label on the
product and a bit more effort creating the labels why not add a QR code to each
one that is something along the lines of.

http://support.widget.com/SN?nnnnnnnnn

And add a support subdomain to your website. Now that most mobile phones can
read a QR code why *require* the human read it and input manually?

QR codes are a security risk as they are intended to encapsulate a URL.
Replace the legitimate QR code with a bogus one and the user has no
way of even examining its content to decide if it is appropriate.

QR codes don\'t let the user catalog the information \"offline\": \"Where
did you deploy the device with S/N 12345?\"

QR codes don\'t let the user identify a particular \"sought\" device:
\"Which one of these is S/N 12345?\"

Imagine you\'re an installer with a box of widgets walking around
a facility. If you \"register\" a particular widget as \"I\'m going to
install 12345 in location ABC, you\'d want to be able to find 12345
(if you set it down amongst the other units, temporarily) again,
with relative ease and certainty.

I\'m a big fan of having ONE copy of a piece of information and \"forcing\"
everyone that needs access to that information to be able to \"read\"
that. This ensures everyone sees the same data.

As it\'s easier to teach a device to read a string of printed glyphs
than it is to teach a human to read a barcode/QR code or <whatever>,
the safest bet seems to be to print a label and choose a typeface
that is easier for people AND machines to recognize.

Then, you just have to hope the information that the device reports
electronically is consistent with this external rendition.

 

[Lasse Langwadt Christensen]

torsdag den 4. maj 2023 kl. 09.01.14 UTC+2 skrev upsid...@downunder.com:

On Wed, 3 May 2023 16:44:20 -0700, Don Y <blocked...@foo.invalid
wrote:
On 5/3/2023 4:13 PM, Lasse Langwadt Christensen wrote:
torsdag den 4. maj 2023 kl. 00.54.41 UTC+2 skrev Don Y:
On 5/3/2023 2:42 PM, Lasse Langwadt Christensen wrote:
here the civil registration number is 10 digits, first six is date of birth dd-mm-yy
last four digits encodes the century, and makes a checksum add up
last digit is even for females, odd for males
So, *twins* have identical numbers?

no, some of the last four are different

But that still places a low upper bound on the number of
persons that can be represented. E.g., there are about
3M births, annually, here. Assuming (best case!) of even
distribution throughout the year, that\'s ~10,000 per day
without \"numbering space\" for check digits.

Given that some days are more likely to see higher
birth rates, this suggests 4 digits wouldn\'t be enough
to *simply* number people

Some refugee groups are the most likely to cause havoc to this kind of
numbering systems. Some immigrating people:

* might honestly not know their date/year of birth
* try to hide their history by avoid giving correct date of birth
* give incorrect dates/year to try to get some child benefits
* give date/year in some foreign calendar (e.g. Arabic) and the
immigration officer is too lazy to find the corresponding date in
official calendar

These are then stored to have been born on xxxx-01-01. Of course most
stored as January 1st are fake, since only a small fraction is
actually born on New Years Day, but how do you tell the difference ?
Those born in a foreign country and claim xxxx-01-01 as their birth
date are more suspect.

yep, about 15 years ago the system was changed to allow number than
doesn\'t have the checksum, because they ran out of number for 01-01-65 and 01.01.66