Currently users are somehow able to spoof data into the ranking with no ability to remove/fix it.
For example currently the rank 1 of Grobbulus-NA Alliance is listed as "All of "
with 420k honor and 133337 RP,

They're hacking the HonorSpy code to broadcast false information on the sync channel. They're not doing anything wrong, per se, it's just not nice. It may be possible to build a blacklist feature into HonorSpy, so if someone know's exactly who is being malicious, they can add them to the blacklist, and their client would ignore broadcasts from that character. However, the way the HonorSpy code works, it seems that other people, who do not have them blacklisted, could still propagate the false information.

You could potentially create a feature that would remove them from the standings list, and remember who was being removed, but in this case they are not even using the name of a real player and could potentially just keep changing the name of who's on the list.

It may be possible to verify that the names on the standing list are real characters, but that would potentially involve querying each name that gets submitted which would cause mass query spamming, and opens the door for real exploitation.

I think the best thing to do, in this case, is just ignore the phony data.

An extra Tab with ignored Values and Broadcasters would be nice.
The "Next Week Rank" feature is pretty nice to see if you make the cutoff but the spoofing destroys it.

@jesse-greathouse thanx for your commentary, thats exactly what I was thinking.
Sadly, there is no way to check for specific playername to exists on the server.
Thats why the best what we all can do, is just to ignore it.

Probably I can add "remove" feature locally, but not sure how many ppl will use that.

my concern is that next week there is going to be 100 entries like this on my realm and that's going to make honorspy worthless all it takes is for 1 more person to figure it out and the troll war begins

I did implemented a little bit of filtering for special symbols in player names. but that's nothing.
Lets see where it will come first. If its going to be more than couple of kiddies trolling, then I probably implement local row remove feature.

You can require two votes for players above a certain standing. It stands to reason that in order for a player to be above a certain point, a player has to be playing quite a lot. If someone is playing quite a lot, you should certainly see him appear in at least two player's shared data. Additionally, this could be bypassed if said player has the addon installed. Until a player above this arbitrary standing is seen twice, he is tracked in a separate table that is included in the payload when the database is shared. Include collection of the players GUID to add an extra layer of required coordination between two bad actors.

You may also consider adding constraints to RP, rank, and standing.

Why you want to guard top players and allow any lower ranker? Both of this table parts are equally meaningful, so any type of consensus should apply to the whole table.
But consensus is not an option here, since we have many players with enough HKs that was only spotted by one addon user.

Checking unrealistic values is possible, if we can find universal algorithm to estimate lower and upper bounds for all columns.

Yes, the simplicity is what I aim for. Starting this endless war with script-kiddies can just do more harm than profit to all of us.
Note for future readers: I considered many approaches how can we eliminate this "bad" data, and all of them brought me to dead ends or super complex solutions. There are no feasible ways of checking for the existence of specific player names, neither we can reach any consensus on "correct" distributed database state.

Checking unrealistic values is possible, if we can find universal algorithm to estimate lower and upper bounds for all columns.

I don't think this is a bad idea, in theory, but I think any such algorithm will be exploitable. The thing I'm worried about is not the obvious person hacking the standings, but a more insidious falsification of the system where it's not transparent what is happening.

For instance, if any algorithm were to dynamically determine what the upper end and the lower end of the range should be, a clever hacker would pad the middle of the range with a dynamic number of fake entries, to expand the range on the upper and lower. I think our Clover Club hackers may not be sophisticated enough to figure this out, however someone who is sophisticated, could be hacking the system and no one would realize why their numbers are skewed.

At the end of the day, this makes very little difference so I don't have any desire to change or not change either way. But I agree with taking time to see if this problem even becomes a big issue, because right now it's not really effecting the community all that much. Adding smartness of this nature is going to be a big burden for any one person to take on. Ideally it would require a lot of testing to get right, and such testing is extremely difficult to do. I think your addon is brilliant @kakysha, but I don't envy the idea of adding this much complication to it. It sounds really hard to get right.

I suggested a solution that places different safeguards on high and low ladder positions because the people spoofing are doing it for attention, thus want to be on top, and consensus is possible at such a high ladder position. It is impossible for someone legitimately # 1 on the ladder to only be seen by one addon.

The only malicious activity that my strategy does not prevent is spoofing hundreds of entries low in the table to affect the size of the ranked pool, and thus brackets. However, the current solution (none), also has this issue. Consensus can help keep the ladder accurate near the top where the heaviest power users are.

How will you count "seen" times in one's addon?
What can prevent a malicious person to create 10 characters and resend same bad data from all of them, so other players would think it was seen 10 times?

As mentioned in my twitch message @kakysha I have a few suggestions that may hopefully help mitigate some of these issues:

Create a cap to the Ranking points at 100,000.
Create a character limit of the max characters that can be used in a name. I believe it is 14 or 16.
Create a function to remove entry ranges. (For example: on my server ranges 1- 1986 are filled with fake characters and data)
-OR-
If the player's name was logged to remove and ignore all further entries from

obviously this will not 100% fix the issue, however it will make it way more restricting. Hopefully some of these help, and if I can think of any other ideas I will share here or on twitch.

["RP"] = 1234567890, <--- not sure if there is an actual cap, but this number is not obtainable now.
["class"] = "DRUID",
["last_checked"] = 1575141695,
["lastWeekHonor"] = 123456789, <--- would set hard cap of 500k-1m
["standing"] = 1, <--- only 1 player can be in the identical standing i believe, but maybe no > 2?
["unitID"] = "player",
["rankProgress"] = 0,
["thisWeekHonor"] = 1.0e+34, <----- Force whole numbers & hard cap of 500k-1m
["rank"] = 16, <---- As far as I know there can only be 1 GM/HWL, would set a limit on that.

Just some more thoughts.

Setting limits won't prevent hackers of creating 1000 "valid numbers". They won't be at the top, but still be in the table. No difference.
"Remove entries" button won't fix your table either, as malicious person can create 500 entries that look valid to you and you won't even know that such players do not exist.
As I said before, its a cats and mice game, in which there is no guaranteed way of defending against it. I don't want to overcimplicate addon, just to make "spoofing" a bit harder.

encrypt data tables so that they cannot easily be messed with? I mean someone can reverse engineer that too, but not just your average player.

could scan /who for all the names that will be updated into everyone's list on dead.

Querying people's names via /who is rate-limited to 1 name per 5 seconds. You can test this by creating a macro with /who [name]. You can spam it as much as you want but it will only return a result every 5 seconds. If you do it with multiple names it will only return the first name.

The idea of doing this was previously discussed, in the beginning of this thread, last week. If you can figure a way around the technical limitations of doing this, and submitting a pull request for it, I can't speak for @kakysha but personally I would be interested in seeing it.

Anything is better than what i just did going line-for-line scrubbing the whole list of fake and/or suspicious entries after setting it to sync over guild and logging out.
I'll keep brainstorming,
A setting that can choose to only sync data for names that you have already seen and specifically update the data for those names, without adding new name entries would prevent spoof names, but it would not prevent people from editing data for names that are already known unless you could opt out of syncing altogether.

Thats why I posted a note for future readers before closing this:
Note for future readers: I considered many approaches how can we eliminate this "bad" data, and all of them brought me to dead ends or super complex solutions.

Possible to vaidate player true/false via /who function?

could scan /who for all the names that will be updated into everyone's list on dead. if those names are not online, it doesnt push the data. sure some of the data will be lost, but it wont be able to push fake data if it cant get past an "online" check.

@kakysha
Another thought came to me. And I think this may be your fix.
If you can log the character name of the player who sent info updates through chat, you could add a feature to ignore all info from "player name" so it would delete any info they sent and prevent future info from that same player. logic being, you could see who sent the erronius info and block any info from that player.

Example, if xjkeldfgoxh sent data to everyone on the server, their info would be tagged with the name, regardless of how the data was aquired.
So if Monster sent data to everyone on the server because they are using the HonorSpy without malicious intent, but they have the data from xjkeldfgoxh who is a malicious dbag, xjkeldfgoxh would have the data tag, so when you ignore them, any info that Monster sent would still be sent, but xjkeldfgoxh's data would be ignored.

And then Monster decides to become bad guy also, changes the "data tag" of bad rows from "xjkeldfgoxh" to "toatllyagoodplayer" and voila - everyone accepts this bad data thinking it came from good guy.

Right, but then you just add toatllyyagoodplayer to ignore and all the data tagged from that guy is excluded from the data set as well.

And them Monster decides to replace toatllyyagoodplayer with every player name from his server, and eventually the whole server get banned.

its a possibility, but its better than having an addon that no one wants to use because its filled with thousands of lines of fake data. or have the ignore list reset every tuesday with the honor reset.

i see the fix i suggest as being a massive deterrant because it would be so time consuming for people to fake data. They are looking for low effort means to fake the data. going in and indivually adding actual player names would take them days to months worth of effort, and by that time the honor would reset. You could also add a feature that removes all data that is older than 3 days old, chances are after 3 days of not logging in either the data is fake or that person will not be pushing honor, and if they log in on the 4th day, they will be re-added.

implementing an "ignore" feature means that there is one more dropdown menu, a separate GUI to add / delete / modify this "ignore" list, and this also means that if malicious person generates 1000 bad rows with 1000 random authors for each row, every player then should click each of this 1000 rows and click "ignore", as it's authors differerent for every row.

And no, it won't take days or months to ban the whole server. Ppl already generate fake data using scripts. It takes 5 minutes to get real player names from addon database and paste them into fake data's author column

well, I thought it would be helpful to share my ideas on how to fix or at least partially fix the problem. I havent dabbled with any scripting in many years, as i used to mess around trying to make things better, but have lost most of that knowledge. I know that there is 2 courses of action that you as the dev can make. either adapt and overcome, or just let it happen and see your creation lose relevance.

Love the addon but unless something is done to prevent this it's basically useless. Soon as people noticed how easy it was to manipulate the data on my server suddenly there's nearly 100 and counting bunk entries. I understand that the creator probably doesn't have a ton of time, but maybe just delist the addon if nothing is going to be done about it. It's mostly worthless atm.

wouldnt that just make it extremely easy for a troll level 1 character to set their honor to whatever they want? Basically handing the tools to trolls to kill this addon...

I've got some ideas.
Label source of each record into 3 types.

1. [self] data inspected by yourself (where INSPECT_HONOR_UPDATE does)
   always correct since they are received directly from server
2. [guild] data received from guild channel
   almost trustable if you can trust your guild
3. [public] data received from public channel (yell, raid, instance chat...)
   not that trustable but lets keep it anyway

Then OnCommReceive should behave like

1. when receive messages from guild, records which labeled [self] will be labeled as [guild] instead, others keep the same
2. when receive messages from public, all records received will be labeled as [public]

Finally, the honor table can display data from 3 different data sets which we can select now.

1. [self]
2. [self] + [guild]
3. [self] + [guild] + [public]

theres a dude trolling me on my server thats altering the tables, he suggested using GUID?

also a quickfix to receive comms from other players (comes from Mired Hunter on Arugal PvP) open honorspy.lua in the addon folder, find the line "function HonorSpy:OnCommReceive(prefix, message, distribution, sender)" delete everything thereafter up until the functions end (include end). restart your game and clear your tables, now all the data will only be received from mouseover? and not from player broadcasts (its a slower table acquisition but prevents spoofing)

Hi, i have fixed this issue and sent you a message on curse on the ideas i had.
How i fixed it was: every data you recieve is added but tagged as confirmed=false.

If you however see the player yourself (mouseover inspect) then they are considered confirmed and gets confirmed=true,

If 50 people share to you the same player then they are also considered confirmed and gets confirmed=true.

and only players what have confirmed=true are displayd and counted towards brackets.

by doing this someone who wants to mess with the data will be forced to make 50 alts and with each of them get guild invite or go to a BG or die close to other players.
so yea it can still be faked but its ALOT harder, as the validation is done for each person locally.
(you only broadcast data that you consider confirmed aswell)

It means the adding of new data will be slower but after 1 day it should be pretty fine anyway.
I've also thought about "whitelisting" your own guildmates so that all data you get ABOUT them you consider confirmed aswell (as you know its a real player for sure).
Do not make it so all data from them is confirmed however, as then it would be easy for 1 person in a big guild to spoof data, then have all guildies spread the spoofed data and we would be back to square 1.

here is the code with my changes:
honorspy.lua : https://paste.ubuntu.com/p/gQfrK9ZSds/
GUI.lua : https://paste.ubuntu.com/p/h5MCtzpqnj/
(ps. this is my first time writing lua so i'm guessing you can do it alot cleaner and better than me, but it works atleast)
if you decide to use this please just add a credit to Leomage-Earthshaker EU :)

If 50 people share to you the same player then they are also considered confirmed and gets confirmed=true.

I'm assuming this would only work if people (or honorspy itself) would delete all the data, otherwise everyone would share the fake entries which would confirm them(?)

If 50 people share to you the same player then they are also considered confirmed and gets confirmed=true.

I'm assuming this would only work if people (or honorspy itself) would delete all the data, otherwise everyone would share the fake entries which would confirm them(?)

If I understand correctly all data is false by default and to verify it you actually have to see that person in game and then he has to be seen by whatever amount of people the threshhold is set to. Since those fake entries are not real characters they will not be shared no.

The issue I have found using this now for around 14h is that it syncs super slow even with the threshold set to 1 and having 4 people using it. It also doesnt seem to sync retroactively but only syncs data to people who are online at the same time but not whatever you have found while they were offline. Perhaps that's just from the low amount of people using it idk.

How about instead of having to hover over someone to confirm them, you'd do a /who request to see if they're online, confirming them. I haven't used /who requests in addons before so maybe someone else would know if this could work or not.

I'm still not sure though how you would confirm that the honor that is being shared is correct.

well any time you die it should send your entire db (that is confirmed).
and yea, seeing as it works by inspecting it makes the update work exponentionaly.
and if we can set all "known names" like people from your own guild to be auto confirmed as we know those are real players this will help ALOT as they will help to confirm eachother faster.

another thing i saw i had missed was that it only updates if the new last seen is newer than the old one, so people need to see you in order, i have done some tweaks so that old data still counts towards the seen count, but not updating the actual data

another thing i saw i had missed was that it only updates if the new last seen is newer than the old one, so people need to see you in order, i have done some tweaks so that old data still counts towards the seen count, but not updating the actual data

This would explain why its so slow! Please share the fix :)

ok so here's the new honorspy.lua file https://paste.ubuntu.com/p/nnpWzmMhCJ/

if you check at the top on line 12 you see

local requiredForConfirm = 8;

This is the amount of people who needs to share the same name before its considered confirmed (ofc seeing them yourself instantly confirms them)
When trying it out with only a few people then you might have it low, but with many people using the addon this should be high, this is basically what configures how hard it is to spoof the data...
lower numer = people are added to table faster but easier to fake.
high number = slow to add people to table but harder to fake.

I have also playd around with the idea of "trusted people", with this i am thinking to let you add players you trust to not fake data, then ALL their shared info will automatically be set as confirmed, because we trust them, this is kind of like what i said before about guild, but as its not automatic it would still make it harder to abuse as you would need people to add you on it if you wanted to fake.

Pls, make a proper Pull Request, don't share code using pastebin.
This solution, howerer, sounds doubtful to me, as the number of players that were "seen" by 50 players, or even 10 players, are actually very low (only the top brackets who actively play and always online).
Instead of just having overpopulated pools with fake entries, you will have much smaller pools than it is in fact.

nah, not sure how its on your servers, but on my server the is a TON of people, and prettymuch everyone uses honorspy. so it would take like 4 hours of you going in and out of bgs in a major city before 50 people have seen you. also this number can ofc be lowered.

You could set the limit to 10 people, but then check the level of the player sharing the data.
require it to be lvl 15+ for example and the person who want to fake data needs to make 10 alts, level them above lvl 15 then go and die in close proximity to 10+ people ( same people for every alt).
so it can still be faked, but would require ALOT more work.

besides in 1 MC raid you will have been seen by atleast 20 people (from your guild).
you could also have so when someone gets confirmed they get added to a seperate whitelist that persist through resets, so consecutive weeks they dont need to get seen by 50 people again.

@Kristoferhh you cant for sure, BUT seeing as it has to be a real person, faked data will get overwritten with propper data next time someone sees the player, so faked data should only last for afew hours before getting fixed again automatically

Using the beta you have. I get a bit laggy to...game stutters, I doubt it has anything todo with ASCII symbols it appears to me its because its adding 100000 people and then removing them???
https://puu.sh/ESzYL/36baa294d6.png
Goes on for about 5 or more minutes

@ramboozer you should not see any ".. added to friends" messages. Thanks for reporting, I'll try to hunt this down.

Awesome, as you can see I showed you what I saw in the screenshot from Puu.sh. However it does appear to also be deleting all the false data

can you guys test latest commit https://github.com/kakysha/HonorSpy/archive/classic.zip
It should remove fake entries now.
I check for players existence using friends system. Need more testing, as the whole idea is a bit-hacky, again.

Laggy as fk while it's deleting :p but it seems to be working, so good job 👍

@Kristoferhh What do you mean by laggy?

I realize now that it's most likely lagging because the fake players' names are all random ascii symbols (at least on my server), so printing the name in chat makes the game freeze for half a second.

So on my server someone has flooded the brackets with "W????????????????????????????" characters. With the version you posted here it scrubs most of them but some of them seems to get through. Also my client is constantly lagging/Freezing/stuttering when its trying to clear these 2k fake entries. It also doesnt seem to scrub actual real players who reported fake honor gained on their real character as you can see in this screenshot by the #1 and #2 standing.

https://i.imgur.com/EQxWt9t.png

While this scrubbing is an improvement (99% of the "W??????..." were removed except 3) it still has critical issues.

Interesting idea, but im not sure the extra flooding of the API is that good of an idea, most servers have 15k players online at primetime, ALOT of them use honorspy, on my server we have a standing table of about 30k people because of all the fakes, going through this will be putting strain on the servers.

I think if you run with the idea i had just a lower threshold like 10 people needs to see you and the person sharing the data needs to be lvl 15+, then possibly also adding confirmed people to a whitelist so they are automatically accepted next week will be better.
With this many people on every server 10 people will see you by just running from AH to bank in IF, so it shouldn't take long at all for real people to be confirmed.

i spent ~10 min in SW and had already seen 200+ people

and even on lower pop servers it might take maby 1 extra day for 10 people to see you, but because of the whitelist that would still only be an issue for 1 day in the first week.

Imagine if you have 5 people running from ah in if to bank, they are seen by 1 person, he then broadcasts this over yell and guild channel, that means around 100 players will now do both add and remove friend request on each of thease, thats 5players * 2requests *100players, 1k requests to the API done in about a second, now imagine this happening all over the server all the time...

Your basically just making the addon into a giant ddos network.

So if you do like that you absolutly have to create a whitelist for real players that persist through the resets

there is a permanent whitelist if I'm reading this correctly, in the saved variables when a player is confirmed real

@leothlon "estimations" about load used to be wrong in about 100% of cases, at least in my experience. Only production testing can show you the real values. Also, there is a limit of 1 friend add/remove per second for each client.

Personally, can't reproduce any bugs by myself. If more ppl can test the linked above version and find any causes for lags / bugs, I'll gladly review them. Thanx.

@PQlse its impossible to clean fake data for real players, but this should not be a big problem anyway, say for example i would fake my honor at 12.00 and share this, then at 12.05 i go online to play some, a random player sees me in IF, he automatically inspects me, and as the data he gets is newer than the fake data i sent, the fake data will be replaced by real data.

So you would need to create a bunch of real chars fake their data then make sure to not log in on them

Ye about 2800 fake players were removed which is awesome but there's still about 30 of them left. I'm gonna try to find out why they're still there

Should just have used a password protected chat channel in game to communicate. Then you can moderate/ban as neccessary.

@Streamsnipe whats wrong in the current fake detections algo?

@Streamsnipe thta wont do anything as with the current setup you cant know who falsyfied data from the start, also addons are not allowed to communicate over global chat channels anymore since 1 patch back.

yeah that's dumb, i thought they only changed it so 1,2,3,4, channels were blocked as means of comms, and not custom chat channels. This addon as it stands is entirely broken and prone to manipulation

You can still spoof data if you create a lvl1 char and send fake data for this char. Or am I missing something? Then again there is probably no real fix.

@kakysha Currently anyone can broadcast to anyone. This allows spoofers to send data directly to someone and have it be integrated into the 'mainstream' of the db. Once its in the system its impossible to scrub. We need to create password protected groups and allow users to construct and create DBs with information provided from other trusted users. Friends lists do not work for obvious reasons. All db updates should come from whispers, and not guild messages/party/raid anymore.

If we allow users to create groups and set passwords, we can have them moderate their own lists. Unfortunately custom global channels would've been ideal for this but it has since been patched

@Streamsnipe again, asking for the 3rd time: why checking playernames by adding them to friends is not working, except the reason provided by @squallified?

Friends lists do not work for obvious reasons.

is not the answer I'm looking for

Because you do not know who spoofed the data. The person could be on your friends list. If someone on your friends list, or a friend of friend is spoofing then the database is still corrupted. Once its corrupted it propogates like a virus. Why is this hard to understand?

What are you even talking about? Are you a developer yourself? Did you read the code I pointed you out? This is not how it works.
Addon just adds players from the table, one by one, to your friend list. If player can be added successfully, then its a real one, otherwise its fake and should be removed.

You can spam as much fake data as you want, it will be purged from everyone's databases soon-ish.
Fake values for real players also are quickly replaced by honest players inspections.

There is currently a problem on Faerlina Horde side where the fake data being input is faster than the removal process. The only way I've found of fixing this, for me atleast, is to take the previous weeks databases and add every player seen to the 'good player' filter, and dump the rest into the 'fake player' filter. While not 100% it does give me a pretty accurate table. The only people who would be false flagged are those who haven't had an honor standing in the past three weeks.

The problem lies in this bit of code @ line 401:

if (distribution ~= "GUILD" and UnitRealmRelationship(sender) ~= 1) then

It appears someone changed the value to accept people from other realms into their database.

Currently there are more people being added, due to this person doing battlegrounds, than the removal feature can keep up with.

Another problem with this is that a lot of people on other realms share names with other people. It is not removing a lot of fake entries do to a character existing with that name actually on the server.

The only way to fix things like this is second party verification, no one person should be able to add to the database or these problems will continue. A second person should verify and then an entry can be added.

Also, self broadcasting your own honor should not be possible either. Another party should have to see you in order for yourself to be added to the database.

Lastly, if the database file in the saved variables folder cannot be obfuscated somehow, all of these changes are for naught. This file can be edited directly and used to change values as well.

"The only way to fix things like this is second party verification, no one person should be able to add to the database or these problems will continue. A second person should verify and then an entry can be added.

Also, self broadcasting your own honor should not be possible either. Another party should have to see you in order for yourself to be added to the database."

Yes, quoted for truth.

Agreed, and that issue would be solved with the solution i suggested, that would require more than 1 person sharing the same names (like 5+ atleast), when a player is confirmed add them to a permanent whitelist, that way people will be added confirmed superfast and easy, there realy wont be an issue where it takes to long to add people, be online for 10min a week and you are guaranteed to have been inspected by atleast 5 people. and ones people have their whitelists there will be no issue what so ever with people not getting added instantly

the solution i posted is ready to be rolled out, its without a whitelist tho but should be possible to add fast enough.

also you get rid of the risk that someone logs off in the middle of adding + removing someone and over time end up with afew people in their friendlist they dont even know

Just wondering. Is there a way to make a part of the code check for modifications of the .lua and deny it functinality ingame? Or would that check also be editable? Any way to have encrypted files somehow? Idk just brainstorming.

@Doodahdoodoo you might be able to check a checksum of the file, but i doubt it... either way that would also be editable as all wow plugins are unencrypted opensource.

the latest version you linked here works verry well kakysha, except for the risk i stated above about getting random people on your friendlist, and in those cases where there is a real char at like lvl 1 that share name with someone from other server (as on earthshaker-eu its the same problem as above where someone removed the check if data is from x-server or not to flood the database)

Is there any way for this addon to connect to an external MYSQL database? I see other addons have the ability to inform you if the version is out of date or not. I assume this is using the internet somehow to check. If the addon could send its data to a secure server and back out to clients would stop the people from editing in their own values. But Im not sure if the API for this game has that capability. As for hosting the server, im sure plenty of us would happily pay for a dedicated sql server.. Just more brainstorming sorry if annoying you xD

There is no way to do network requests. Other addons know about new versions just by receiving messages from other players with new version

I cba doing anything so complex like that. P2P, blockchain, distributed ledgers or any other consensus solutions will fix the problem totally 100%, but I will leave implementation of blockchain inside WoW addon to someone else crazy enough to even start thinking of that.

I don't plan anything else on this problem. Fake rows already got eliminated by "friends check", wrong values got fixed automatically by fair player inspects sooner or later.

HonorSpy heavily relies on community, it can be called "community-driven" in terms of data it is showing. There always be some smart guy who can fuck up all the data, this cats and mice game will never end. You can hope there is another honest smart guy who "fix" those tampers, like I do on my server across my faction I play for, when players ask me to do it.

Yes. You'd need blockchain. OR. A single master in game where everyone points to to get their list and that list can be controlled by them. (E.g they have the authority to remove entries/modify out the bad ones). The latter is an easier solution

This has been answered previously in this discussion actually:
#58 (comment)

Setting limits won't prevent hackers of creating 1000 "valid numbers". They won't be at the top, but still be in the table. No difference.
"Remove entries" button won't fix your table either, as malicious person can create 500 entries that look valid to you and you won't even know that such players do not exist.
As I said before, its a cats and mice game, in which there is no guaranteed way of defending against it. I don't want to overcimplicate addon, just to make "spoofing" a bit harder.

This is why you create a whitelist where the source of the information is controlled and not the data. I have no idea why this is so hard for people to understand here or why I've had to say it 4 times for people to understand.

1. Let there be a person who creates a table, become the owner of it, and can white list names who can broadcast entries into this table. They are whitelisted by the master and only whom the master trusts (E.g a guildmaster)
2. The person can see the source of all entries/all inputs to its DB because this app requires a message to be received from someone with a name.
3. The person can janitor their own DB.
4. Players who want to join the 'source' DB are invited by the master. They broadcast information to the master and also have the same whitelist as the master.
5. Suspicious information from a suspected player will have them removed from the whitelist and all will be filtered out from each subsequent player in the group as their copies are taken from the master list.

On arugal i get one or 2 of these guys at least every other week. Surely it wouldnt be hard to have a check for honor values this high that should be impossible to achieve normally. (everyone else only seems to go up to a max honor of 6 digits)

On arugal i get one or 2 of these guys at least every other week. Surely it wouldnt be hard to have a check for honor values this high that should be impossible to achieve normally. (everyone else only seems to go up to a max honor of 6 digits)

I have the same issue on my server. Keeps setting himself as 14 which is obviously not possible. I don't know how this effects the estimated calculations but it sure is annoying to see.

This is why you create a whitelist where the source of the information is controlled and not the data. I have no idea why this is so hard for people to understand here or why I've had to say it 4 times for people to understand.

I don't want to overcomplicate addon

If you want to implement some crazy complex syncing schemas with some "masters" people who control and push the data (which, obviously, won't work, as to cover the whole playerbase, you have to rely on as much data collectors as possible), go for it.