Currently, there are two main problems surrounding cloud variables:

• They stop working frequently
  
• They can be set by bots, meaning people can set impossible high scores and do a denial of service (DoS) attack on multiplayer games.
  

What if we had two different kinds of cloud variables: open and closed cloud variables?



Closed cloud variables:

• The API for these is closed, so software like scratchattach can't edit their values
  
• They have security measures so simple HTTP requests can't edit their values
  
• They have bot protection so DoS and DDoS attacks on multiplayer games won't work
  

Additionally, all existing cloud variables will be closed cloud variables, and all new ones will default to closed.



Open cloud variables:

• API is open, so scratchattach and similar software can access and change values
  
• Still require account credentials to authenticate, but no bot protection, similar to the current system
  
• Other projects can access, but not set, these variables without third party services.
  
• New cloud variables need to be set to open manually, and the process of setting them to open has bot protection
  

This system has numerous advantages over the current one, and over any completely-locked-down system:

• Cloud variables can't be overloaded by bots. If they become overloaded, it can only be because of normal users
  
• Existing projects that may have been used for a DoS or DDoS attack on the servers will be stopped immediately
  
• New attacks on cloud variables will be very slow because the cloud variable API can't be enabled by bots
  
• Inter-project cloud variables, as suggested here, will be possible with open cloud variables
  
• Open cloud variables will still require quite a bit of work to abuse because they require the credentials of a user who's reached Scratcher status to set, just like the current system
  
• Few projects will use open cloud variables because of their niche nature, so attackers can't effectively DoS the cloud variable server with other people's projects
  
• Making all existing cloud variables closed won't hurt almost anyone because the number of projects that require bots to set cloud variables made by Scratchers who are no longer active to reopen them can be counted on one hand.
  

Additional technical details

• Cloud variable services will continue to be unavailable for New Scratchers. This includes linking cloud variables from another project. As such, the editor will not change in any way for New Scratchers.
  
• Cloud variables being open/closed is not stored in the project itself. When downloading the project, this information is not saved. When the project is reuploaded, it will automatically make all cloud variables closed.
  
• In the editor, closed variables and open variables look the exact same. The difference is not stored in the project.
  
• Remixing makes all variables closed. Linked variables will remain.
  
• Linked variables cannot be set. As such, they will not appear in set or change variable block dropdowns.
  
• An explanation will be provided in the FAQ about this feature.
  
• Both open and closed cloud variable servers will reject HTTP requests sent by banned users to lower the number of DoS attacks on projects.
  

I made some mockups below. Hopefully this reduces abuse and keeps cloud variables up for longer, all without disrupting project functionality.

Mockups:



This will open the following menu:



Here people can open or close their cloud variables and connect to others' cloud variables.



A linked variable

support!

i have been bugged by cloud variables not working for years now and this seems like a useful and practicable way to fix them, while also adding new features like cross-project variables (i think if i read the suggestion right). btw, the mock-ups look really clean and definitely helped me understand the suggestion better.

This is a genuinely well-structured suggestion. The open/closed split addresses the core tension that every cloud variable discussion runs into: the same system that makes multiplayer games possible also makes them exploitable.

The strongest part of this proposal is the default-closed approach. Most projects that use cloud variables are leaderboards or simple multiplayer games - they have zero reason to expose their variables to external APIs. Making closed the default means the vast majority of projects get protection without their creators needing to understand what an API even is. That's good design.

A few thoughts on the implementation:

• The “closed” enforcement problem - saying “the API is closed” sounds simple, but Scratch's cloud variable system currently works over WebSockets. Blocking external access means Scratch would need to distinguish between a real Scratch client and a bot pretending to be one. That's not trivial - it's essentially the same arms race every anti-cheat system fights. CAPTCHAs on connection? Token rotation? Both add complexity that could affect legitimate users.
  
• Inter-project cloud variables - this is actually the most exciting part. Right now, projects are completely isolated from each other. Open cloud variables that other projects can read (but not write) would enable entirely new project types - shared world state, cross-project leaderboards, collaborative data. That alone justifies the open/closed distinction.
  
• Migration risk - “all existing cloud variables will be closed” is the right default, but it will break every project that relies on scratchattach or similar tools. A grace period with notifications to affected project owners would smooth the transition.
  

The bot protection on the open/closed toggle itself is a nice detail - it prevents someone from scripting a mass-switch of variables to open. Shows you've thought about the meta-game, not just the surface-level fix.

Support with the caveat that the “closed” enforcement mechanism needs more detail. The what is solid; the how is where this gets hard.

PaymerAlt wrote:

The “closed” enforcement problem - saying “the API is closed” sounds simple, but Scratch's cloud variable system currently works over WebSockets. Blocking external access means Scratch would need to distinguish between a real Scratch client and a bot pretending to be one. That's not trivial - it's essentially the same arms race every anti-cheat system fights. CAPTCHAs on connection? Token rotation? Both add complexity that could affect legitimate users.

…

Support with the caveat that the “closed” enforcement mechanism needs more detail. The what is solid; the how is where this gets hard.

You're right. Scratch would probably need to either completely change protocols or route requests through a proxy and hide the core websocket server, both of which would require a completely different system for open variables. I'll have to think about this.

Edit: I found an article explaining websocket various vulnerabilities. Hopefully this helps.

PaymerAlt wrote:

Migration risk - “all existing cloud variables will be closed” is the right default, but it will break every project that relies on scratchattach or similar tools. A grace period with notifications to affected project owners would smooth the transition.

An announcement should be sufficient for notifying affected users. A grace period is definitely a good idea; it would prevent almost every project using external tools to set cloud variables from being broken, as the number of projects that rely on such tools that were made by users who have since gone inactive (meaning they wouldn't be online to set their cloud variables to open) is very low, and the chances that those external programs are still running is even lower.

I just did some research and discovered WebTransport. There's an older article on it and a newer one documenting JavaScript support. It's supported in all of the browsers Scratch supports, and it looks like it could be more stable than the current WebSocket system. Could the current system be used just for open variables and a new WebTransport-based system be used for closed variables? I don't have a lot of experience with web development at this level.

bump, this topic needs more discussion

from people who are smarter than me

Does anyone think WebTransport would be a good alternative to WebSockets to use for a new closed cloud variable system? It looks good to me, but I'm unfamiliar with this level of web development. Also, how easy would it be to make a WebTransport-based cloud variable system?

Edit: It looks relatively easy to implement in Python. (Docs for implementation)

To avoid potential confusion: when I'm suggesting using WebTransport, I'm suggesting that an entirely new cloud variable system be created for closed cloud variables and use the current WebSocket-based system for open variables to provide maximum compatibility with existing external tools.

Bump

Bump

Bump

It would be cool is closed variables would be infinite or at least a large quantity, since closed variables would ACT like as if you are manually saving it to the computer in editor.

GunesKing wrote:

It would be cool is closed variables would be infinite or at least a large quantity, since closed variables would ACT like as if you are manually saving it to the computer in editor.

I think you've misunderstood the suggestion. Closed variables are just like open variables, with the only difference being that open variables can be accessed from other projects (while also behind the scenes allowing other programs to set variables and potentially running different backend software). This has nothing to do with who can access the variables. Allowing them to store infinite amounts of data does nothing to stop the servers from becoming overloaded, which is the reason I made this suggestion.

PaymerAlt wrote:

This is a genuinely well-structured suggestion. The open/closed split addresses the core tension that every cloud variable discussion runs into: the same system that makes multiplayer games possible also makes them exploitable.

The strongest part of this proposal is the default-closed approach. Most projects that use cloud variables are leaderboards or simple multiplayer games - they have zero reason to expose their variables to external APIs. Making closed the default means the vast majority of projects get protection without their creators needing to understand what an API even is. That's good design.

A few thoughts on the implementation:

• The “closed” enforcement problem - saying “the API is closed” sounds simple, but Scratch's cloud variable system currently works over WebSockets. Blocking external access means Scratch would need to distinguish between a real Scratch client and a bot pretending to be one. That's not trivial - it's essentially the same arms race every anti-cheat system fights. CAPTCHAs on connection? Token rotation? Both add complexity that could affect legitimate users.
  
• Inter-project cloud variables - this is actually the most exciting part. Right now, projects are completely isolated from each other. Open cloud variables that other projects can read (but not write) would enable entirely new project types - shared world state, cross-project leaderboards, collaborative data. That alone justifies the open/closed distinction.
  
• Migration risk - “all existing cloud variables will be closed” is the right default, but it will break every project that relies on scratchattach or similar tools. A grace period with notifications to affected project owners would smooth the transition.
  

The bot protection on the open/closed toggle itself is a nice detail - it prevents someone from scripting a mass-switch of variables to open. Shows you've thought about the meta-game, not just the surface-level fix.

Support with the caveat that the “closed” enforcement mechanism needs more detail. The what is solid; the how is where this gets hard.

pls dont use AI to make your posts, people expect real answers and not a clankers opinions

Pixalperfect wrote:

support!

i have been bugged by cloud variables not working for years now and this seems like a useful and practicable way to fix them, while also adding new features like cross-project variables (i think if i read the suggestion right). btw, the mock-ups look really clean and definitely helped me understand the suggestion better.

support for the same reasons

Foxofpeace wrote:

(#14)

PaymerAlt wrote:

-snip-

pls dont use AI to make your posts, people expect real answers and not a clankers opinions

i don't think they used AI because the writing makes sense and the points are connected to the OP, i think they just wrote a very detailed post

Pixalperfect wrote:

Foxofpeace wrote:

(#14)

PaymerAlt wrote:

-snip-

pls dont use AI to make your posts, people expect real answers and not a clankers opinions

i don't think they used AI because the writing makes sense and the points are connected to the OP, i think they just wrote a very detailed post

the post feels uncanny and not natural

Foxofpeace wrote:

(#17)

Pixalperfect wrote:

Foxofpeace wrote:

(#14)

PaymerAlt wrote:

-snip-

pls dont use AI to make your posts, people expect real answers and not a clankers opinions

i don't think they used AI because the writing makes sense and the points are connected to the OP, i think they just wrote a very detailed post

the post feels uncanny and not natural

honestly wish it wasn't so hard to tell nowadays but idk if they did or not

Pixalperfect wrote:

Foxofpeace wrote:

(#14)

PaymerAlt wrote:

-snip-

pls dont use AI to make your posts, people expect real answers and not a clankers opinions

i don't think they used AI because the writing makes sense and the points are connected to the OP, i think they just wrote a very detailed post

It seems to me like an AI touchup, because it sounds like AI but contains some key elements that would suggest they actually typed it. Edit: It seems more like they touched up AI now that I'm reading it again.

Back to the topic, does anyone know if a WebTransport-based cloud variable server would be feasible for Scratch to make, and could it be secured easily enough that it would be easier than simply trying to secure the existing WebSocket system?

HighlaneGamingStudio wrote:

(#19)
Back to the topic, does anyone know if a WebTransport-based cloud variable server would be feasible for Scratch to make, and could it be secured easily enough that it would be easier than simply trying to secure the existing WebSocket system?

i don't exactly know if a webtransport based server will be easier but i believe that it would be more sustainable. the ST is already trying to fix cloud servers so switching to a new system instead of using an outdated one would be much better in the long run; it would probably take longer due to the fact the ST is handling many other issues with the site tho. (take everything i said with a grain of salt, i don't know exactly how these systems work)