@Seranok While I do see your point, why hasn’t this limitation been applied to the require(assetId) function? Can you clarify why require(assetId) isn’t restricted when, in practice, it is also creating “dynamic third-party dependencies” within many games, such as with admin scripts?
Here’s the difference: It can currently load any free ModuleScript from the Library via its asset ID, and there is no setting to restrict it. ModuleScripts can run their code before the game can do anything to interfere, so it might as well be a more dangerous version of loadstring. In contrast, with InsertService, games have an opportunity to strip out BaseScripts and other unwanted objects before adding them to game worlds, but it’s currently restricted.
Basically, a more controllable model-loading system, InsertService, is restricted, but a less-controllable and more dangerous system, require(assetId), is unrestricted. Given the reasons I’ve stated, it would seem the restrictions should be the other way around.
I have previously made a similar feature request to this asking for security switches for these two model-loading functions.
In the meantime, I created web server software which eases the restrictions for non-group games (for creators willing to run their own web servers).