Removing Direct use of TPService from MS's

Feature Requests Engine Features
#1

-Removing Direct use of TeleportService from ModuleScripts-
Okay so here’s the thing. TeleportService is a fantastic service, and with hesitance I suggest this, but I suggest that we remove direct use of it from ModuleScripts (or at least direct use of the Methods)…

Reason:
Using TeleportService from a ModuleScript is a major issue because it allows ModuleScripts that are required directly from the website to maliciously update the Source of the MainModule to include a functionality to teleport everyone actively using the script in their games to a specific place;

Now here’s the thing. I’m not out of the blue thinking about this, and coming up with a conspiracy about it etc; this is something I have heard directly from Scripth (whos admin has over 800K takes.) He told me on the day he quits he would use this as a front to teleporting people to a game of his (he didn’t specify if he was currently working on said game);

He explained to me he was causing an effective DataStore crash when he first started using them in his admins and his admins in turn sent too many information gets, and sets requests causing crashing in the DS system. Admins here can probably view the moderation history of his assets to find that to be true;

He also explained to me he tried the TeleportService trick once when it had 8K takes and got 3,000 players in a single game at once (at which point he vowed to wait and only use it again on the day he quits.)
He mentioned a name on this forum (that I may or may not disclose?) that egged him onto doing it

Unfortunately I do not know how to get the (rather explicit) steam chat logs from steam that we created a couple nights ago when we talked about this on Feb.15th in the AM times (about 2AM-4AM) but if I find out I will definitely post them.

The biggest reason I see this as a problem is ROBLOX is generally a equal opportunity platform, and if Scripth (or anyone else who achieves his level of asset-usage for ModuleScripts) the service to forcibly teleport thousands upon thousands of people to their place at once (without their consent), it would make thousands of people mad, and interrupt whatever they were currently doing.
I don’t normally like to dictate what good coding practice is, but for RBX.lua unfortunately I would have to say TeleportService should not generally be allowed in ModuleScripts because of the potential malicious behaviors it can cause which could In turn hurt the platform or its consumers.

Considering Scripth now has 800,000 takes on his admin, compared to when he used TeleportService when it had 8K takes, I think we all know how unequal and unethical it would be for him to forcibly teleport (what I would predict to be over 30,000) people to his own place without their consent or confirmation.

1 Like
#2

Honestly, I do not think this would be a good idea. Modulescripts are useful for dividing your code up into smaller “modules”. Taking features away negatively impacts their usefulness.

You should not trust other peoples modules or even allow them to remotely update code which directly affects your game. They could just as well clear all children of Workspace.

12 Likes
#3

Should we also not allow free models to use teleportservice because someone might hide a teleport script in one?

/s

I honestly don’t see this being much of a problem

#4

The way I see it this is just one of the many risks you run if you give other people access to run code on your server. If you don’t want your game to be affected then don’t use his commands.

4 Likes
#5

I think this is just one of the risks of using a private module in your game. Using the teleport API in modules is something that could be prevented in theory but there are plenty of other ways that creators of private modules can do damage to games that can’t be prevented, I think if you don’t trust the creator of the module you shouldn’t be using it.

3 Likes
#6

that’s the risk of free models

2 Likes
#7

Or… you know…don’t asset require? Unless it’s private I guess… Then just make your own?

#8

I use malicious code all the time in my friends places, they trust me enough to let me run a place destroyer :smiley:

#9

I think a better solution would be a new option like “Allow3rdPartyTeleports”, that must be checked to teleport to other games.

#10

It’s not a problem with teleports or any other aspect of the API - as said before, he has many other options to damage people’s games with this script - it’s simply a problem of people misplacing their trust, which can happen in any case where you’re using a 3rd party service.

Even if he performs this mass teleport, he won’t stand to gain very much aside from a few tens of thousands of tickets (before his game gets deleted and he is banned), and notoriety of course.

It’s a shame that the author of such a popular script would perform these malicious actions against the people who have put their trust into him, though I can’t say I’m surprised in this case.

1 Like
#11

I understand the other arguments, I do not understand this argument as being valid considering you have every opportunity to look at the source of the hidden script (and ever chance to find that hidden script), and also not fear it will be changed in real time to be possibly malicious.

The biggest (and most important) difference between public modules, and free models, is the ability to upload malicious code in real time which affects everyone who has the modulescript, as opposed to updating a free model and any un-updated free models won’t be affected.

@Everyone else, thanks for the counter arguments, I liked a lot of them and they made sense.

That being said, for the people who didn’t give implied consent to be teleported (aka the people who are playing the game, and didn’t make the game) these are the victims- if it was a datastore problem I was speaking against, yeah sure, it’s a risk the developers of those games are taking by having the admin have too many datastore requests or something; But in this case the people being targeted are the people who had nothing to do with it in the first place. I understand the same could be said about destroying every part in workspace, or unanchoring everything, but would it be too much of a stretch to include a confirmation option for teleports if they are initialize by a third party source?
Would that not be sufficient?

#12

If you don’t trust third party modules, just don’t require them using an assetId.
When something like this happens, it’ll be the module creator that’ll get punished.
He’ll lose the trust he had earned.

And let’s be real:
If I had a module, and modules were blocked from using stuff, I would just insert a normal script.
(I could even insert a localscript in all players, to display a fancy teleport GUI while they’re teleporting)

#13

This is why I make all of my own stuff, so I don’t have to worry about malicious manipulation.

Only use public work from trustworthy sources.

1 Like
#14

I got plenty of public modules.
When you insert them, some of my modulescripts contain a regular script that does require(assetid).
There are probably some games that use that, but I don’t really care about that.
Those people that use it are probably used to me releasing lots of stuff without suddenly ruining games.
Nothing stops you from inserting the module, removing the loader and using require(modulescript).

[size=10]I can still turn evil any moment I want, but eh[/size]

I got a modulescript, which is named “Visited” I think? (lemme search)
Found it, it’s called Visited Module since it has to do with visits…
Whenever someone joins, os.time() is stored in an OrderedDataStore by userid.
(When they leave and every 5m it’s also updated, because up-to-date data is nice)
It allows you to easily see who has been in-game recently, or when a certain person last visited.
I use this in some of my projects which will (well, might) be released sometime.
People could be using several of those projects, or the Visited Module itself.
In that case, it would be good if everyone used require(assetid), else it would run several times.

Another project will be a closed-source admin that gets loaded (and kept private) using require(assetid).
People would have to completely trust me, which some do. (would be sad if nobody trusted me)
The bonus from require(assetid) that also counts for open source scripts: It auto-updates.
(You know, without having to do LoadAsset, hoping the place creator took the model…)

What I’m trying to say: If you trust the creator, use require(assetid). Don’t if you don’t trust him/her.

#15

I never give other people control over my places by putting their model-based ModuleScripts in my place. It’s just a bad idea.