Patch 7.2's Account ID protection measures have already been circumvented

[Gurgeh]

Maybe thats the master plan.
You can't have stalking...
if there is noone to stalk!

[PotatoePet]

I mean I seriously cannot imagine doing server-side blacklist calculations cost that much extra money. At some point FF14 players have to realize that CBU3 is the epitome of a penny pinching studio. Yoshi P is a glorified accountant. He takes pleasure in cutting costs on his precious spreadsheet.

Programmer (and former game dev) here with nearly 20 years of experience (also server-side development):

I assume that yes, it will cost more power. I assume this because they implemented this feature in that way obviously to save that power.

If I had to guess how they handle player synchronization in open field is that they have a mesh of cells. Every cell can be subscribed to by players and are a basically shouting out all information required to synchronize data with all subscribed clients. (Everyone receives the same data) You can see those cells in-game btw when there are a lot of people around and the game is actively lowering the amount of cells you can subscribe to.

This all is pretty performant as it's basically a simple pubsub system. Creating custom packages for every user would mean extra computing power needed.

As I never have worked on a MMO before I can't estimate the exact extra cost. It might also be a problem of old code not being able to support this change requiring at least a refactoring of that old code.

Just wanted to add my 2c because people in the forums are always like "This is a beginner problem and totally easy to solve." when they most likely never worked on server-side code before.

In regards to that "cryptography" attempt of them... That's actually a beginner error. But any cryptographic approach is destined to fail anyway, be it a hashsum or actual encryption as the client itself still has to be able to differentiate between players so hashes need to be unique or the encryption has to be decrypted by the client (and therefore must have a key to do so which can be extracted)

[Exmo]

I expect their attempt at obfuscating IDs in a decryptable way was mainly driven by PR goals dictated by management who wouldn't take "this is pointless" as an answer. It was clear they have no intention to eat the cost of moving the system server-side, likely because doing that would also fail to address the fundamental issue that is inherent in this blacklist feature: that users can block player characters are linked to a given account. So long as that feature is present, users can learn that information too.

[PotatoePet]

Yea, it's kinda ironic that this feature was meant to improve privacy by enabling people to block characters and all their alts but by doing it that way (very naive and cost-effective) they ended up invading the privacy of all players (at least the ones with alts). I mean ultimately they would've had to add a filter to all outgoing broadcasts and filter out data of blocked characters for each recipient. It would have a cost but I personally think that cost would have been worth it.

Or they could have at least made it a bit harder for data scraping by only communicating the character ids of accounts you have blocked when they are in the zone you enter or they enter the zone you are in. So you block character A of account A and character B enters the same zone as you the server simply tells your client: Btw, the character ID xyz is on your block list.

That way you could theoretically still scrape data, especially if you specifically target certain players but you wouldn't make it possible to generate whole databases of accounts with all their characters and retainers etc.

[Exmo]

You would. It's the same process as the existing stalker plugin. It took a bit of time to grow the db because the author and other participants had to trawl worlds to generate the network data with account IDs.

Even if the packet contained zero data about whether a player is blocked or not, and the approach was to simply omit data about blocked characters from the packet, a scraper would still be able to get the information they want very easily.

[PotatoePet]

Let me explain more in detail.

The situation right now is that if your client subscribes to a cell it will get a list of all players within that cell including the character ID and account ID. (They are doing this so all blocking can be done client-side)

This way you can scrape all characters and link them to account IDs just by flying around.

My approach was to only inform the client if it is necessary. It is necessary if 2 conditions are true:
You have blocked a character (and therefore that account)
A character of that account is in the same instance as you (or even you subscribe to that cell)

After that all the work can still be done by the client.

As the block list is limited to 200 players and it's required to actually add someone to that list in order to be able to have a chance to encounter their alts it greatly reduces the amount of data gatherable.

You can find alts in a similar fashion right now as well: If you have blocked someone in-game and you are logged in to lodestone and see an alt of that character, it shows that they are blocked as well.

The discoverability would be as low with my approach imho. Especially if the game doesn't tell you: Character X is blocked because you blocked character Y but just "Hey, that character is blocked because its an alt of a character you have blocked"

The ideal situation would be to only transfer data of non blocked characters and filter out blocked characters completely and don't let the client even know this.

[Gurgeh]

Programmer (and former game dev) here with nearly 20 years of experience (also server-side development):

I assume that yes, it will cost more power. I assume this because they implemented this feature in that way obviously to save that power.

If I had to guess how they handle player synchronization in open field is that they have a mesh of cells. Every cell can be subscribed to by players and are a basically shouting out all information required to synchronize data with all subscribed clients. (Everyone receives the same data) You can see those cells in-game btw when there are a lot of people around and the game is actively lowering the amount of cells you can subscribe to.

This all is pretty performant as it's basically a simple pubsub system. Creating custom packages for every user would mean extra computing power needed.

As I never have worked on a MMO before I can't estimate the exact extra cost. It might also be a problem of old code not being able to support this change requiring at least a refactoring of that old code.

Just wanted to add my 2c because people in the forums are always like "This is a beginner problem and totally easy to solve." when they most likely never worked on server-side code before.

In regards to that "cryptography" attempt of them... That's actually a beginner error. But any cryptographic approach is destined to fail anyway, be it a hashsum or actual encryption as the client itself still has to be able to differentiate between players so hashes need to be unique or the encryption has to be decrypted by the client (and therefore must have a key to do so which can be extracted)

Absolutely! 100%!

But I don't think many people have suggested if a "begginer" issue to "solve".
I think what they (and I) have suggested is that is a "beginner" issue to "not make in the the first place". And in that they are 100% correct, and another 1000% on top of that.

- They should never have started exposing the account ids to the client 'in plain text'.
- They should 'never' have started exposing the account ids to the client.
- They should never have started exposing the account ids to the client in a game that is 'rife' with addons, and has a game culture where cat/bun-girls and romantic (oft confused) relationships are hallmark of your game.

It was a beginner F up not to make.

What is also 'very' feasible if you can be arsed is to roll it back.
Not saying its easy.
Yes rebasing the code will be gargantuan.
But it is doable.
It frankly 'has' to be done. Its the only option on the table.

AsI've said elsewhere I could easily believe tha moving this server side is well within 'infeasible' (effectively impossible) territory. (Unless you want to be changing so much you'll be irining out the kinks and game breaking bugs for the next 3 years)

I'll be blunt what I think they should be doing is saying:
- We realise we have messed up. We hope you understand we did this with the best of intentions. But we realise we have really messed this up.
- Many of you are not going to like the following, but we have a responsibility as dev to show leader ship. (the same way we do on other ocassions we don't listen to you and do our own thing anyway)
- ALL game dev is now on hold until further notice.
- We are continuing suspension of housing until dev resumes. We anticipate many of you will want to pause your sub. (hell even offer free sub, or heavily discounted to cost of keeping the lights on in the server rooms.)
- All dev resources are now working on rolling back this change and the testing that entails. This will be a herculean task for us as obviously we can't just delete DT with that. (yes I know, no jokes abut you wish they would please)
- There will not be any field operations. There will not be any more dungeons, nor msq, nor raids, nor unreals, not fesitval-events until this work is complete, except were a this does not in anyway delay or remove resources from rolling back the blocklist change.
- We are very sorry for this but the welfare of the community is the most important thing to 'us'. (we are showing leadership and following our own mind on this)
- It is a certainty that all content will be severely delayed I am afraid. We are very sorry.

(hey, we can't offer you our AAA titles, but maybe you'd like to claim a couple of old titles. We are 2 old final fantasy titles on your registered XIV platform. Perhaps you'd like to try something you've seen appear in XIV? Something you probably never would have bought.)

"We are your friends. We've got your back"

And really those that want to get indignant that their raiding schedule is a serious busineness and must not be impeded. F'em.

[Exmo]

Let me explain more in detail.

The situation right now is that if your client subscribes to a cell it will get a list of all players within that cell including the character ID and account ID. (They are doing this so all blocking can be done client-side)

This way you can scrape all characters and link them to account IDs just by flying around.

My approach was to only inform the client if it is necessary. It is necessary if 2 conditions are true:
You have blocked a character (and therefore that account)
A character of that account is in the same instance as you (or even you subscribe to that cell)

After that all the work can still be done by the client.

As the block list is limited to 200 players and it's required to actually add someone to that list in order to be able to have a chance to encounter their alts it greatly reduces the amount of data gatherable.

You can find alts in a similar fashion right now as well: If you have blocked someone in-game and you are logged in to lodestone and see an alt of that character, it shows that they are blocked as well.

The discoverability would be as low with my approach imho. Especially if the game doesn't tell you: Character X is blocked because you blocked character Y but just "Hey, that character is blocked because its an alt of a character you have blocked"

The ideal situation would be to only transfer data of non blocked characters and filter out blocked characters completely and don't let the client even know this.

I understood your proposed approach the first time. As I said, it doesn't really address the fundamental issue and it doesn't make it that much harder to discover linked characters. Omitting blocked character data from the network packet does not prevent a user from discovering what data was blocked. They can discover this easily by comparing packets received by different clients for a given instance at a given moment in time and seeing what is absent from the non-control group.

In effect, SE could spend a lot of resources right now to move blacklist checks server side, but all this will actually do is kick the can down the road. Someone would still create a plugin to find linked characters in a matter of weeks or months. So SE will probably have eaten that cost and upgraded their infrastructure globally pointlessly, for a little bit of good PR.

People here keep missing the fact that the privacy issue is fundamental to the feature, not the implementation. So long as the feature is "block all characters in a given user account", there is no possible implementation that will address the privacy concerns.

[PotatoePet]

...

Yea, one would wish they would take any responsibility in the situation.

AsI've said elsewhere I could easily believe tha moving this server side is well within 'infeasible' (effectively impossible) territory. (Unless you want to be changing so much you'll be irining out the kinks and game breaking bugs for the next 3 years)

Which brings me to

People here keep missing the fact that the privacy issue is fundamental to the feature, not the implementation. So long as the feature is "block all characters in a given user account", there is no possible implementation that will address the privacy concerns.

Yea, that's true. The feature will always make it possible to link one character to another. Only thing they can do is making it harder. Question is, if this is actually worth it for the little effect this feature actually has and if just increasing the block list to 1000 slots would be a better alternative.

[Rin_Sato]

.
...
Question is, if this is actually worth it for the little effect this feature actually has and if just increasing the block list to 1000 slots would be a better alternative.

Making the blocklist 1000 slots does sound like the best option, especially with how simple and easy it would be to do, they can't possibly mess that up too...