As a Roblox developer, it is currently too hard to programmatically or manually prevent unwanted code from being loaded into my experience. If a plugin adds unwanted code to my experience then I have to spend an absurd amount of time doing a deep search to find and remove the source. Malicious code often attempts to add a third party require to run unrestricted code in live experience servers.
If Roblox is able to address this issue, it would improve my development experience because the unwanted code would be stopped at the source and wouldn’t have a chance to run at all in live servers thus providing minimal disruption for visitors and allowing me time to debug and search the place file for where the malicious code was added into and then remove it.
I have never had a genuine use case to require by id in my own experience.
This is used for loading modules other people write quite a bit.
I agree that Roblox needs to provide more control over modules. For example, if a module is not owned by you it has to be approved by you first, or at least will show a warning letting you know that a third party module was loaded, what its ID is, and who it was authored by.
Currently, there’s just no way to tell when modules are getting loaded, and assuming one somehow sneaks into your game, you might not ever know if its well hidden enough.
I know and this isn’t my concern. There are developers who still require by id to load in code written by other developers and that’s still a legitimate use case. This doesn’t apply to everyone though. I have never had a genuine use case to require by id in my own experience.
I want to simply be able to turn off a feature I don’t use that can cause potential problems for me down the line especially working with collaborators who don’t vet their tools correctly. I’m speaking from my own use case and don’t speak for everyone.
I recognise that this feature request does focus in on backdoors as my example of unwanted code but ideally I don’t want any unwanted code from running in an environment that I do not have immediate access to. Doesn’t matter what it does, I have no use case to require third party modules.
Current methods are still long-winded as I made sure to point out in my problem statement:
Search-and-destroy is a valid option that developers should look into or find as a helpful solution against backdoors and will have to commit to at one point but that code is still going to ship and run in live experiences in the time that you don’t find it.
It is tedious and time wasting to spend a bit of development time every Studio session preemptively searching for that code when you could stop it as in when it appears right away and deal with it later, saving you precious development time to work on other experience features.
I don’t agree at all, lol. I’ve made some points pretty explicitly clear throughout:
My problem statement: “As a Roblox developer, it is currently too hard to programmatically or manually prevent unwanted code from being loaded into my experience.”
I want to be able to disable a feature I have zero use cases for to preemptively stop issues from occurring rather than using long-winded methods to deal with it. Why should I wait until it’s affecting me to stop it rather than just be notified “hey, there could’ve been a problem here, maybe deal with it sometime?”. This is also important again for “working with collaborators who don’t vet their tools correctly” (as mentioned in my reply to Hexcede).
I prefer to spend more time developing features, not looking for backdoors after-the-fact when they’ve caused damage to my experience and potentially affected the initial impression other users have of it. First time experience is important.
Not sure what you mean by the first statement at all… just because a developer encounters unwanted code being loaded into their game, it does not mean that the content isn’t made by them. Even if it isn’t made by them, so long as it’s not sourced from a bad faith actor, so what? Resources and plugins exist and they are commonly a culprit here.
Additionally, I made it explicitly clear that backdoors are an example but not the encompassing point of this feature request, so stop hijacking to focus in on that. I don’t have a use case for allowing id-based requires in my experience and that’s primarily what this feature request targets; stopping it at all. It’s importance is literally irrelevant and so are existing methods to quarantine unwanted code? It’s a feature request. Feature requests are aimed at requesting things to be possible on the platform. I don’t care what priority level its assigned if they want to add this feature too or anything; the point is that it happens at all at any point in the future.
Your comments aren’t providing anything useful here but moot argumentation and ignore what I’ve stated in the initial request as well as my follow up.