As a Roblox developer, it is currently too hard to rely on TouchTransmitters securely as they are riddled with issues. TouchTransmitters (and in a lot of ways, Roblox physics itself, but that’s not related to this request) are still very much geared towards Roblox before FilteringEnabled, and I feel require some changes.
If Roblox is able to address this issue, it would improve my development experience because it would improve the security and reliability of Touched events.
Currently TouchTransmitters have the following behaviour, which I feel to be very undesirable:
The client can invoke touches for parts extremely far away from themselves. I feel that Roblox should employ their own checks for this rather than developers as many developers do not know to do this in the first place, how to do this, and nor do many developers want to do this themselves anyway. Even Roblox’s own items, including most, if not all sword tools suffer from this and allow an exploiter to trigger touches to the sword Handle for anyone in the game, no matter how far. DoomSpire Brickbattle, SOFTH, and Catalog Heaven are classic examples of where this has been frequently abused.
The client can invoke touches for anchored parts, and parts they do not even have network ownership of. If one part is not owned by the client who is sending the touch, it should be ignored by the server. The server should simulate all touches for server owned parts, and should only authorize touches between two clients where the two objects are likely to be able to collide.
Sometimes it is even impossible to employ distance checks from a developer standpoint because objects are so large simply checking distances cannot work, and because developers don’t have the tools to do these checks, often times they must use arguably hacky solutions such as using GetTouchingParts on a scaled up version of an object, performing different raycasts, etc.
I feel that this post, posted by @Shedletsky, is very clear evidence that TouchTransmitters are not very well understood among most developers, and their security quirks can be quite discouraging/hacky to work around. They do not really follow the rules of FilteringEnabled, and are the cause of many bad exploits which you would never expect.
I agree that Touched Events need to be modernized to fit modern day security standards. It’s almost too easy for the client to spoof touches to the server when roblox just accepts them all as valid. This has required many developers to go out of their way developing their own touch detection or verification systems because Touched events end up being unreliable and a major security flaw if their validity isn’t checked.
Many developers don’t expect problems like this occurring because they are following FilteringEnabled rules and expect that roblox would do the same. This leaves many games vulnerable to all sorts of exploits that shouldn’t be expected to occur.
If roblox were to implement their own verification to make sure touches are valid, it would save developers a great deal of time implementing their own security to verify these events, not to mention saving new developers from spending hours at their computer trying to figure out how their game is still getting exploited. The current standard with FilteringEnabled has left many aspects of the roblox API behind in terms of security, and roblox needs to do their part to update old tech to adhere with the rules of FilteringEnabled.
To solve the problem of .Touched exploits is to also solve the problem of exploiting of parts (eg. teleporting) that have client network ownership - I don’t think there would be a difference in solving just one… Actually having a “strict humanoid class” with more constrained behaviours (speed changes & velocity boosts only possible when issued server-side, no possibility to fling or trip) and server authentification for speed, flight and wall clipping would be a godsend for Roblox action games. Sadly I’m coding these features myself - It’s not that hard to implement in Lua either and I’m surprised there’s no open source project for this yet
This would also involve changing the effect the client can have on their own character. This may be problematic however, as the easiest way to reduce the issue is probably to simply deny LocalScript’s access to the Player Character full stop.
To be honest, its questionable as to why things like the Health and speed are handled on the client anyway - especially regeneration of health, as usually to damage the client you use :TakeDamage through a server script to visualize it to everyone.
Guess it can be useful for animations though, even though you could probably use the server as a midpoint to run animations on your Player Character
Well, this is sort of true, but also sort of not true. The client does not actually have to move parts on the server to cause these touches, they simply have the ability to fire touches in the first place, so having a distance check fixes this issue. I mentioned in the linked post that I created a post talking about how I prevent teleportation/movement exploits. If touches were sanitized by Roblox, this would be perfect for me as I never have to go beyond preventing movement issues.
Additionally, I honestly agree so much with what you’ve said. Roblox is actually implementing Humanoids entirely in lua now, and we even have demo code from the Avatar Evolution build (I highly recommend looking it up and messing with the code, it’s quite cool!). This is a great step towards this as we would be able to make and publish these modifications all on our own where Roblox may disagree with putting in resources for something like this.
Also, here’s the most complicated movement anti exploit I’ve ever done: FilteringEnabled - Character Physics Edition - Roblox
I’ve just uncopylocked it if you’d like to take a look at how it works. It’s quite hacky, but from my testing it works in most situations, and all player movement is done completely server sided.
It is assumed that the client can do anything on it’s scope, so we’re only left with what the client can replicate. Roblox gives us the freedom of full client network ownership for parts - roblox developer implementations of it are very intuitive and straightforward… At a great price. Roblox API level Server-side constraints for maximum velocities, grounded (and gravity) checks and clipping checks on client-owned parts could go pretty far imo
To be honest, a way of getting the Client’s view of a value might also be useful - that way if the client makes a change to a property of the Player on the client its automatically sent to the server without the need for a watching script (which they could easily delete).
A lot of the time most of the anti exploits rely on client defences for the most basic thing. In my most recent stuff I’ve created a security module which essentially makes every script rely on its values so its relatively impossible to delete the security script without messing up the entirety of the game.
Well, the issue with this proposal is that exploits will simply start spoofing these responses. While your script is “relatively impossible to delete” its still not difficult to do such a thing, not to mention exploiters can already spoof properties, humanoid states, etc, and even overwrite functions entirely without changing their tostring result.
