Consider an online implementation of tnoodle

[dunkOnIT]

From Gregor's email in "Saving Scrambles to Google Drive" email thread (WRT, WRC, WQAC and WST copied):

Regarding a more sophisticated technical implementation (read: automated backups) there is one major issue: Historically, our scramble program has been designed so that offline usage is always possible. I had not been involved with the WCA in any way when the exact decision was made, but from a high-level point of view the two main arguments are: (a) venues without Internet access (b) scramble secrecy (somebody tapping into the wire to read scrambles before the comp?!)

I just want to point out that moving away from this stance would make the software implementation for the whole scramble workflow around ten times easier. TNoodle already understands and uses WCIF since the bump to version 1, and by mandating online use we could:

Save Delegates the trouble of having to install Java on their machine by hosting an instance of TNoodle for them
Sync back the WCIF with scramble sets stored in the main website (there's even a proof-of-concept for symmetric encryption of scramble strings in the TNoodle code already)
Potentially abandon scrambles-matcher altogether (significantly improving the quality of life for Delegates upon submitting results)

The only real drawback (apart from the reasoning outlined above) would be a small complication of creating additional "An incident happened!" replacement scramble sets on the fly. With an online scrambler, this would potentially involve changing the scramble set count in the "Edit Events" section of the main website while the competition is running, and going through the TNoodle workflow again.

We would also need a minor update to the TNoodle internal logic to allow incremental scrambles (only generate scrambles for stuff that isn't already scrambled) but this is a comparably low effort and I'd be happy to work on that if it means saving us from all of the pain points listed above.

[campos20]

The simplest way would be just deploy our tnoodle jar as a docker somewhere. We could easily do this in AWS using ECS or similar. I was testing something like this a while ago, the result can be seen here

https://tnoodle-web.herokuapp.com/scramble

[gregorbg]

This is not exactly what we're aiming for here. The current version of TNoodle is still running under the assumption that it can be executed offline without Internet access. This leads to several complications like the WCIF JSON being embedded into the ZIP file that Delegates have to manage independently.

Creating a "proper" online implementation entails rethinking our workflows. For example, the WCIF could be PATCHed back to the website with encrypted scrambles (or similar, it's just brainstorming at this point)

[jfly]

Historically, our scramble program has been designed so that offline usage is always possible. I had not been involved with the WCA in any way when the exact decision was made

I was around for this "decision", so I can share a little context (hopefully nothing too susprising). The answer is basically "doing anything else was inconceivable at the time":

• The scramble software that tnoodle replaced all worked offline.
• Internet access at venues in ~2010 - 2013 (when I was building tnoodle up until it was adopted as the official wca scramble program) was not nearly as sure a thing as it is today. I personally didn't have a cell phone that could tether until sometime after that.
• The WCA website as it exists today (with user accounts such that delegates can prove they're a delegate for some upcoming competition) is a relatively recent thing. (much newer than tnoodle).

I do think that a fundamental redesign could simplify a lot of the process:

• Scramble reconciliation is always a pain, and that pain (and code!) could disappear if folks are forced to be online and go somewhere to gen more scramble groups or add a round or whatever
• We could axe all of the tnoodle's careful phoning home to check if it's an "official" version
• Oracle / Java doesn't seem to be interested in helping you write desktop apps anymore. IIRC, installing a JRE on windows these days requires you to get past a modal that basically says "are you sure you need this?" in a way that is super unfriendly to non tech-savvy people. Not to mention folks on tablets and chromebooks and the like.
• I'm sure the list goes on.

Things worth considering:

• Already mentioned: scramble secrecy/privacy. Historically, a lot of members of the wca have direct access to the database (this may be dated, but back in my day: a software team with some inactive members, plus the entire results team). And this problem gets even worse if they're available unencrypted in the WCIF. We wouldn't want a random WCIF compatible tool like groupifier to have access to the scrambles for an ongoing/upcoming competition.
• I do (personally) think the WCA should to continue to provide some mechanism for non-technical folks to generate scrambles outside of the context of an upcoming WCA competition. We've seen tnoodle used for unofficial competitions (wild guesses: "You can do the cube" here in the US, Guinness, Red Bull competitions), and while supporting that sort of stuff might not be core to the WCA's mission, I think it does help cement the WCA as an authority.

[gregorbg]

Linking these two issues here for future endeavours:
cubing/cubing.js#250
cubing/twsearch#4

[timreyn]

Brainstorming on

Already mentioned: scramble secrecy/privacy. Historically, a lot of members of the wca have direct access to the database (this may be dated, but back in my day: a software team with some inactive members, plus the entire results team). And this problem gets even worse if they're available unencrypted in the WCIF. We wouldn't want a random WCIF compatible tool like groupifier to have access to the scrambles for an ongoing/upcoming competition.

what if the scrambles were encrypted with a random key, that was then emailed to the delegate's WCA email (or uploaded to Google Drive), and only the encrypted scrambles are stored on the WCA site? Then, for me to access passwords, I would need both access to the website and access to the delegate's google account. I'm not sure who has access to the google workspace admin, but it could be reasonable to disallow anyone with DB access to have access to the google workspace admin.

[gregorbg]

Encrypting scrambles is definitely possible, and (fun fact!) is already supported by TNoodle as a proof-of-concept. So syncing back base64-encoded byte arrays instead of "real" scrambles is very possible in terms of WCIF. We need to figure out whether we would want these to be:

• symmetrically encrypted, and whether the Delegate should be allowed to choose that password or whether we assign it
• asymmetrically encrypted, using the public TNoodle signature key

I'm not sure who has access to the google workspace admin, but it could be reasonable to disallow anyone with DB access to have access to the google workspace admin.

Currently, Board + WST Leader. The latter is the only person who also has DB access but in my opinion (a) it's a good thing to have an admin who has access to everything in case of emergencies and (b) at some point in the toolchain, we need to trust at least one person in the process IMO.

[jfly]

the public TNoodle signature key

What is this? TNoodle doesn't have any keys, AFAIK. Who/what would/does have the corresponding private key (and therefore, the ability to decrypt the scrambles)?

[gregorbg]

TNoodle has an RSA key pair that is used when "phoning home" to verify that Delegates aren't running self-built / self-compiled versions of TNoodle. Currently, only WST Senior Members have access to that private key.