I use a variation of Conti and Caroland (2011)’s “memorize the first 100 digits of pi” assignment as an in-class learning activity to teach my infosec students how to cheat, as part of teaching threat modeling. This semester at the beginning was all-remote for me, though, so I modified it for the zoom teaching session. Instead of having all students write down the first 100 digits of pi and then submit their papers to me, I instead told students the following:
Your assignment is to memorize the first 100 digits of pi having been intentionally given so little time to do so that your only chance of completing the assignment is to cheat. I authorize you to cheat on this assignment and only this assignment, but if I catch you cheating, you lose.
It will go something like this (subject to change): at the start of the next class, I will randomly sort the class roster, and then I will go down the list and call on people one at a time to recite to me the first 100 digits of pi. I may ask you to share your screen, and also to pan your camera about the room (be prepared!), simulating what proctor-monitoring software would do. The grading is pass/fail. If we run out of time before you are called on, you pass by default.
Again, I expect you to cheat. How you choose to cheat is entirely up to you. Collaborative cheating is also encouraged, but everyone involved will lose the game if caught. At the completion, I will give you opportunities to share-and-tell your cheating techniques with the class.
The objective of the exercise is to learn how an adversary thinks and operates by deliberately loosening traditional rules and tapping personal creativity. It is an exercise in threat modeling.
I am only permitting you to cheat on this single quiz. You may not cheat on any other assignments for this class.
It was really fun. Nearly all pressure was off because I changed the language to say that they would “lose” instead of “fail” if they got caught. In practice, everyone who made a legitimate good-faith effort “passed.” If they made a legitimate attempt. When we did it, I invited all other students to help me try to catch the presenter cheating. They would submit suspicions via zoom chat. I would interrupt the recitation if I suspected cheating, and sometimes I asked them to do random challenges such as turn around and continue reciting the numbers, or re-pan their camera to a certain position in the room. After I announced a pass or lose, I asked each student to explain their technique, and we discussed. This interstitial kept engagement high, I think.
Some students still passed. One had taped the numbers in three different places around the room, anticipating that I might ask her to turn around. Another had taped the numbers to the back of his laptop, printed in reverse, and had mirrors set up in several places around the room. One student had an extra pair of earbuds on under his over-the-ear phones, and had a button on his phone that would play a recording of the numbers to him. Another student pre-recorded a video of himself reciting the numbers, which obviously didn’t work well at all with interruptions, but was still fun.
Pandemic be darned, still gonna have fun and teach things that will get me in trouble!
G. Conti and J. Caroland, “Embracing the Kobayashi Maru: Why You Should Teach Your Students to Cheat,” in IEEE Security & Privacy, vol. 9, no. 4, pp. 48-51, July-Aug. 2011, doi: 10.1109/MSP.2011.80.
David Eargle is an Assistant Professor at the University of Colorado Boulder in the Leeds School of Business. He earned his Ph.D. degree in Information Systems from the University of Pittsburgh. His research interests include human-computer interaction and information security. He has coauthored several articles in these areas using neurophysiological and other methodologies in outlets such as the Journal of the Association for Information Systems, the European Journal of Information Systems, the International Conference on Information Systems, and the Hawaii International Conference on System Sciences), along with the Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI). More about the author →