[Enhancement]: Enforce PNID links and only allow each PNID to be tied to one of each console (like on NN)

[jonbarrow]

Checked Existing

• [X] I have checked the repository for duplicate issues.

What enhancement would you like to see?

This is a 2 part issue, which ties directly into #100:

1. Enforce PNIDs to be linked to consoles before letting them go online. This is only really relevant to the 3DS, as the Wii U already enforces this.
2. Actually link PNIDs to consoles on the backend just like Nintendo did.

Part 1:

Enforcing a PNID to be linked to a console before going online has a few benefits, the biggest one being that it FORCES 3DS consoles to go through the NNID setup. This means we FORCE the 3DS to contact the NNAS server, which means we can:

• A) Ensure that a 3DS has an actual device certificate (not just the LFCS) tied to it.
• B) Actually tie a device to the device ID stored in said certificate.

Forcing a 3DS to link it's device certificate before going online means we always have access to it from the moment the user goes online. We plan to eventually completely change how bans are structured, and being able to simply directly ban the certificate would streamline things. Currently we still do support full console bans by using the LFCS, but being able to handle this as just device certificates would make things simpler when we transition the ban system. Currently the way console bans work is we lookup the console's records in our database and then set it's access level to -1. When we transition to a ban system where bans are stored as records in the database, being able to just store the device certificate hash in a ban record would simplify lookups (rather than trying to fumble around with checking both device certs and LFCS hashes).

Tying the device ID to the records in our database would also make some things easier in the admin panel. Currently @hauntii tries to use the device serial as the unique identifier, despite them being inherently untrustworthy (note that serials are not used for any actual checks besides sanity ones, since they are untrustworthy, Niko simply tries to use them as unique IDs).

Enforcing that a PNID be linked to a 3DS before going online would also give us an extra layer of tracking, especially when it comes to cheaters. For example if we find someone cheating in Mario Kart 7 we can see their PNID, and use that to cross reference who they are on a Wii U. If that Wii U has other accounts linked to it then we know to also monitor those accounts. Just as a basic example.

This brings things around to part 2.

Part 2:

Linking users to single devices of each type has several benefits, but the biggest one comes down to preventing account sharing on supporter accounts. Right now we have a major issue with how supporters are handled on the 3DS; we manually whitelist people. This worked "fine" in the old days, but now that we cycle through several dozen supporters coming and going every day it's way too much to handle on our own. @DaniElectra does a great job adding people to the whitelist, but without someone also keeping up on removing people we end up in a situation where people support, get whitelisted, stop supporting, and stay whitelisted. We have known about this issue for years, but chose to not think much of it until now,

In order to prevent this, #100 was proposed. While this would fix the manual whitelisting issue, it introduces a new one (which isn't exactly new since this happens on the Wii U already); account sharing. By allowing PNIDs to exist on any number of consoles, it encourages account sharing especially in cases of supporter accounts. This can cause issues as we now have accounts tied to multiple consoles, and we can't actually know for certain who is who. If 1 account is linked to 2 consoles, and it keeps cheating, which console do we ban? That sort of thing.

In the case of supporter accounts it also encourages, essentially, account "piracy". People share the details to supporter accounts and then share those details publically. This becomes an issue as we rely on donations to stay operational, and just further adds fuel to the "who actually is this" issue. Additionally it also creates a scenario which we are seeing pretty often; people selling PNIDs. I know of at least 2 cases where someone has been directly profiting off of the mass sale of supporter PNIDs. This is, obviously, something we do not want to encourage. Not only for the already previously mentioned issues, but also because it creates an environment for users to get easily scammed.

By only allowing PNIDs to be linked to one of each console type, we prevent all these issues.

Any other details to share? (OPTIONAL)

In order to do this properly we would need to throw the 0143 error on NNAS. This error, on the Wii U, throws the "The link to this Nintendo Network ID has been temporarily removed" error and unlinks the NNID from the local user account, forcing the user to sign in again and thus actually complete all the device detail filling and account linking.

This does mean that those who use Cemu as their primary medium would need to relink themselves using a real Wii U. I am aware that this may not be the case for everyone who uses Cemu, but that is unfortunately something I am willing to sacrifice in order to improve our own services and increase our security. Additionally, Cemu already has all the account information it needs to do the NNID/device linking process, so (while possibly not trivial) it is possible that Cemu could simply be updated to support this directly.

Additionally we would introduce a new issue that we would need to handle; manually unlinking PNIDs from consoles. This shouldn't be an issue from a technical perspective, but it is something people will request now (especially on the 3DS, since it doesn't have a "logout of NNID" button). We may be able to provide users the ability to unlink from their previously owned devices on the website however?

Also on the 3DS, I am unsure if 0143 from NNAS will have the same effect there. I remember testing some Wii U error codes on the 3DS a while ago and having slightly different results. This would need more testing.

[DaniElectra]

As much as I understand the reasoning of this proposal, some important (IMO) aspects are not being considered which would disrupt the usage of the service to some people (disclaimer for conflict of interest on Part 2 as I am directly affected by this). Along with my explanation, I will also add my own alternative proposal

Part 1

Enforcing a PNID to be tied to a 3DS would break support for Korean 3DSs, as they don't have support for Nintendo Network. You may argue that such a userbase is small enough to be sacrificed, but I would like to consider other options before jumping onto this.

The reasoning for Part 1 is that the admin panel relies on the serial number to search for consoles. For this, I propose adding the LFCS number (not the full cert!) to the database in order to allow an easy search of 3DS consoles in a trusted way. We already need to do this if we want to support people registering friends while not connected to the Internet, so I think this would be a good excuse to do it.

Part 2

Putting aside the issue of how to deal with PIDs which are already linked to multiple consoles (and viceversa), only allowing one PNID with one console fails to consider an even bigger issue than the previous one: system transfered consoles. I have explained countless times why is this an issue, so I will just add that people who have system transfered their console (or purchase a console from a person who has system transfered before) would be pissed if they can't access the service anymore.

My proposal in this case would be to limit the ability to link a PID to a new console within periods of time (whether to link the time to the PID or the console is something to be discussed). This is technically accurate to what Nintendo does, IIRC you can't system transfer your console for 7(?) days if you have already done so. This would essentially remove the issue of accounts being sold, and people can still system transfer their console with no issues.

[jonbarrow]

Enforcing a PNID to be tied to a 3DS would break support for Korean 3DSs, as they don't have support for Nintendo Network. You may argue that such a userbase is small enough to be sacrificed, but I would like to consider other options before jumping onto this.

Do we have any actual numbers for how large this player base is? Also what did Nintendo do in this case, since a NNID is required for many other aspects of the 3DS such as the eShop and (I forgot the 3DS doesn't need this for the eShop) certain games like Badge Arcade, were these simply not available in Korea?

Depending on how large the player base is in Korea I may be willing to sacrifice this. We already basically sacrificed all of China (see https://github.com/PretendoNetwork/Inkay/issues/19), so this would not be the first time we would do something like this. Alternatively, what exactly makes it so that Korean users can't use NN? I'd find it hard to believe that Nintendo made entirely separate, custom, builds of their FW with these bits gutted, surely it's all still there somewhere? Also region swapping is 100% still an option is it not? I understand that region swapping may have other side effects, like the system not being in Korean anymore, but it would at least get them back online no?

The reasoning for Part 1 is that the admin panel relies on the serial number to search for consoles. For this, I propose adding the LFCS number (not the full cert!) to the database in order to allow an easy search of 3DS consoles in a trusted way. We already need to do this if we want to support people registering friends while not connected to the Internet, so I think this would be a good excuse to do it.

The reasoning for Part 1 is not just about the admin panel. It's about streamlining several of our services and future plans. The admin panel is part of this, yes, but not the only thing. As I said it also streamlines the process of banning a console, since now we simply just ban only the device certificate and it would Just Work, even at the NASC level which doesn't send the device certificate. Being able to always know console ID also means we can safely prevent PID spoofing in the BOSS user agent on Wii U, which gives us the ability to send personalized content through BOSS (since now we can validate if the PID being used is actually tied to the console ID, which is not so easily spoofed).

Also adding the LFCS number to the DB was, yes, already planned.

Your suggestion also only accounts for the 3DS, and does nothing for the Wii U. Forcing users to link a device ID to their 3DS device records (which can only be done by forcing them to hit NNAS) is the only real way to, across both consoles, create a safe, unique, identifier that we can use to index from in the admin panel.

Putting aside the issue of how to deal with PIDs which are already linked to multiple consoles (and viceversa), only allowing one PNID with one console fails to consider an even bigger issue than the previous one: system transfered consoles. I have explained countless times why is this an issue, so I will just add that people who have system transfered their console (or purchase a console from a person who has system transfered before) would be pissed if they can't access the service anymore.

My proposal in this case would be to limit the ability to link a PID to a new console within periods of time (whether to link the time to the PID or the console is something to be discussed). This is technically accurate to what Nintendo does, IIRC you can't system transfer your console for 7(?) days if you have already done so. This would essentially remove the issue of accounts being sold, and people can still system transfer their console with no issues.

As I mentioned on Discord, my plan was to add a button on the users settings page on the website that would allow them to forcibly disconnect their PNID from either device. So they can simply force the disconnect via the website and then be on their happy way on their other device. This was already mentioned in my original post.

As for users who are already linked to multiple consoles, this was already gone over in my original post. Nintendo already gave us an out for this. Error code 0143 from NNAS will trigger an error displaying "The link to this Nintendo Network ID has been temporarily removed", and will unlink the NNID from the local account. The plan would be to create new fields on the PNID document for each console, and if the user is trying to login to a console which the server says it isn't linked to (either because the PNID has not been linked to one yet, or is linked to a different one), then sending back error code 0143

I know you have your concerns, but I don't see any concerns you have which are either

• Not fixable
• Worth not moving forward with this

System transferred 3DS's are a non-issue if users are allowed to unlink themselves from the website, Korean users are only partially an issue since afaik they can just region swap (assuming that Nintendo really did fully gut the NN parts from Korean consoles, which I have my doubts on), the issue of people already being linked to multiple consoles is fixed by forcing them to unlink from NNAS, etc.

The benefits of doing this far outweigh on cons imo. Being able to much more reliably track users and consoles is a must, without having to continue to try and rely on hacky work arounds just to get around implementing things correctly.

[DaniElectra]

Do we have any actual numbers for how large this player base is?

I don't, but I can understand that sacrificing that player base may be needed.

Also what did Nintendo do in this case, since a NNID is required for many other aspects of the 3DS such as the eShop and (I forgot the 3DS doesn't need this for the eShop) certain games like Badge Arcade, were these simply not available in Korea? ... Alternatively, what exactly makes it so that Korean users can't use NN?

The NNID system isn't that tied to the system on the 3DS (in fact, NNID support was added on a system update). The only account system that is really tied is NASC, and the link to an NNID would be (presumably) performed using the device_attributes. As such, games like Nintendo Badge Arcade weren't released in Korea, and the ACT sysmodule and the NNID settings were simply stripped out from that region.

my plan was to add a button on the users settings page on the website that would allow them to forcibly disconnect their PNID from either device. So they can simply force the disconnect via the website and then be on their happy way on their other device.

I see! That makes more sense, and addresses the concerns.

[jonbarrow]

@DaniElectra Do we have a safe, reliable, way of determining whether or not a 3DS is a Korean 3DS? If so we can possibly add some special handling here. But only if we can safely know the console is Korean. My thought is that we can possibly just ALWAYS put Korean consoles in the prod environment. This would allow them to still connect, but would have some consequences:

• No Korean 3DS user could ever be a beta tester
• We lose ALL of the "link the console data to the 3DS data" parts of this proposal
• We would need special handling of these consoles in the admin panel, since part of the point of this proposal is to standardize parts of the panel (such as using the device ID as the unique identifier), but on the 3DS we can only get that through the NNAS API

Even though Korean consoles don't support NNIDs, do we know if they have device certificates? Like the ones sent to NNAS? If so, then we can work around ALL of this by simply sending the device certificate to NASC in every request. The device certificate would give us the device ID and would give us, obviously, the device certificate hash