New filtering function request (Feedback systems)

[DevKurka]

Hello, Roblox Developers!

---

I saw a discussion saying about user input sent outside of roblox is meant to be filtered.
I’m especially talking about buildthomas’ post:

On another topic

Yes, technically if you send user input over the Discord hook, you will need to filter it.

When we ran a Discord webhook to receive in-game feedback (and we didn’t think to filter it yet), we used to get some messages like “if you want more ideas here is my…” followed by full phone numbers, full names, full email addresses from kids. So having to filter this stuff is genuinely important. I’m a good guy and removed that kind of messages, but someone else might not be such a good guy with this information.

What do I mean with that?
I suggest creating special filtering function which would work like Chat’s FilterStringForBroadcast function, but it won’t filter string to be safe for 13- children. I would just filter string like for 13+ people. This could secure Roblox user’s personal informations (like phone numbers according to buildthomas) and won’t tag the most of the sentence (like original function), which makes it unreadable. It wold be useful in case developers would want to make a feedback system only for themselves (such as Discord hooks). Something such as sender -> developer filter. Sadly… The normal filtering function (both 13- and 13+) accepts only player instances as arguments. If it would be possible to enter user ids there it would be surely easier, but I wonder it could be abused with filtering each user’s id and check does it equal to normal 13- / 13+ filtered string.

---

Sooo…
It’s hard for Roblox developers to secure user’s privacy in feedbacks system when you want to keep the message readable, but filtered…

---

I hope You will understand my request.
I can’t wait to hear your opinions about it.

Sincerely,
DevKurka.

[unix_system]

This would be abused as discussed before.

It’s impossible to establish if a user is >13 or <13, so in all cases except off-site exporting of data this would be useless (if not unsafe) - The purpose of FilterForBroadcast is to not discriminate between any age group or user and filter for the safest setting as the developer in these contexts has no control over who views the text. In the case of this however, it is safe to use FilterStringAsync.

[DevKurka]

It would be mainly made for the off-site exporting data for only developer’s usage. It still prevents users from sharing personal info and this is what it’s for. When you would use normal broadcast filter you wouldn’t be able to read even the sense of sentence. When you wouldn’t use any filter, people would be not safe. Kids can just get some stupid ideas to share their personal informations. So…
This function wouldn’t have got any other usage than exporting data for dev’s usage
You aren’t able to call FilterStringAsync on nil value…

[EchoReaper]

This would be abused as discussed before.

The way OP worded their request could be improved, but what they’re suggesting is reasonable. Based on the API, I’m assuming (I have no internal knowledge of the filter) that there are two types of filtering: outbound and inbound. Below are diagrams A, B, and C (from left to right):

Diagram A is the behavior of regular filtering. The outbound filter protects the sender’s PII/etc depending on how “innocent” they are. The inbound filter protects the receiver from profanity/etc depending on how “innocent” they are.

Diagram B displays the behavior of FilterForBroadcast. Since the receiver can be anyone (e.g. a 7-year-old), it has to use the most restrictive filter to be suitable for all ages. There is a lot of room for words to be filtered undesirably because the filter is so strict. Diagram C displays the behavior the OP is requesting: the ability to remove the inbound filter. Since the place owner would not need to be protected from profanity/etc, we could remove the inbound filter entirely. Depending on how strict/inaccurate it is, this could remove a significant amount of false positives.

Proposed Solution:

I don’t think removing the inbound filter entirely is a good idea. A 10-year-old could make a game and then be exposed to inappropriate content because their feedback system isn’t filtered. Instead of removing the inbound filter entirely (unsafe) or being forced to comply via FilterForBroadcast (tons of false positives), developers should be able to filter from sender -> developer. This would decrease the harshess of the inbound filter the older a developer is.

This is currently not possible because the filter methods require player instances for some reason. This could easily be rectified by allowing those arguments to be overloaded with UserIds – I’m not sure why they require player instances to begin with.

[DevKurka]

This is one of the solutions too. They can at least make it possible to filter user -> developer messages. The filtering based on user ids wouldn’t be safe too… There need to be other function for that.
Why wouldn’t it be safe enough?
Developer can scan the players by himself (he doesn’t even need them to join his game). Take an example of how text is filtered for 13- and for 13+ and he would be able to check the age then… Maybe it’s not that bad, but still… There is privacy danger.

[unix_system]

I agree, however this should probably just be a request for userIds.

Has anyone tested if it’s possible to fool the API by providing a generated userdata with username and userid properties?

[DevKurka]

Ye I have tested that… And about the user id filtering. It’s good way too, but I wonder can’t it be abused like I said before.

About the trying to fool API with userdata… Seriously?

[Autterfly]

The filter is (for obvious reasons) not handled on the Lua side. Fooling the system wouldn’t be possible if it’s explicitly asking for a player instance.
Lua newproxy userdata is flagged internally as different from C sided userdata created from the Lua C api.
My assumption as to why they do Instance instead of UserId is because the instance already contains a lot of (hidden) information that loads in with the user to adjust playability. So they’d likely end up making more than 1 request to the backend if they say were to use UserIds for filtering, as it would mean loading in any needed information.

[unix_system]

My reference to fooling the system means a developer may use a >13 FilterForBroadcast function when they should use the <13 version. This sort of discrepancy is difficult for staff to detect and can lead to the FilterForBroadcast function becoming fairly redundant.

[DevKurka]

It’s a way too, but exported data will be at 99% tagged…