To add, if they can detect these scripts and prevent them from running, it’s also likely possible to point them out in Studio for developers to remove. Really happy to finally see something done about this.
12 Likes
The fact that it showed up in the release notes again is a procedure bug with how the release notes are handled. TL;DR: The revert just ended up with the same release notes as the original change.
8 Likes
If you can get around it, that doesn’t stop people from updating virus scripts which brings you back to square one. Hoping there’s a more grandeur focus around this that hasn’t been disclosed yet.
2 Likes
It’s likely mostly an attempt to prevent spreadable malicious code in toolbox assets from crushing new developers, especially in old toolbox assets that haven’t been updated in half a decade but still hold strong positions in search results. It’s a bandage for a problem that has existed for too long with no easy solution. We should be appreciating this attempt to mitigate this, it’s obviously not desirable for Roblox to just keep doing nothing about the issue for another five years waiting on a Perfect Solution.
14 Likes
Removing the said items also work. If it’s malicious, I don’t see the point of having it remain in view on a public toolbox used in production. Especially when visibility to said items seems to be high (?).
Majority of these issues arise / stem from the lack of care after years of being postponed or essentially forgotten about. As a developer or as a long time user, most decisions on this platform seem to stem from “bandage-like” solutions.
While I’d hope that most of us appreciate this/Roblox/people who worked on said thing(s), I feel like we forget about the years of perpetually asking for this to be fixed. And as the years went by, the library got more saturated with malicious code w/o any tangible safeguards in place.
The only real way that I personally see for this to be corrected is to do a deep clean of malicious code: i.e search every item in the toolbox (wherever it’s stored/pulled from), remove it from view or even delete it (spooky word on this platform lol) and put actual safeguards in-place that will prevent this from happening again. This is a pretty radical move (even in terms of theory) but, like you said, this a complex issue that needs to be handled. However, perhaps, a radical one may work.
This doesn’t just pertain for toolbox. Nearly everything that is accessible by users, published by users and can be search show similar symptoms which as a user or a person trying to “make it” on the platform can be incredibly challenging. i.e The saturation of stolen clothing items from clothing designers, etc.
But yeah, I do agree.
2 Likes
I don’t really feel that deleting or removing content from the toolbox is necessary or a good idea, there is room for that to go wrong. I am, however, a huge fan of this change because it means that old games using malicious code like this won’t be nearly as laggy (I hope).
I think that a good solution is to have a prompt, similar to what you get when you insert a tool. Roblox can pull from a list of “blacklisted” script sources (or hashes of bytecode/source, which, would be easy to store in fast flags), and prompt the user when they insert something, asking them to remove it.
The prompt could simply say, for example, something like “This model has malicious or misleading code in it. Remove the content from the model?”
Additionally, perhaps the prompt could have a third option to insert the model without removing content but select and disable the scripts which would show them in the explorer without allowing them to run by default.
This would be an excellent solution to this issue in my opinion as it would be cheap in terms of development cost, would inform the user about the code being removed, but would not inhibit any use or viewing of the content and would be non intrusive. On top of that, malicious scripts aren’t able to as easily say, for example, ask the user to insert something into the script to stop it from getting blocked.
In the future, this could be extended to rely on all kinds of methods to filter out malicious code, and is extendable, meaning if changes need to be made, they can be made without any unexpected impact to games. (Which would be incredibly rare, but accidents happen)
10 Likes
Not sure if you read the release note or not but it clearly says “really old” scripts, so e.g. ancient “fire antivirus” scripts. I assume they’re meant to make any old models in the library safer again to insert, not to counter new models with virus scripts.
Just because they’re pushing out 1 change doesn’t mean that’s all they’re doing to solve a particular problem, don’t be that guy. 
It’s just 1 release note.
13 Likes
I just appreciate that anything is being done at all so why complain.
7 Likes
Does anyone have an idea of when the new RunService events will work? I see them in studio’s autocomplete today but they don’t seem to fire.
14 Likes
what is the function of
ApplyStrokeMode(as I was unable to see a difference between Contextual and Border in the video above)?
ApplyStrokeMode would switch whether it is adding stroke for text or adding border to the frame if it gets parented under a text object, as we consider there are needs for each of them.
Also, will UIStroke work for text and have the TextStrokeTransparency/Color3 deprecated? It seems in the video that that that border is definitely more than 1 px thick!
Those properties will not get deprecated. It will get overriden if you parent a UIStroke to apply textstrokes, which will allow thickness greater than 1px.
Another one includes support for gradient colors
We support adding gradient to strokes by parenting gradient under a stroke object. We will give more detailed explanation when announcing the beta.
7 Likes
What is the status of these events? After three months these new events still don’t work, and the old events had their Deprecated tag removed.
1 Like
Iirc the deprecated status was removed because the new events weren’t actually enabled when they got deprecated.
Not sure why they haven’t been enabled yet but it probably has to do with the release process, probably around testing. I’ve noticed some features seem to sit around in the engine for quite a while before they release (without any changes seemingly though I’m sure there are occasionally internal changes).
The same thing happened with Attributes, which, interestingly upon release “don’t support” certain value types like CFrame, Region3, arrays, dictionaries, etc despite previously supporting these prior to release, which, I would assume is probably where the hold up was. Perhaps there is a stability or security concern around some of those complex value types as they do seem to be pretty close to their format in memory. (I hope these get readded because it makes most of my use cases for attributes useless)
There might be some concern around these new events for some reason, or maybe they’re just low priority and nobody has had a chance to test and approve them.
1 Like
Security in a way. The issue is that there’s no way for the properties UI to display those types of items even if the Attribute storage itself can store them. It’s not just a question of implementation work either, we couldn’t arrive at a UX we were happy with for dealing with them so excluded them from the first version of Attributes rather than making people wait even longer for them.
TL;DR: Having people able to pack hidden data into an instance that you can’t find out is there without scripting is not ideal. We did it with Tags, but didn’t want to repeat the same mistake with Attributes.
3 Likes
Is there anything complicating the issue of showing tags in the properties widget? Or is this just a matter of prioritization? It’s funny that both the properties widget was revamped and attributes were released while tags are still completely invisible.
1 Like
I mean, if it were just showing Tags in the properties widget then that would be easy enough, but that’s not an acceptable Tags UX. The whole idea of tags is that you can identify things with a given Tag, so you’d want some viewport visualization / way to hide things with a given tag, etc… so it’s a much bigger can of worms to deal with.
2 Likes
That sounds very cool if those are the features Roblox would like for working with tags in Studio, but I really think something like this needs to be handled in “levels of quality”.
Even if Roblox has a whole awesome feature spec designed for this already, that is meaningless to users because in the meantime, they’re waiting 2+ years with no functionality whatsoever while Roblox shuffles around priorities. Completely leaving out this functionality for years is worse UX than providing super basic controls, because out of touch developers won’t know about CollectionService, or third party plugins, and other developers now have to juggle more screen clutter and spend more mental effort to work with tags.
The code for this in the properties widget would also most likely be independent from the other tooling, and could likely be reused or expanded upon later.
It seems wrong to put off something like this just because plans for the feature are huge and the roadmap doesn’t have space for it.
5 Likes
Maybe Roblox could “endorse” good community resources—eg this is the tag plugin I’m aware of and use
Yes, for some further context, the fact that there’s already a very good Tag editor community plugin at this point does play into this. Even if we make a stopgap solution (which is something that we try to avoid doing if at all possible), if it isn’t better than the readily available community tag editor then it wouldn’t accomplish much.
3 Likes
I would argue that simply by it being built into studio, in a place where people look to see instance properties, it’s already valuable enough because it is much more convenient for a quick glance, and many people don’t even know CollectionService exists, especially since its name isn’t obviously affiliated with tags. I wouldn’t call it stopgap either if the properties widget side of implementation can be easily iterated on.
Truth be told, I do not use most of the advanced features of the tag editor plugin. I only use it to add, remove, and see what tags are available, the last of which is not strictly necessary for my workflow.
Thanks for talking about this by the way!
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.