mterwill
Queue sign-ups vulnerable to exploitation by autoclickers
Howdy!
I'm writing from the 482 course staff. Since 482 OH help is in such high demand, it's common for students to camp the queue and wait to sign up the instant it opens. Since at least F19, we've been seeing students using autoclicker scripts and other trickery to guarantee a top spot on the queue, and that trick has started proliferating among the student body.
One approach that's been described to me is:
- Using "Inspect Element" to make the "Request Help" button extremely large,
- Positioning the mouse over the button,
- Running an AutoHotkey script that spams mouse-clicks as fast as possible (>>1000Hz).
When the queue opens, the "Request Help" button shifts down slightly, but (1) guarantees that the button is still under the click-spamming cursor.
Pretty much any autoclicker can sign up faster than a normal human, so a script user's only real competition comes from other students using autoclicker scripts. We're worried that this creates an equity issue: if ~six 482 student groups use autoclickers, than a group that only signs up "fairly" will enqueue no higher than position 7, with an expected wait time of ~an hour.
I've brainstormed this a little bit with the other staff. We're thinking that potential front-end solutions might involve:
- Making the "Request Help" button "sticky," so that (e.g.) it could only be pressed once per second, with faster clicks only resetting its "time-remaining-till-unstick",
- Guarding the sign-ups with a Captcha, at least right when the queue opens,
While back-end solutions might involve:
- Rejecting "false starts" that arrived <100ms (or so) after the queue opened, since those could only have come from scripts or from a student click-spamming the button,
- Taking any requests that arrive between (say) 100ms-200ms after the queue opens, or even up to 30 seconds after the queue opens, and "scrambling" them.
I'm personally leaning towards a combination of (3) and (4), since that'd be proof against more advanced scripts (that, e.g. attach callbacks to the DOM that trigger "Request Help" as soon as the button changes color). A long-interval (4) might also make queue sign-ups less stressful, since it'd be random, dispassionate, and fair to all students who arrived before the queue opened.
Any thoughts on this? I'm intentionally taking a light courseload this term to have more time for IAing, so I could also try to work on this if that would be helpful.
Thanks in advance!
I think option four is the best approach to this issue. The first option will still ensure scripters get in first, since they only need to press the button once to register. Captcha is a bit unnecessary and could cause problems on its own behalf. And students could have their script sleep (100) and then have it press the button, still faster than any normal human being would be able to do.
Hey @Yilin-Yang, sorry I missed this! Thanks for the detailed issue writeup. 🙏
I like the idea of something like this:
Taking any requests that arrive between (say) 100ms-200ms after the queue opens, or even up to 30 seconds after the queue opens, and "scrambling" them.
What are your thoughts on making this a manual action available to instructors, as opposed to automatic? We could add a "scramble queue" button to the instructor panel with the rest of the controls.
We also experienced suspected Autoclicker issues deploying the queue at Caltech. I implemented an invisible ReCAPTCHA protecting the "Request Help" button, but had to roll it back due to strange issues that it produced (probably due to something I broke).
When the invisible ReCAPTCHA was active, we experienced no anomalous requests, but I'm not sure if that was caused by deterring autoclickers with the little ReCAPTCHA badge that shows up in the corner of the screen.
A feature that would scramble the first few entrants to the queue would probably be very useful to anyone using this queue in the future.
Hi @mterwill! Sorry about the hugely delayed response.
Yup, a "Scramble Queue" button (plus "Are you sure?" confirmation dialog, etc.) would work for our needs!
I don't think that I would be able to, unfortunately, with everything that's going on. 😢 That might change over the next several months (and would probably change by early 2021-ish, if the issue is still open by then), but I'm not personally expecting it to.
Hi @mterwill! @annieli555 and I are interested in working on this issue, is it still available?
Hi!
We're brainstorming implementations for this issue right now and one of our professors suggested using reCAPTCHA as his preferred solution. Is that something you think would work or would you prefer something like the scramble requests option suggested earlier?
We can make it configurable via environment variable and add instructions to the README for anyone testing the functionality to generate their own? I can set up a production key when we’re ready.
I'm having some trouble figuring out how to integrate reCAPTCHA into the project. I was only able to find documentation online for implementations that are React or Rails only. Is there a way to import npm packages in this project or is there a particular method you would recommend?
Unfortunately we don't have npm packages set up currently. It's been a minute since I've looked at all the Rails asset pipeline stuff, not entirely sure what'd be involved there. Currently, js is vendored by hand in the vendor folder.
👋 I just opened #216 as a first attempt to address this, feedback welcome 🙂