Fake SIN + Commlink, How do you treat it. Options Track this topic Email this topic Print this topic Download this topic Subscribe to this forum Display Modes Outline Switch to: Standard Switch to: Linear+

[Slymoon]

Unfortunately search terms under 3 letters long doesn't work, so it is tough to search SIN.


When purchasing a fake SIN, how does it come? On a chip?
Do you receive it as a download to your commlink? Can you house multiple fake SINs on a single commlink? or to be safe do you make it a package deal Fake SIN + Additional Commlink Setup.

A player noted that it would behoove the Fake SIN provider to make sure that it was provided on a relatively secure medium, less chance of anything getting back to the provider. ie: an at least middle grade commlink + decent Firewall. I can't fault his thought, but do you really want to get your hardware preloaded with a Fake SIN and OS from a hacker... backdoors away.

I can see the benefit as well as the problem with having more than 1 Fake SIN on a commlinkm hackers haven.
I can also see the benefit as well as the problem to having multiple Fake SINs each on its own commlinnk; money sink.

[Riley37]

So if a cop or any other person running a SIN check sends a confirmation request, and gets back info matching the person with the SIN... then that means that the database has the biometrics of the subject. Which implies that if you get a fake Evo sin, *your* biometrics go into both Evo and SIN registry databases. Which means that if Evo ever gets your biometric data any other way, and spend the resources on cross-checking databases, then they'd be able to connect the two instances of matching biometric data.

Which means don't ever get a fake Aztechnology SIN, and if you're a troll or orc, don't get a Renraku or MCT SIN, unless you happen to trust those particular corps with your biometrics.

[DireRadiant]

So if a cop or any other person running a SIN check sends a confirmation request, and gets back info matching the person with the SIN... then that means that the database has the biometrics of the subject. Which implies that if you get a fake Evo sin, *your* biometrics go into both Evo and SIN registry databases. Which means that if Evo ever gets your biometric data any other way, and spend the resources on cross-checking databases, then they'd be able to connect the two instances of matching biometric data.

Which means don't ever get a fake Aztechnology SIN, and if you're a troll or orc, don't get a Renraku or MCT SIN, unless you happen to trust those particular corps with your biometrics.

Depends on the records and how it's done. Both the data available and process can yield vastly different results

Consider a system with biometric data and multiple SINS for a Runner X.
Assumption 1 - SIN is a unique single value, it will either match or not.
Assumption 2 - Biometric data is inherently fuzzy, you can get degrees of matching.

SIN 1 + Runner X Biometric
SIN 2 + Runner X Biometric
SIN 3 + Runner X Biometric
SIN 4 + Runner X Biometric

If you send the system SIN 1 + Runner X Biometric and ask it if it matches, it will say "Yes"
If you send the system SIN 2 + Runner X Biometric and ask it if it matches, it will say "Yes"
If you send the system SIN 3 + Runner X Biometric and ask it if it matches, it will say "Yes"
If you send the system SIN 4 + Runner X Biometric and ask it if it matches, it will say "Yes"

If you send the system Runner X Biometric and ask for a match, you will get at least one. At this point it would depend on the protocol, it could easily offer a selection of SIN to choose from, or offer the "best" match, or the top 3 matches. (Note in the RAW the advice of an additional dice check for SIN verification that is a result of this type of scenario. Also look at situations where you are asked to provide corroborating identifying information in your day to day activities. It happens every time I go to my doctor, they ask for an additional piece of data from me to verify they are billing/pulling medical records of the right person. They need more then the exact match on the data I initially provided.)

There's plenty more variations that easily allow for a "dumb" remote query to allow a fake SIN to pass, and it would take a significant effort and data analysis for the fake SINS to be detected and removed. Keep in mind that there are always legitimate positive matches of biometric data between different individuals which always creates room for fuzziness in matching routines.

Think of a simple SIN checker as a box with an idiot light that goes red or green, and the more sophisticated SIN validators providing a higher level of detailed analysis.

When dealing with billions of people and non unique matching values it's not so simple to get exact results for matching.