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

Quote:

---

Originally Posted by GiR_Zippo

Means SE could easily set the visibility from a blacklisted player server side to 0 and suppress the chat messages.
Basically the same situation we have now (he can see you, you can't), just done server sided?

---

They could do that but it's a much more expensive approach, either in terms of how it slows the game's performance or in terms of reallocating infrastructure resources in all their data centers.

However, that still won't make it impossible for someone to create a database with every user and their alts. So long as the feature intends to hide all of a blocked player's characters, a malicious user can easily leverage that to discover alts.

SE has unfortunately not really ever taken player privacy seriously. This dates back to ffxi - taking a player off your friends list only takes them off YOUR list, not the other persons. I'm pretty sure it works that way here too, or did last I checked. So it's always been pretty easy to just stalk anyone you want even if they end the "friendship".

I think its a cultural thing - ending a friendship may be considered rude in Japan? But for Americans it's sometimes the only option to avoid toxicity.

I dont have high hopes for them taking meaningful action.

Quote:

---

Originally Posted by kajv95

At the launch of Dawntrail's Early Access, it was discovered that, to facilitate the new Blacklisting features, each service account's unique identifier is being broadcast to everyone within the zone you're in. This unique identifier is used to identify the player on a service account level, meaning every character on that service account shares the same unique identifier.

Some unhinged people created a tool that farms that data to create a database, allowing the users of said tool to track players on a per-user level. This also lets you know which retainer belongs to which player, which de-anonymizes the market board to a great extent and opens the door to harassment.

After the issue was ignored for a long while, originally a statement was made here, basically asking them to kindly stop.
This, of course, did nothing, and there was the outcry that the issue was at a system level. Because it is. So in a Live Letter leading up to 7.2, they announced that they would be implementing measures... for 7.2. Which was still like a month away. People weren't happy with it, but hey, atleast they were doing something, right?

Fast forward to 7.2's release. They delete everyone's blacklist to accomodate for the new system. In reality, all they ended up doing was adding an obfuscation layer to the unique identifier, which was broken within 24 hours. The problem is that this is being handled client side at all, which many users commented on at the time as being the worst possible implementation possible. So the obfuscation layer is fully cracked, the tool updated, and we're basically right back to where we started.

As for what this means; it means there's a database that keeps track of who you are across all your characters and retainers, which can be used very easily for cyberstalking :)

---

Day by day it appears that it's not incompetence. They did the minimum effort possible because they want to spend only 10 minutes on this to appease everyone and hope everyone forgets. Will the community let SE get away with this? Who knows.

https://youtu.be/_2IY2In9VxQ

Have they said anything yet?
They gonna fix it?

Quote:

---

Originally Posted by Gurgeh

https://youtu.be/_2IY2In9VxQ

Have they said anything yet?
They gonna fix it?

---

They'd prefer to delete threads that point out how badly they failed.

Hello?! I'm...

...still waiting...

...with the...

...last dying...

...breath of my sub.
I'm still here.
Anything?

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

https://c.tenor.com/QLbV11ltA8cAAAAd/tenor.gif

Quote:

---

Originally Posted by Kazuke_Miso

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)

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.

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.

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.

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.

Quote:

---

Originally Posted by PotatoePet

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.

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by Gurgeh

...

---

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

Quote:

---

Originally Posted by Gurgeh

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

Quote:

---

Originally Posted by Exmo

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.

Quote:

---

Originally Posted by PotatoePet

.
...
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...

Blocklist didn't need increasing to 1000. Only people who need that many blocks are people miss using it to block every player who fails to reach progpoint second pull, or are going out of their deviant way to attract the attention of deviants. Please don't waste resources on that SQX. It's an unnecessary 'change' that solves a totally different non- problem.
A problem that somewhere there is already an add-on for I'm sure. Don't choose helping the progliar-paranoics to be the issue you actually decide to fix in the vanilla game rather than leaving to the add-on the community.
Come on add-on community. Isn't it time you created an add-on that:
-checked all the PF results
-interogated who is in the PF the moment
-looked then up and flagged an alert for any on your blocklist (account wise)
-also checked with a crowd maintained public shamelist
-used ai to interpret the PF description and do any auto check against fflog progress analyser

Let's go full psycho-toxic!
PROG! PROG! PROG! PROG!
IT'S ALL ABOUT THE OPTIMAL PROG!

The dangers of day drinking

Also, this privacy issue still hasn't been fixed.
I'm not even going to bother asking about X-DC PF.

Will this be mentioned in the Live Letter?
We'll find out!

Quote:

---

Originally Posted by Rin_Sato

Will this be mentioned in the Live Letter?
We'll find out!

---

Enough people have forgotten about it or believe that their "fix" actually accomplished anything that it's no longer a fire they need to put out, so it'll go unmentioned.

the persecution complex of bad players in PF feeling bullied for being kicked and blocked for underperforming sure is staggering

That last time I heard anything about this is some reddit talking about how the owner that that tool have already received a "cease and desist" officially. How true that was, I dunno.

The fact however remains that the security flaw seems to be unchanging. It's only a matter of time before another one took their place (or already is, we're just unaware).

As long as they don't make a true fix that stop sending account number identifier through the client, there will only be PS 2.0, 3.0 etc popping out very soon. Just because you stop the 1st one it doesn't mean you get to be invulnerable. People who have more than a braincell wouldn't go happy all jolly