Overview

ROBLOX has released a new, optional filter that will prevent almost all forms of exploiting. However, this filter will require developers to rewrite many of their scripts to properly handle server->client communication.

Trusting the Client

ROBLOX gives an incredible amount of freedom to game developers to create anything they can imagine. The complexities and intricacies of multiplayer networking and replication are hidden behind a deceptively simple data model. This allows younger users to jump right into game development without prerequisite knowledge.

However, the game’s security model has a fundamental flaw — it gives clients too much power. Clients can tell the server to change properties and add or delete objects, and the server obeys. This is why exploiting is so rampant and widespread.

In most online games, clients are restricted in the actions that they can perform. For example, in Halo, the client can only tell the server which direction he is moving in, and when he presses any buttons. The server verifies that the user has bullets left to fire, manages the raycasting of bullets, deals damage if needed, and keeps track of the player’s position.

ROBLOX is the exact opposite. Clients have the freedom to create, delete, or modify almost any object in the game. A player can change his health, position, and walkspeed on a whim, and the server will accept the changes. If he asks the server to destroy every object in the workspace, it will comply.

The Solution

ROBLOX added a new property to the game client on February 6th.

Workspace.FilteringEnabled

When set to true, this property severely limits the access the client has to the game server. Changes that the clients make will no longer replicate to the server. Because this filtering will break most existing games, it is set to false by default, and can be optionally enabled by the place creator.

NOTE: This property is not visible in the property window in Studio. It can be set with the command bar or from a server-side script. It also does not save along with your place file, so if you want to test it in online mode, you will need to have a server script that sets it when the game begins.

When the property is set to true:

Local scripts are unable to set properties or create/delete instances. There are a few exceptions to this rule:

• Local scripts can do anything inside of PlayerGui.
• Local scripts can call RemoteFunction:InvokeServer and RemoteEvent:FireServer.
• A handful of property changes are whitelisted because they are set internally by the client (VehicleSeat.Steer/Throttle and Humanoid.Jump)

PlayerGui objects do not replicate to the server. They only exist on the client. Server scripts no longer run in PlayerGui, so all GUI scripts will need to be local scripts.

This enforces a proper separation between client and server. GUIs will be managed purely by local scripts, and when they need to talk with the server, they will need to call RemoteFunctions or fire RemoteEvents.

For example, if your game includes a GUI with a respawn button, the local script will wait for the button to be pressed, and then call a RemoteFunction to let the server know that the player wants to respawn. The server would then call Player:LoadCharacter() to complete the process. If the client were to call Player:LoadCharacter() directly, the server would ignore the request.

Speed hacking will still be possible

Even with the filter enabled, users will be able to speed hack or teleport to move around levels at faster speeds, because player movement is a part of the physics pipeline and isn’t governed by the same rules as normal properties. This is a slight downside, but we will be able to write server-side scripts that detect and ban speed exploiters. All other forms of exploiting will be prevented by default, as long as your server scripts are written securely.