Well, ive never seen backdoors from plugins so take this with a grain of salt. But the most viruses and backdoors ive seen are from free models, so sure you’re stopping one faucet, but another has existed since the beginning which us models. In some games ive seen tons of viruses where ive had to pull a scanner to help me. So, we still have one faucet going…
2 Likes
yes, but this update is taking care of alot of models that are malicious and take a big impact in the roblox community. We shouldn’t be arguing about things that have already been discussed in this topic. Yes, there are quite alot of pros and contras of this update, but afterall this update is for the safety of robloxians and we’ll find a workaround soon enough. Again, repeating arguments over and over wont change anything.
I don’t fully believe this is for the better, honestly. (If I’m moderated for this umg)
There are so much better ways to handle this, instead of removing a feature because inexperienced devs who bot their favorites/likes on their game to front page don’t know that their free model tree has a script in it, why not instead teach?
Honestly this is a much better alternative to everyone. Many front page games are by inexperienced people who bot their likes and favorites, but don’t know how to develop. A good way to combat this issue is to release a thread by a Dev. Relations member explaining how to ‘background check’ their game. A good one is Ctrl+Shift+F, look for ‘require’. Take the assetId being required, and find where it’s coming from. If it isn’t something you think you want in your game and believe it’ll be a malicious asset, then don’t use it and report it. Most people implementing backdoors aren’t smart enough to use that getfenv() method (not being rude).
7 Likes
I’m sure people who aren’t as experienced in development won’t know if the asset they are using is malicious or not as they cannot see the source code which is what they’re going to focus on rather than checking if the asset is botted etc. Thats the main reason of why private modules can be so malicious.
Though I must agree on the first part, teaching inexperienced developers will reduce the amount of backdoors being inserted into a game. Then again there’s going to be alot of people who won’t bother reading the devs post.
There’s still the possibility that known models etc have backdoors on them even if they are not botted, which makes it pretty much undetectable. Not only would this be bad for inexperienced developers, but for experienced developers it could become a problem aswell.
So what I’m saying here is that whatever people try to do to stop people from inserting backdoors into their games, there’s still going to be alot of people who either ignore or don’t realize they have a potential malicious code inside of their game.
Actually it’s not even that hard to tell if it’s malicious or not. Based on my example, why would a tree need to require anything? It’s suspicious, just might as well be malicious. All it takes is common sense, to be fair, to know what’s not supposed to be there and what is. Not being able to see the source does not mean you can’t judge for yourself whether it is malicious or not. Also, I’m pretty certain experienced developers would not insert a free model without checking it for themselves, as that’s an easy way to get a backdoor into the game. If you don’t have the sense to check for yourself, don’t be a developer. Learn to be a developer first and check the utilities you use yourself.
See one of my previous posts. Features should not be removed due to inexperience and gullibility. That’s a terrible way to go about things. Just because some people are too lazy to learn how to check for malicious code, does not mean that a feature should be removed for everybody. Those lazy people should suffer from their own laziness. Nobody else should.
8 Likes
I agree on everything you said except for this part,
I ment scripts like admin systems etc, you use the script without knowing whats actually going on in the code. Now I know lots of experienced developers would propably make their own systems instead of using free models, but most of the games I visit have systems that use private modules that the game doesnt own. Even if the owner is someone who’s known around the community, he could still do whatever he wants with the code.
Most free admins, like Adonis, don’t have any backdoors because they’re open sourced. Why would you use any admin that needs to be required?
I can assure you there are free admin systems that arent open sourced which have more features than Adonis, people would rather use them as they have functions that adonis for example, doesn’t.
People can obfuscate code - players might be too lazy to figure out how deobfuscate code. Let’s just remove coding entirely, because people are obfuscating their scripts and players are using them while being totally unaware as to what they actually do.
This is how I’m viewing this entire situation, and it seems pretty crazy to me.
4 Likes
Not sure what other admins have that Adonis doesn’t. Pretty decent anti-cheat, all needed commands, some custom features. What ‘free’(required) admins have things Adonis doesn’t?
1 Like
Theres less known admin systems specifically designed for certain areas of roblox, one of them being abacu for example, it an admin system specifically designed for ro-aviation, though it uses require.
You got a good point there, its just that people may be too lazy to deobfuscate code, but they’re not able to get the source of a private module. I mean this is my view of this update, it got pros and contras, theres going to be work arounds though which are propably gonna be more time consuming, but then again, developers shouldnt be too lazy and not use the workarounds.
1 Like
A certain admin just for a certain reason, did I read that right? Sounds like it’s something needed for only some people, not all. This gives reason to keep private modules, well, private.
I understand that they can’t get the source of a private module, I was just arguing against the whole “lazy” argument that you had going on. My biggest issue with most of the posts on here is the reasoning behind these actions. If a feature is going to be removed, I expect a better reason than “a few people are gullible” or “some people are too lazy.”
If the admins offered us a better explanation than “some people r bad,” and they provided a reasonable alternative before removing support, then I would probably be totally okay with removing closed source modules.
1 Like
I am totally okay with your opinion and I support it, the reasoning provided from the admins are quite ‘poor’, I’d love to have an official alternative too, but for now if this goes on we’ll just have to figure out alternatives on our own.
Thats a good point, I don’t really have anything to say about that. Maybe it would unfair towards the group of people who actually need the update, maybe someone could come up with a solution for this, I doubt that is going to happen though.
The Adonis anti-cheat was completely cracked over a year ago, it is completely useless.
I think that I made a fairly good point earlier.
Edit: Thousands of users create and rely on the functionality of private modules, and this update is completely killing them off. (I know this point was already made but I want to reiterate it.)
2 Likes
I don’t think anyone has said this specific suggestion yet, but what if we were to use a system resembling the endorsed model system, and make it so specific, well-known modules that have been around are verified to be safe so can be loaded when closed source? There are many examples of good use of closed modules that have been used throughout time, most commonly in commands or application systems, and APIs are not always a friendly option for everyone. This solution would have a benefit of modules picked by people who are experienced, something a individual module whitelist system would be relying on individual developers, including new ones that may not know what they are doing, would not do. It also provides more than a blanket on/off system like loadstring by not creating running the risk that allowing just any modulescript could potentially pose, not that thats a bad idea.
There are limitations of this and it would be especially difficult for new creators, but Its just an idea that I thought could work at least if it were short term. This update does stop some backdoors, but I doubt that just doing this best we could do. And with what we’ve got now, many services are being left to either switch to APIs, or to public modules. Modules having to be public nearly defeats the purpose in the cases of paid services, and people will just edit out the requirements.
APIs are tough on developers with fewer resources, and aren’t as simple or as transparent as using modulescripts.
3 Likes
You made a good point towards fixing the issue rather than removing it. The admins themselves, however, failed to give a good reason as to why they’re simply removing this feature without providing a reliable and painless alternative before removal.
Edit: Unless an admin has posted somewhere else on this thread explaining this in better detail. As I said before, there are a lot of posts, so it’s possible that I missed something.
Even so, with a system like this, if the owner of said endorsed module were compromised, hackers could overwrite the module with their own code and instantly gain full script context to every game with that module.
As I have mentioned before, we should get a PrivateModulesAllowed property that is off by default that allows creators to load in Private modules. This property should not be able to be changed by any context level script, only manually by the creator.
1 Like