As a Roblox developer, it is currently too hard to test that our games are resistant to the majority of exploits. We cannot test for vulnerabilities in a server, as the developer doesn’t have access to a client-side console to execute code.
To address this, Roblox could set up a sort of “White hat” group dedicated to this, of similar function to the QA tester group. Trusted members would be able to poke around in games suffering (losing revenue / players) from security flaws or exploiters, find vulnerabilities and report them to the developer.
Games that have undergone this could also receive some kind of seal of approval, marking it safe for players.
If games on the front page (for a minimum amount of time, say 4 consecutive days) were offered to be tested, then a lot of popular games would be secure and a lot less players would have to deal with exploiters.
Is this the right category? I was debating putting this in studio features but idek
This feels like something that’s good in theory, but incredibly difficult in practice. What happens when players freak out because they see someone exploiting a game, even if it is just for testing? What’s the process for getting your game tested? Is there a specific process that a white-hat has to follow? What’s the vetting process for hiring a white-hat?
I think that overall, it’s best to just have people from your own group try to break the game instead. Much less headache.
As Chipio said, it may sound good in theory - but I think that publicly supporting any form of exploiting is probably a bad idea on Roblox’s end. It could lead to an increase of black-hats and people out to find new ways to get through Roblox’s ever-increasing security.
As a white hat who operates outside of Roblox, I feel worried about becoming a white hat on Roblox given the threats of moderation actions.
In terms of those who freak out, testing should be done in a private and secure environment without causing harm and/or alarm.
In terms of processes, I stick to the code of ethics set out by the EC Council (Code Of Ethics | EC-Council) however some may have a different code and/or processes.
In terms of those who worry about the increase of black hats, that’s not an issue in my opinion. For the pen testing to be accurate it is important it works off the current enviroment and maybe even stop black hats at the same time.
In terms of getting your white hat, it’s important you look at history and create contracts so in the event things go bad, you have something to secure yourself.
In the end most exploiters are known as skids (script kiddies) [Hi V3rm] will try and attack the game and standard polices such as FE and proper Server-Client communication is important but a program like this will help with the dedicated people who try to attack the platform.
I’ll also say this, by disallowing pen testers you (in my opinion) will harm security by the fact that you do not have ways to legitimately sort out these issues.
I pose this question, would you rather have an exploit of your game be reported before or after it’s been released to the public?
Any sort of local testing can already be done with script interpreters and fully controlled by the game’s developer. I don’t see a point to this being some internal feature.
In all seriousness I don’t see how white hats could be seen as a bad thing. Its already so easy to exploit, might as well have some of the exploiters help make your game more secure.
This is a pretty good idea and could potentially work well if executed correctly.
White hats could be given a private testing server to test things to prevent alarm/game breaking from a public server, they could have some sort of invite link for alts/other white hats to join and test as well.
You could argue that you can test your game yourself with an in game script console etc. and that’s true, however exploiters have a higher context level and many custom functions that allow them to do much more than what a regular LocalScript could do, this is where white hats would come in handy, being able to test for the more advanced stuff you can’t find yourself.
Like others have said, the TOS is an issue here, however there’s always a possibility for change.
Okay no; I have to disagree. We already know it’s possible to spoof context levels via smart methods, so long as a second, higher context is present and running non Roblox code. This is probably more a security issue for the “white hat” than the game owner themselves, since calling something dangerous on their client is very well a possibility.
That’s a very true possibility, I don’t think something like that can be prevented but there could be some sort of report option for games that do something like that, doing so could remove a game’s eligibility for testing, or if it’s severe enough, possible deletion. (Just throwing ideas around here)
Also, depending on how the actual system works it could be available to certain devs/devforum members only, which would decrease the chance of that happening pretty greatly.
Of course at this point I’m just throwing ideas around for if the system actually ends up becoming a thing, there’s a low chance it’ll become a thing but there’s still a chance.
I mean, you can get someone’s authentication token from a higher context and slide it past some obfuscation and no one would ever know, so I’m not sure it’s really the best idea. Just my look on it though.
Yeah I’m aware, you can do quite a lot at a higher context, there’s not really any way to prevent it though, which is why the devforum/trusted users only idea would work a little better because there’s less risk of a random user implementing something like that. Another idea would be to use alt accounts (which I’m sure a lot of users would do anyway)
I can definitely see the benefits, but as I stated in an earlier post, I really don’t feel that supporting exploiting in any way would be a good choice for Roblox.
It doesn’t matter if they support it or not. The client security is a joke. Coming out and publicly supporting whitehats wouldn’t even increase the already massive pool of exploiters by a significant amount.