Hello Developers and fellow text filtering users,
Soon we will be deprecating the use of Chat:FilterStringAsync and Chat:FilterForBroadcast from LocalScripts.
Calling these methods from server-side Scripts is still valid and will not be deprecated. Personally, I would recommend using the new TextService:FilterStringAsync API for new work.
We don’t have a set date for disabling support for text filtering from LocalScripts at this time. We’ll be evaluating how often this is actively used and working with developers to update their games before we have discussions about setting a date for disabling the feature.
Why are we deprecating text filtering from LocalScripts?
Even though supporting these text filtering methods from LocalScripts did make scripting easier in some cases because you could call it anywhere in your scripts without worry, there is a number of issues with it that led us to the decision to deprecate this usage.
- Hidden redundant round trips: Filtering from client works by sending the text to the game server and waiting for the server to filter the text and send it back to the client. In most cases I’ve seen in scripts the client immediately sends the filtered text right back to the server. In these cases it would be more efficient to send the original unfiltered text to the server once, then filter it on the server and process it without any extra round trips. This redundancy is hidden from the developer.
-
It supports bad usage patterns that we don’t want to support
- Trusting the client and not filtering on server: This supports the use case of filtering on client, then sending “filtered” text to server and assuming that the client already filtered it. If the server doesn’t redundantly “re” filter the text it is trusting the client to have filtered the text, which is potentially exploitable.
- Filtering on client receive: This supports the use case of the server broadcasting the unfiltered text to clients and then filtering the text on each receiving client. To protect user’s privacy you should never transmit unfiltered text to other clients, even if it cannot be accessed without exploits. There’s also the hidden redundant round trip for each receiver.
-
Difficult to maintain: The internal C++ plumbing to support text filtering requests from local scripts is complex. It’s nontrivial to test and maintain as we make changes to text filtering and chat privacy, as well as requiring many bug fixes:
- Currently always picks the most strictly filtered version of the text in all cases. There’s not an easy way to fix this.
Will this affect my game?
Only if you are calling FilterStringAsync from a LocalScript or a module script function invoked by a LocalScript on the client.
I was using this. What do I do now?
The quick-fix replacement is wrapping FilterStringAsync up in a Lua remote function. This is very easy to do, and also has the benefit of not hiding the extra round trip to the server from you.
Thanks for your understanding! Let us know if you have any questions.