Keybinding scripts and the simultaneity rule

[The Northern Light]

Hi,

I wanted to ask for clarification regarding scripting tools tools creating keybindings for specific NS actions (e.g., NS Breeze), and how they are affected by the simultaneity rule listed in the OSRS. As a tl;dr, I state my questions at the end of this post; but they are hard to explain clearly without a lengthier description, hence the long post in-between.

For reference, in addition to the OSRS, I've found two threads that relate to this question. I'll list all three threads below for convenient reference:

• The One Stop Rules Shop---Script Rules for HTML site [Note: The table of contents in the OP of this thread does not link to the script rules, making them easy to miss.]
• How to follow the simultaneity rule [Note: This thread really ought to be linked in the OSRS thread.]
• Post Suppression Throttle [Note: Page 2 has the most relevant discussion.]

---

I will use an example scenario to explain my question. Let's say that you want to endorse a list of 20 WA nations. I describe below the most efficient fully-manual, completely-unassisted way for doing this (as far as I know at least).

Fully-manual, completely-unassisted case:
1) Open the nations' pages of the 20 nations in 20 consecutive tabs on your browser.
2) Repeat the following 20 times:
2)(a) Use CTRL+TAB (or other browser shortcut) to switch to the next nation page.
2)(b) Click the "endorse" button to endorse the nation.

Note that, as a player quickly alternates between steps (2)(a)-(2)(b), it is very likely that they will submit multiple near-simultaneous requests to NS. In particular, most likely they will end up hitting several endorse buttons in a row before their first "endorse" request has produced a complete response from the NationStates server (this is how simultaneous requests are defined in the OSRS simultaneity rule). However, given that this is being done completely manually, without any assistance, the simultaneity rule does not apply and the above is legal.

Now consider how this changes when the player uses a keybinding script (I've put the difference in bold).

Keybinding script-assisted case:
1) Open the nations' pages of the 20 nations in 20 consecutive tabs on your browser.
2) Repeat the following 20 times:
2)(a) Use CTRL+TAB (or other browser shortcut) to switch to the next nation page.
2)(b) Use E (or other keyboard shortcut) to endorse the nation.

As in the completely-unassisted case, the player is very likely to generate several simultaneous (as per the OSRS definition) "endorse" requests. In fact, given that hitting E is faster than clicking an HTML button, the number of simultaneous requests is likely greater than in the completely-unassisted case. However, unlike that previous case, the player's actions now are being performed through a tool, and therefore are subject to the simultaneity rule. Consequently, the above sequence of actions becomes illegal for violating the simultaneity rule.

As far as I am concerned, the difference between the two cases is so trivial, that it'd seem way too excessive to rule the script-assisted case illegal. But still, as far as I can tell, a strict reading of the simultaneity rule would indeed make the second case illegal.

The explanation of the simultaneity rule (second thread I linked above) does not seem to say anything that would make the above strict reading of the simultaneity rule incorrect. To the contrary, there is the following quote that could be interpreted to apply to the keybinding script-assisted case; and if it does apply, the quote points towards this case being illegal:

It is also illegal to create a button which causes something to happen when clicked and can be clicked again before the result of the previous click is complete.

Related to the above is this post by Eluvatar in the third thread I linked above. This post refers to buttons being moved by CSS manipulation. Eluvatar says that, if the purpose of the CSS manipulation is to facilitate clicking several times in quick succession, the simultaneity rule needs to be enforced. While not exactly equivalent to the keybinding situation, it is a fairly close analogue.

Another post worth noting in this thread is this post by [violet]. There, she recognizes that this very strict enforcement of the simultaneity rule on CSS manipulation tools would be unreasonable, and she hints that such tools may in the future be excluded from the simultaneity rule. However, it is not clear whether this exception has taken effect; it is also not clear whether it extends to keybinding scripts.

---

Given the above, could you clarify the following:
1) Is the "keybindings script-assisted case" I describe above illegal under the simultaneity rule?
2) Has the exception to the simultaneity rule for CSS manipulation tools taken effect?
3) Can we expect a similar exception as for CSS manipulation tools?

Thanks in advance for the information!

[The Northern Light]

Bumping before it slides into page 2.

I know a lot of gameplayers are interested in this question, so a response would be very helpful .

[[violet]]

It's a good question.

I agree with your summary of the current situation: that the "keybinding script-assisted case" is likely to result in behavior that is illegal now under the simultaneous requests rule, but we should probably go ahead and formally introduce some kind of exception, similar to what's been discussed for CSS-only tools.

My thought is that browser-based tools that merely rearrange a page (whether by CSS or JS) or add click listeners or keybindings should have to abide by the simultaneity rule but only within the bounds of their current browser tab. That is, if the tool modifies a button that endorses a nation, it must ensure this button can't issue simultaneous requests by itself, but not need to worry about what happens if the user switches tabs.

This presumes the tool isn't switching tabs itself, of course.

Users would then be free to engage in the "keybindings script-assisted case" behavior, but it would still be illegal to use a tool of the kind Eluvatar refers to, where a tool makes a button more clickable but fails to prevent it from issuing multiple simultaneous requests.

Would that solve the current problem, do you think?

[McChimp]

Could somebody please clarify for me if there are any situations in which Breeze (a script of this type) can perform multiple restricted actions using a single tab without having to wait for a new page to load fully? For example, are there two keybindings for endorsing and ejecting a nation that you could effectively use before that nations' page reloaded?

[Caelapes]

Could somebody please clarify for me if there are any situations in which Breeze (a script of this type) can perform multiple restricted actions using a single tab without having to wait for a new page to load fully? For example, are there two keybindings for endorsing and ejecting a nation that you could effectively use before that nations' page reloaded?

That would be illegal from what I understand, as doing either action refreshes the nation's page if I'm remembering correctly - that was ruled illegal in the same way that scripts suppressing RMB pages (coexisting suppress buttons on the same page being "clicked" rapidly).

[McChimp]

Eluvatar's elaboration on how the simultaneity rule is to be abided by states that "It is illegal to generate and use a page with multiple forms pointed at nationstates.net if you can submit the forms in parallel".

Does this not therefore mean that the rule already only applies to individual tabs?

My understanding, given that thread, is that a script satisfies the rule so long as it makes submissions using AJAX and waits for the AJAX callback before allowing the user to make another restricted input on that tab.

[The Northern Light]

Eluvatar's elaboration on how the simultaneity rule is to be abided by states that "It is illegal to generate and use a page with multiple forms pointed at nationstates.net if you can submit the forms in parallel".

Does this not therefore mean that the rule already only applies to individual tabs?

My understanding, given that thread, is that a script satisfies the rule so long as it makes submissions using AJAX and waits for the AJAX callback before allowing the user to make another restricted input on that tab.

Before anything else, I should clarify that I am no expert in Breeze: I've neither written its code, nor ever used it. What I say below is based on my reading of Breeze's raw code, as provided to me by a user. Also, I'm obviously not an admin, so what I write below is simply my interpretation of the rules.

Breeze provides shortcuts for several of what the OSRS defines as "restricted actions", including moving to a region (M) and endorsing a nation (E).

However, looking at the underlying code, Breeze seems to work by virtually "clicking" specific buttons in pages. If a page does not have a button, then pressing a key will not generate any request for NS.

So, for example, pressing M + E one after the other in the same tab while viewing some region page will generate a request to move to the region, but it won't generate a request to endorse somebody, because there is no "Endorse" button to "click".

Therefore, the only way for Breeze to violate the simultaneity rule within the same tab is if it allows you to "click" two buttons that are present on the same page and both generate restricted actions. As far as I can tell, Breeze doesn't provide such options. So, as far as I can tell, it's not possible to break the simultaneity rule using Breeze while staying in one tab.

Note that Breeze does not use synchronous Ajax requests (i.e., what Eluvatar suggests in his elaboration post), and as a result, it's very easy for any new features to create the potential for illegal behavior. For example, If Breeze was to, say, add a keypress for ejecting a nation (say, J), then violating the simultaneity rule within the same tab would become possible: It'd be as simple as a user hitting E + J very fast while viewing the page of a nation they can endorse and eject.

Also, the above applies only to the official Breeze distribution. My understanding is that there are a myriad of keybinding scripts, including personalized variants of Breeze, that could very well be running afoul of the simultaneity rule within a single tab. Therefore, there is a strong risk that variants derived from Breeze could be illegal.

It seems to me that it would be better if whoever maintains Breeze added some synchronous code, along the lines of what Eluvatar suggests in his post, to avoid such problems.

It's a good question.

I agree with your summary of the current situation: that the "keybinding script-assisted case" is likely to result in behavior that is illegal now under the simultaneous requests rule, but we should probably go ahead and formally introduce some kind of exception, similar to what's been discussed for CSS-only tools.

My thought is that browser-based tools that merely rearrange a page (whether by CSS or JS) or add click listeners or keybindings should have to abide by the simultaneity rule but only within the bounds of their current browser tab. That is, if the tool modifies a button that endorses a nation, it must ensure this button can't issue simultaneous requests by itself, but not need to worry about what happens if the user switches tabs.

This presumes the tool isn't switching tabs itself, of course.

Users would then be free to engage in the "keybindings script-assisted case" behavior, but it would still be illegal to use a tool of the kind Eluvatar refers to, where a tool makes a button more clickable but fails to prevent it from issuing multiple simultaneous requests.

Would that solve the current problem, do you think?

I'll need to think more carefully about this, to avoid creating any new loopholes, but it seems like a reasonable direction.

I think it would also be helpful to clarify what happens to those who have already violated the rule (as per this discussion) using one of the available keybinding tools across multiple tabs, in the way I described above.

It seems to me that this instance of breaking the simultaneity rule could apply to other scenaria, e.g., answering issues or ejecting nations or surfing regions, that can be performed by having multiple tabs open.

[McChimp]

Therefore, the only way for Breeze to violate the simultaneity rule within the same tab is if it allows you to "click" two buttons that are present on the same page and both generate restricted actions. As far as I can tell, Breeze doesn't provide such options. So, as far as I can tell, it's not possible to break the simultaneity rule using Breeze while staying in one tab.

Note, though, that this seems like a happy accident. Breeze does not use synchronous Ajax requests (i.e., what Eluvatar suggests in his elaboration post), and as a result, it's very easy for any new features to create the potential for illegal behavior. For example, If Breeze was to, say, add a keypress for ejecting a nation (say, J), then violating the simultaneity rule within the same tab would become possible: It'd be as simple as a user hitting E + J very fast while viewing the page of a nation they can endorse and eject.

Also, the above applies only to the official Breeze distribution. My understanding is that there are a myriad of keybinding scripts, including personalized variants of Breeze, that could very well be running afoul of the simultaneity rule within a single tab. Therefore, there is a strong risk that variants derived from Breeze could be illegal.

It seems to me that it would be better if whoever maintains Breeze added some synchronous code, along the lines of what Eluvatar suggests in his post, to avoid such problems.

Concerningly, in terms of written rules, this does not seem to be enough. Eluvatar is unambiguous about this: "Legal solutions will involve submitting restricted actions using AJAX and not allowing a subsequent action until the AJAX callback is called". It follows logically from this that any such script that does not use this mechanism is not legal.

This is presumably intentional. The system Breeze uses has the potential to create actual simultaneous requests as you say (even if the official release can't). If it used the AJAX callback system, it couldn't.

Apparently an admin specifically told them that the code was legal, though. If that's true I can't see how it would be fair to punish them.

[The Northern Light]

Concerningly, in terms of written rules, this does not seem to be enough. Eluvatar is unambiguous about this: "Legal solutions will involve submitting restricted actions using AJAX and not allowing a subsequent action until the AJAX callback is called". It follows logically from this that any such script that does not use this mechanism is not legal.

My reading of this has always been that this is one of many possible ways to avoid breaking the simultaneity rule, and not the only permissible way. You are right, though, that it is possible to read Eluvatar's post as a requirement, rather than a recommendation.

I think it would be worth having a clarification on this point as well.

[The Blaatschapen]

Apparently an admin specifically told them that the code was legal, though. If that's true I can't see how it would be fair to punish them.

I'd like to see a source for this claim.

[Roavin]

Eluvatar's elaboration on how the simultaneity rule is to be abided by states that "It is illegal to generate and use a page with multiple forms pointed at nationstates.net if you can submit the forms in parallel".

Does this not therefore mean that the rule already only applies to individual tabs?

That had been my understanding this entire time as well.

Furthermore, if that was not the case, it would effectively ban every keybind by default that involves any sort of keybinding or button moving or button augmentation or anything, as the security measures in browsers don't allow for full cross-tab cooperation! A tampermonkey script has no effective cooperation method at all. A Chrome extension can partially do so, but only asynchronously using a so-called background page, but that doesn't work across the regular-incognito boundary, and many gameplayers will use an incognito tab for a separate session to do things such as refounds. I'm not familiar with the Mozilla stuff but I presume the situation there is not much different from the Chrome situation.

EDIT: This would affect a significant number of users - the 151 users of Breeze++, the 208 users of the original NSBreeze that Breeze++ is based on, several endorsement swapping helpers, etc.etc.etc.

Now, for keybinds that just press specific buttons provided by NS, that's not solved by simply switching to XHR (i.e. "AJAX requests"), because those are a different kind of thing. XHRs will send an asynchronous request to fetch data within the context of the current page, while clicking a button or link (such as Endorse) will send the user to a new page. The situation described here, if considered problematic, could be mitigated by unregistering or disabling keybinds when the document.[before]unload event fires.

[Vincent Drake]

Hey R3n, I'm the author of Breeze++ and I'm sorry that you were unable to determine who maintains the script. I try to be as reachable as possible, my name is on the Chrome Store listing as the developer and my Discord contact info is prominently placed in the description, above the keylist. In a raw source code dump, my name and contact info are still available in the README file. Authorship and maintainer status can additionally be determined via Google search or NS forum search. Obviously, reachability for questions and concerns about the script is important, so I will consider ways to improve upon this in the future.

When Breeze++ was first being developed, I reached out to admin onsite to determine how keybinds would be treated, specifically the refresh feature (N key). The N key above all others is special in the way it's intended to be used and what it can do, reloading the page in rapid succession if you so choose to keep hitting the key during update. I was confused about whether this would be legal, so I asked about it. [v]'s ruling at the time was:

by [violet] » Mon Feb 20, 2017 9:56 pm

Caelapes is right. If your tool simply remaps and doesn't actually create a request itself, that's fine. If it makes its own requests, you need to avoid making simultaneous ones.

At the time, I was under the impression that the simulteneity rule did not apply to straight remapping, as stated directly by a game admin. The script does not create its own buttons or forms or submit its own requests. Breeze's additional features were added with this statement in mind - a keystroke lets a user hit native NS buttons, not creating its own requests, so we were good to go I thought.

At some point around late July or early August in 2017, I have credible reason to believe that Breeze++ was GHR'd and the people who did were told that the script was fully legal. Is it possible to check if this event actually occurred and what the outcome was?

FWIW, Breeze was intended to be used in one tab as an update script, endotarting in tabs is outside of what was expected. Its usage has clearly shifted in ways I failed to predict or think of in Feb 2017. Thing is, there are no tracking metrics in Breeze, other than the Chrome Store telling me how many active installs there are. I have no way of knowing who is using it and for what. I have no way of excluding anyone from installing it. I have no way of knowing that people have found ways to use it that potentially violate rules - that's what the contact info is for. It's not possible to install it without seeing who made it. Please, please tell me about off-spec usage so I can make changes if necessary.

Obviously, rule clarifications would be great so I know whether the script needs to be amended, rewritten, or discontinued. It was developed under the explicit understanding that the things it does were legal, so for the goalposts to move is disappointing.

[[violet]]

The script does not create its own buttons or forms or submit its own requests.

Okay, that's not what I was imagining in the original "keybindings script-assisted case" hypothetical. I thought we were talking about a script that generated requests. A browser tool that doesn't create requests but simply wires up a key to trigger() on a native button is a bit different--if that's the whole tool, it isn't responsible for managing what the native button does.

I could potentially imagine ruling a tool illegal if it co-ordinates multiple trigger()s in a way designed to perform simultaneous requests. Or, of course, if it called fetch() / get() / etc itself. But not what is described above.

Eluvatar's elaboration on how the simultaneity rule is to be abided by states that "It is illegal to generate and use a page with multiple forms pointed at nationstates.net if you can submit the forms in parallel".

Does this not therefore mean that the rule already only applies to individual tabs?

I'm missing how you get that interpretation. I may be missing what Elu meant, too. But he doesn't seem to be saying anything about multiple tabs. He's discussing a particular situation relating to multiple forms. What we're discussing now seems like a new question, about whether a tool has to be responsible for avoiding simultaneity with other instances of itself running in other tabs (or other browsers, or on other devices...).

Could somebody please clarify for me if there are any situations in which Breeze (a script of this type) can perform multiple restricted actions using a single tab without having to wait for a new page to load fully? For example, are there two keybindings for endorsing and ejecting a nation that you could effectively use before that nations' page reloaded?

Yes, this would be good to clarify. The current rule is built on the assumption that a form submission click (like endorsing a nation) ends the user's activity on that page, and they have to wait for the page to reload before they can do something else. If a tool allows them to act so quickly that they can perform multiple actions before page unload, we probably need to address that.

I think it would also be helpful to clarify what happens to those who have already violated the rule (as per this discussion) using one of the available keybinding tools across multiple tabs, in the way I described above.

This is the kind of thing that makes admin reluctant to answer hypothetical questions. You jumped from "what if a user did this" all the way to "how will these people be punished" in one step. It's fairly common for admin to interact with the authors of scripts that are breaking the rules and work with them on fixing those errors, because it's easy to do so inadvertently and despite the author's best intentions. The Predator situation referenced in the linked thread was very different.

Anyway, by way of summary, at the moment it seems to me that we want:

• statement in official rules that simple keybindings & CSS modifications don't count as "generating requests," even if they're moving buttons or mapping keys to them -- which is de facto current practice, but not articulated
• statement in official rules that tools designed to operate within a single browser tab aren't responsible for avoiding simultaneity with other tabs / instances -- which I don't think we've properly considered before

[Escade]

Am I getting banned for using Breeze? I mean I use it because I really don't know what I'm doing sometimes and it is useful. Also I have no clue what any of the technical discussion means just nervous tension here with all this discussion here and elsewhere.

[[violet]]

Am I getting banned for using Breeze?

No!

IIRC we've only ever banned people for script rules violations twice, which were extreme cases that don't have much in common with anything I've seen so far here.

Standard practice for resolving script problems is to work with the authors to fix it, which is what's happening now.

[Escade]

Am I getting banned for using Breeze?

No!

IIRC we've only ever banned people for script rules violations twice, which were extreme cases that don't have much in common with anything I've seen so far here.

Standard practice for resolving script problems is to work with the authors to fix it, which is what's happening now.

Thank you so much for clarifying, it's a relief to me and I'm sure others.

[McChimp]

I'm missing how you get that interpretation. I may be missing what Elu meant, too. But he doesn't seem to be saying anything about multiple tabs. He's discussing a particular situation relating to multiple forms. What we're discussing now seems like a new question, about whether a tool has to be responsible for avoiding simultaneity with other instances of itself running in other tabs (or other browsers, or on other devices...).

If the rule specifically bans generating and using pages containing forms that can be submitted in parallel (using a script) then multiple tabs are permitted because although you may have generated multiple pages, no individual one contains forms that can be submitted in parallel.

It seems fair to me to rule that scripts actuating native game buttons doesn't count as "creating requests" and is therefore not subject to the simultaneity rule. Please do clarify whether scripts that actuate the game's native buttons in order to perform restricted actions are responsible for ensuring that two such buttons cannot be actuated before a page unloads. Within a single tab, of course.

[Panagouge]

You can use keyboards shortcuts to help hasten the process, however, such as 9003's Hotkeys (too lazy to find the link right now).

[United Calanworie]

You can use keyboards shortcuts to help hasten the process, however, such as 9003's Hotkeys (too lazy to find the link right now).

This thread is three years dead. Why on earth did you dig it up? iLock.