Update cloud-variables.md

docs/website/cloud-variables.md

@@ -26,8 +26,8 @@ Connecting to our servers using bots and other custom clients is acceptable, wit
 
  * When using custom project IDs, don't use random numbers. Project IDs aren't contrained to numbers, so use text that lets us verify that your use is legitimate. For example, `example.com/my-project` is a lot more useful than `3498394834`. **If we see excessive cloud variable traffic to a numerical project ID that corresponds to a project that doesn't make sense, we will disable variables for that project.**
  * Bots must set a proper `User-Agent` header. Include something like a Scratch username, GitHub repository, website, etc. so we can learn more about your bot. Cloud variable libraries should set a default User-Agent with generic library information and provide an API for library users to add their own contact information (ideally, make using this API mandatory). An example User-Agent would be `foo-client/1.0.0 ExampleBot/4.2 scratch.mit.edu/users/TestMuffin`. Pretending to be a web browser is not okay and is trivial to detect. **Connections that do not provide a valid User-Agent will be rejected immediately.**
- * Remember that a WebSocket is a bi-directional pipe, not a single-use HTTP request. If you need to read variables as they change, open exactly one WebSocket connection and let the server send updates as they happen. Once a WebSocket is no longer needed, close it. If you only want to read changes on intervals of several minutes or more, it would be better to open a WebSocket, wait to receive any variables, then close the connection. **We will very likely start blocking bots that constantly open and close many connections or that open simultaneous connections to the same project.**
- * Bots must not send more than 10 cloud variable updates per second. It is server-side throttled at that point; sending more just wastes bandwidth. **We may start blocking bots that attempt to set variables too fast.**
+ * Remember that a WebSocket is a bi-directional pipe, not a single-use HTTP request. If you need to read variables as they change, open exactly one WebSocket connection and let the server send updates as they happen. Once a WebSocket is no longer needed, close it. If you only want to read changes on intervals of several minutes or more, it would be better to open a WebSocket, wait to receive any variables, then close the connection. **Bots that constantly open and close connections will be blocked.**
+ * Bots must not send more than 10 cloud variable updates per second. It is server-side throttled at that point; sending more just wastes bandwidth. **Bots that set variables more rapidly will be blocked.**
  * In order to reduce CPU and network usage, the server batches multiple cloud variable updates to send as a group. The server doesn't promise that it will send each variable update in the same order as they were received or that it won't skip some updates that were replaced by more recent values.
  * Please don't include Scratch session cookies when connecting to our servers.