Anti-RMT suggestion: improved rate limiting for /tell
Recently there have been a lot of suggestions shared by players for improving the situation of RMT spam. Some of these suggestions are very good, and I hope SE is reading them. I would like to suggest another one.
FINAL FANTASY XIV(R) currently implements a rate limit on /tells sent by a player, one which I certainly hope is enforced server-side. This current rate limit seems insufficient to prevent large-scale spamming of users; it has been reported that miscreants have been able to spam entire worlds with a single character. Tightening this rate limit would negatively affect some legitimate players who use it to chat with friends and may be very quickly sending lots of short messages like "hmm?" and "omggg i got zeta" and "oh rly?" to one friend.
SE may want to look into limiting the number of unique /tell recipients per time window. For example, allowing players to send a /tell to no more than 16 different players per 2 minutes. This is enough to allow a zealous FC recruiter to send random people a /tell about every 8 seconds. This kind of recipient limit, initially set to a smaller limit if needed, could slow down the bots enough so they can be caught before too many messages are sent.
Here is an example of how I would implement this:
Code:
Each active player session maintains in memory a list of the most recent 16 players that a /tell was sent to, along with a timestamp for each player that received a /tell. E.g. the target's character ID or session ID (targetID), and Unix time or FFXIV internal server clock (timestamp).
Whenever a tell is sent:
Go through the list once and look to see if the target ID is already there
If the target ID is already in the list: Permit the message.
If the target ID is NOT in the list: Go through the list again and check the timestamps.
If you see an entry older than the expiration time, remove the expired entry, replace that entry with the current target ID and system time, and permit the message.
If you have looked through the whole list and no entries have passed the expiration time, refuse the /tell message and inform the client that it needs to wait.
Memory usage: If we allocate 32 bits (the size of an IPv4 address) to the target ID and 32 bits to the Unix timestamp, each pair takes 8 bytes, and a pool of 16 "tell allowances" uses 128 bytes per active session.
Operation speed: For a pool of 16 allowed targets, approximately 32 comparison operations.
Computational and development resources may be constrained, so care was taken to make sure that this suggestion was simple and operated efficiently. I'm keeping in mind that each hour spent by software developers, each kilobyte of memory or processor cycle used, takes away from creating other features we want (like cross-server friends list!).
Other considerations: - Assuming the list is discarded on logout, expiration time should be short enough so spammers cannot rapidly logout and login to reset the rate limit, or, initialize the timestamp list with a small delay on login (time+1s, time+2s, time+5s...)
- If /tell becomes sufficiently protected, gold sellers may move on to shouts and yells. Fortunately, messaging volume on these channels are probably lower and easier to log. This is where you put in a database log on all shouts and the right-click Report Spam option that has been widely suggested.
- To determine the appropriate limits, developers can insert instrumentation to capture usage stats before turning on the restriction. Instead of blocking when the limit is reached, messages are permitted and silently logged. Adjust the limit up and down until very few legitimate messages are blocked, then turn on the message blocking.
- Limits on communication can be adjusted based on player reputation, for example, 4 /tell targets per 2 minutes for new accounts and 16 /tell targets per 2 minutes for accounts with 30 days tenure. Many have suggested using checking player level or requiring a quest, however this approach is unlikely to be effective. As many players have mentioned, there are bots that will do quests and level up. Actual elapsed subscription time might be a better idea: 30 days is usually enough to catch stolen credit cards, and if spammers buying their copies, they will have to pay for the copy and one month of time since the trial will have run out. (Any measurements of player level or tenure will not however catch the use of high level stolen accounts.)