Can't let Redjack start all the SIN threads

First of all, a few assumptions:

• A SIN is a string of letters and digits, which serves as an index for ID data in one or more databases. All of this usually gets subsumed under "SIN", but in this case "SIN" refers just to the letters and digits
• The SIN also contains some basic ID information itself, to facilitate quick offline checks
• A SIN is supposed to be a unique, life-long thing which is usually assigned at birth. Information subject to change (height, photo...) can be stored in the attached databases, but the SIN itself should remain unchanged
• SINs were introduced in 2036 and have not changed much since then

So given these assumptions, which data could be encoded into a SIN? Here is what I though of so far:

• Date and location of birth: Pretty obvious
• Nationality/issuing authority: Also obvious
• Sex: Probably still "permanent enough", hindrances for transgender individuals depend on issuing authority
• Name: From weddings to initiation rites, in many cultures a good part of the population changes their name at least once
• Race: "How much melanin qualifies as 'black'?"
• Eye/Hair color: Bwahaha. Also difficult to assess on newborns.
• Metatype: Problematic due to goblinisation. On the other hand, lawmakers might just not have cared for those damn trogs (or even liked the idea of them being stuck with the "wrong" SIN)
• A few prominent points of fingerprints; ear shape, retina etc.: Not too precise but easy to check
• DNA: Again maybe half a dozen specific regions which show high diversity; probably provides better identification than biometrics and is unaffected by cyberware, but also more complicated to scan

Comments/More ideas?

That information likely does not exist within the SIN's ID itself. Much like your address does not exist within your social security number. The SIN is probably just something like 2e4a-55d3-0cb6-8f51, which is not sufficient to encode much data within. Specifically, that sixteen digit hexadecimal code suffices to store eight bytes of data. A QR code on the other hand stores around 300 bytes, so if SINs don't use alphanumerics and instead use something like a QR code they could hold some basic degree of data within the ID itself.

However, the more likely scenario is that it ID itself doesn't contain any information, and that all of the person's information (name, birthdate, etc) is stored in a database entry that the SIN's ID references. Which is how certain illegal people can get away with using other peoples' SINs. If the SIN number itself said that you were a 78-year-old woman named Beatrice from Milwaukee, it might be tricky for any shadowrunner to conceivably get away with using it. The hackers simply jigger the database to put in the new person's data to overwrite the original person's data so that when a young male orc uses it, it doesn't show the store clerk a picture of a little old lady on the register screen.

Ignoring for now the question of what SINs should be, here's a bit more from the 5th ed rules:

From Corporate Limited SIN, p. 84:

"Many of these Corporate Limited SINs record whether or not the character is Awakened."

This is also problematic because this can happen during a person's life.

From Corporate SIN, p. 85:

"Corporate Born records are limited to the megacorporation that generated them. Files in the Global SIN Registry can confirm she has a valid SIN, but do not contain any additional information."

I would change this to have them appear to be Corporate Limited SINs.

From ID and Credit, Fake system identification number (SIN), p. 443:

"SINs are digital, not physical objects. They exist on your commlink, or in your PAN."

This implies that the number could be quite long.

Unlike America, present day Germany does have social security numbers containing personal data, like e.g. birth date. Don't discount the possibility of a SIN containing the same. Of course this cannot be the only basis for the full-length number, but it can conceivably be part of it.



The same sentence appears in the SR4 core rulebook, p. 266

SSNs were never designed as IDs (and suck badly at it), but even these numbers are not entirely random.

SINs on the other hand are said to contain some basic data, and the new rules in SR5 say than only an R3 SIN has any external data attached, and only and R3 check queries even for the existence of external data.


I kept information theory to the level of "yeah, well, this might just be in the same ballpark". A complete fingerprint embedded in a number is BS, but encoding a few reference points falls in the realm of suspension of disbelief

In point of fact the first 3 digits of modern SSNs denote the State and county in which you were born, or lived at time of the SSNs issuing if not at birth.

I am so close to having a much more playable set of SIN rules from all these threads. I love the conversations and healthy debates; different views being presented and discussed!

I'm imagining that SIN's are now like QR codes which can contain quite a crapload more of info.

Which means you can do a very basic verification from the number itself, a child can't have a number issued two decades ago. What I'm imagining for SIN spot checks is basically that, just more precise: look at the contained data and decide with a decent probability that the SIN belongs to the person presenting it, without complicated scans or queries to background databases.

"Female Troll in her 30s, UCAS citizenship" is already an improvement, but still pretty unspecific since there are a lot of people who fit that criteria -- meaning that a lot of people can simply copy that number. So what I'm looking for would be a few more distinguishing features, which can still be easily checked and stay mostly fixed from birth on.


@Redjack: TBH I am probably way overthinking all this, but besides gameplay matters I think it's a interesting thought exercise.

Absolutely. I really like the conversation around everyone's different thoughts, then picking out the aspects I like and figuring how to implement that into play with simple rules. I tend to go to a position of over thinking as well, then coming back around to the simple. For example: The new initiative bugged us. We wanted to reduce the difference between the top & the bottom and allow better use of the new interrupts. We went through four different house rule sets, some worked, some didn't. The next to last one was great, but too complicated. In the end, we got about the same number spread by saying Base Initiative is REA + INT + 2d6 (instead of REA + INT + 1d6). Works well, we're all happy, but it was several iterations of testing to get there.

I like it, but with an exact date of birth. I haven't found anything in 5th edition about metahumanity being included as part of a SIN or online supporting data.

On a mostly unrelated note, I found in the 5th edition basic book (Fake SINs, p. 368) where high-Rating SINs come with matching organic samples (blood, skin cells, and hair).

Redjack, you mentioned that fake SINs of lower Rating than the verifier should always fail. I'm also thinking that there could be times when SINs of higher Rating than the verifier should routinely pass. Having it sometimes be a crap shoot feels right.

Part of this is that the team may have no idea what the "Rating" of a given verifier is, and will thus not know if their fake SINs are up to snuff. To me, this seems like a cool thing that a decker could try to determine by hacking, and if she's good or lucky, ensure that the team's SINs pass in any case. Possible tests include:

a) Scan for software version and settings to know what you're up against.
b) Disable the device entirely.
c) Disable merely the security alerts.
d) Whitelist the team's SINs, requiring an additional test (EDIT: after the fact) to un-whitelist the SINs to cover their tracks and not have their SINs burned as a result of the hack being discovered.
e) Lower security settings to cause the verifier to behave as if it were part of a low-security setup, e.g. point of sale.
f) Do a version rollback attack to give the verifier fewer dice due to bugs in previous software versions.
g) Hack the verifier to show perfectly matching demographic statistics to the operator or facial recognition unit.

You could also have the decker change the sensitivity of the scanner more (all the way) to the false positive versus false negative match.

Or just have it send a "pass" in response to any SIN check. They probably won't have anyone worse than the runners going through that checkpoint before it gets noticed, so you don't need to change it back afterwards.

Yeah, heeeeeyyyyyyyy.......

I think those are e and c on my list. As for not setting it back, I'd say it depends on how important it is that they never find out they've been compromised in that way. Thinking about it, it might be a bad idea to let players have a direct way to avoid that kind of security.

Sure, the SIN would have the exact date, but since it's hard to verify a person's exact age, a cursory check by a cop or bouncer would boil down to whether the subject appears to be in the right ball park.

According to 3rd and 4th Edition rules, the SIN contains birthdate, -place, citizenship, and initials. Those are mostly fine, just the initials make no sense. Besides the various opportunities (or even requirements) for name changes, there is also the fact that most of the world do not adhere to the "Given Name, Middle Name, Family Name" scheme. What are the initials of Mr. عبد الله محمد بن موسى الخوارزمی, and do we use the original spelling and reading direction or transcribe him as "Abū ‘Abdallāh Muḥammad ibn Mūsā al-Khwārizmī", or maybe as "Abū Ǧaʿfar Muḥammad b. Mūsā al-Ḫwārizmī"? And at least Arabic is still written horizontally ...

Sex (male,female,X) and metatype on the other hand seem comparatively safe options: Sex reassignment will probably still be rare (and getting a new SIN still be among the easier steps), goblinization follows rules (orks don't become trolls) and in both cases, there will also have been a significant body of decision-makers whose approach was "screw those abominations".



@RJ: So basically everybody gets 2 IPs?

Depends...
Example 1: REA(3) + INT(3) + [2,2] = 10. Only 1 IP
Example 2: REA(3) + INT(3) + [3,4] = 14. Yea! Average is 2 IP.
Example 3: REA(3) + INT(3) + [6,6] = 18. Maxed at 2 IP for the average person... and plenty for interrupts if needed.

Given that the numbers are fairly universal (i.e. most countries apparently are using the same system), and that the system was probably built to last for many generations, and that it was probably built to have blocks of numbers given to various granting authorities (which isn’t efficient), I’d agree that these are big ‘numbers.’ The suggestion that they may typically be something like a QR code makes some sense to me, but also I’m thinking of the IPv6 model of internet addresses, where they basically just allowed for a very large quantity of numbers.

Here the granting nation may not be recognizable as “UCAS” as the front of the number, but knowing that numbers starting between 1025 and 4048 were granted by the UCAS lets those familiar with such things tell quickly.

If the number is sufficiently large, it is possible that how some portions of it are generated may vary between jurisdictions. Within their range of numbers, maybe UCAS codes gender, date of birth, and initials. Maybe the Trans-Aleut Council just hands out numbers sequentially with no additional data buried in it (you have to go look at a database), while maybe Aries codes everything from your blood type to who your parents were.

Anyway, I’d think that the vast majority of SIN checks would be accompanied by, or even be incidental to, license checks. Your national SIN may not tell a viewer much without accessing the appropriate database, but the licenses that you have for everything from driving to being allowed to draw breath while being a mage no doubt contain a lot more personal information. And normally no doubt those licenses are associated with your SIN, available all in one data gulp to anyone with a modicum of authority.

So what makes you think such block allocations would be used, then? Reserve two places in the SIN for the equivalent of an ISO 3166 code, done. Place of birth can be encoded by a military grid number (6 digits for 10 km precision), for the date four alphanumerical digits suffice for 36^4 days or ~4600 years. Sex + metatype fit into one digit, another two digits running number, that's 15 digits with plenty of space.

Because I've been close enough to various standards body to have great respect for their ability to make robustly messy decisions which will not totally alienate anyone but which will please nobody. All the major countries and corps agreeing to one compact algorithm, when data is cheap? Nah, I don't buy it.

Luckily enough, you don't have to buy it. Here's the quote:


So, the explanation is simple: The world is corporation-ruled, the corporations use the CC, the CC has the GSINR as one of its subsidiaries, and global adherence follows.

There certainly is a good number of dumb standards, but numbering schemes are simple enough that they are hard to screw up

And as bannockburn pointed out, the fact that the Corporate Court has a few more teeth than other international standardization bodies solves a few principal problems of creating new standards. Case in point, in SR North America has switched to metric...how anti-dystopic is that?

As for the suggestions of QR codes (or simply transmitting some file containing additional data): Certainly possible, but does that solve the question of which life-long and easily verifiable identifying feature could be embedded there from birth?

That begs the question, what about gender and racial reassignment surgeries?

Lone Star: This SIN is for a 40 year old human, male. You are definitely not a 40 years old human male.
Person: Well thank you... Though, 40 years ago I was born a human male, but today my name is Alisha Oakenleaf. My surgeon's name is Fred Aspen; he is on retainer.

Lone Star: Ears, breasts, soft skin....
Person: 2,500 nuyen, 5,000 nuyen, weekly spas visits @ 75 nuyen...

Something I thought was conflicting in the rules, it says that SINs are supposed to stay with a person for life, but then goes on to list several examples where a person is issued a new one.

The GSINR allows issuing a new SIN matching sex (gender reassignment would require psychosurgery ) or metatype, and in any case, the database gets updated. Of course, this process still needs to go through the national or corp authorities, which may do their worst to hassle those people.

Anyway, I had something of an idea, based on this exchange: Just add a physical token to the mix in the shape of a SIN card, a tiny chip card which stores the SIN plus some verification to prove it's been issued legitimately. It's normally plugged into your commlink but may also be slotted into a verification device directly or even inspected visually, in either case it serves the same purpose as holograms and watermarks on physical documents: It's not impossible to copy or manufacture, but more legitimate than just calling out a number.

And the second two are year of birth (non-linear 100 year rotation). The last four are incremental. First dude registered on Jan 1 gets 0001, second guy gets 0002, and so on.



No it doesn't.

Ugh. You really used wikipedia to raise a point of order and then ignored the second paragraph '"to beg the question" is sometimes also used to mean "to raise the question"'. I mean really?

I only see where a new SIN is issued on a change of citizenship (SR5, pg367). Did I miss something?

Interesting idea. I'll have to think on that a bit.

You missed the next sentence, which said that "That usage is often proscribed."


http://begthequestion.info/

No I didn't. I ignored it because I used the term to mean "to raise the question".

This is much like the use of the word "ain't". When I was a kid, grammar teachers hated it. Now... now it is in the common vernacular as well as most dictionaries.

And that usage is proscribed. If you really want to say "that raises the question," use the word "raise." Because you are not asking for the principle.

Unless you two are starting up a GrammarRun™ campaign, how about we bring this on back topic please?


And yes, the irony of me pointing out a possible derailing is not lost on me.

I like Sengir's SIN token idea, it would certainly make switching between your SINs on your comm make a bit more sense, since you are only supposed to have one SIN at a time on your comm so where would your other ones be stashed when not in use.

Now it would be like swapping out your SIM card in your phone, although some cub with some welding/wiring skills could make a multi-slot holder that lets you physically switch the connection between multiple SIN tokens (though still only one at a time is connected to the system as the other two are isolated ), so turn the switch to position A for the everyday SIN, switch to B for your runner SIN and turn to C for one of your cover SINs.

Yes, it appears that question was begging to be raised as well.

Imagine the Frankenstein that a runner's comlink could become very quickly. Ha!

Let's go one better, revive the skillwire jukebox and have it tied into your Multi-SIN switch so that when you flip SIN Personas it also fires up the appropriate skillwire set.

This way you don't accidentally keep Kung Fu 5 running while in your wageslave cover SIN and then trash most of your department when they surprise you with an unexpected birthday party.

By RAW there is no sex or metatype/race in a SIN, but we are not going by RAW here

By common sense, re-issuing a SIN means nothing more than changing two database entries. The existing data is found under the new SIN, while the old SIN gets marked as "this is now [new SIN] and only valid for stuff before [date]". And in case of the the "SIN card" approach, which I like better the more I think about it, a new card needs to be issued. But since physical objects have a habit of getting lost, stolen, or otherwise compromised, there should already be procedures for that.
(If the chip is simply lost or stolen, the SIN would remain the same, just the old chip gets marked as void)


And are you two seriously discussing whether somebody's pet peeve makes sense or is just a case of being overly pedantic? Just run a forum search for "clip" or "magazine"

Well, dual citizenship is possible and would probably result in two SINs, so there would even be a legitimate market for multi-SIN commlinks

Had not thought of that, assuming dual citizenship still works the same way and one SIN doesn't just trump the other in the grand scheme of SINs.

The first question would be whether the SIN is a "global identity number" with citizenships attached as data fields in the associated database, or basically a citizenship in itself. I tend towards the latter, because a SIN is not something everybody has with citizenship added or removed as a data bit. A SIN is something bestowed upon a person by the issuing authority.

Therefore, a dual citizen should indeed have multiple SINs (and SIM cards), although at the GSINR and the issuing authorities should be aware that the different SINs belong to the same person.

I'm away from book at the moment, but I think I remember it saying that changes in citizenship result in a SIN change, not two SINs. Is there fluff of people having dual citizenship?

I think that multiple SINs would be for people working under deep cover, intelligence operatives, and the like.

Thanks bannockburn. Where was that from?

From the same place as all the other quotes, the core rulebook, p. 266(ish for SR4).
Basically the same paragraph is in SR5, too.

on the matter of external databases... there are so many databases (1 for each megacorp or country that issues a SIN), that it makes good sense to have some intermediary services to check all that data for you. heck, theres probably a paid service to help check external databases.

now, the point where things can get strange... if someone is a witness or suspect, i would bet that the security forces (corp, lone star, KE, ect) will retain a copy of that SIN and the associated external data. if a person goes missing then they may check that data, to see if its still there- or to see if they get multiple hits off the biometrics. they know fake SIN exist, and will likely keep the possibility in mind of a procedural, bureaucratic level. the very serious-minded will keep offline storage of older records.

so logically, you should only have 1 'good' SIN at any time, although you could get a good one from several different databases... unless someone decides to use one of those database services to check multiple sets for your biometrics at once. heck, they can probably use analytics to see how common duplicated biometrics are and then start investigating those. some of them probably investigate duplicates as a matter of course, which may add a 'flag' on all of those SIN for the security officers.

So, lets say runner A fakes his death, and his old sin is marked as 'deceased', and he gets some cosmetic work done, and grabs a fake SIN. at some point (on a critical glitch, most likely) that old data may flag to his new fake SIN, somewhere in the system. heck, in other cases a crit-glitch may be them seeing something odd where there isnt anything, because you just happen to have a SIN a bit too similar to somebody else.

all SIN will likely indicate if the individual has a Twin, and mark such on both SIN. this is likely abused by those getting multiple fake SIN. lets hope they dont retina scan you...

My assumption is that there is only one, central database (the GSNIR), and this registry only confirms or denies whether the SIN and biometrics submitted by a check match or don't match.

Of course, somebody might still store that certain biometrics were confirmed to belong to a certain SIN and object if the same biometrics later are used with another SIN. But that means you are abusing a system belonging to the CC, bad idea

Random question:

Has anyone ever thought to hack the sin-scanner device itself and spoof a validation check? Remember, all that comes back from whatever central server should be either "yes its valid" or "no its not."

Well, I guess that'd be an "Edit File" action after breaking in. But depending on how high the rating of the device is, it might be rather difficult to perform.

But of course, that's how SR5 chooses to work.

That is generally what I tend to do.

In 4th, you could also intercept and edit the network traffic so the device got back an "OK". So far 5th only lets you manipulate files, so that will have to wait till Data Trails