PG Software Development

I’m in need of a fix. A wonderful student (now that it is the end of the school year) has confessed to me that he and others have been hitting F12 on my online randomized quiz certificate pages and modifying the .html to give themselves 100% on a regular basis. He appeared to select the score field … hit F12 .. and voila … editable .html

As I run my course materials in a full-screen pop-up, Is there a way of using the AE to disable the F12 key and exit the program?

Robert,

Trapping the F12 key is probably the easy part of this scenario. Here are some other things to keep in mind:

1. You must run your course from a launch page or your students will still be able to launch the developer tools from the browser menu bar.
2. Not all browsers may prevent access to the HTML, though this seems to work in IE and Firefox.
3. If you are using an LMS, then the course results are transmitted separate from the contents of the fields in your certificate.
4. Best approach may be to encrypt your score variable using PowerPac's pgStringEncrypt() function so that even if the visual field text is compromised, the encrypted value will reveal that a student had cheated on the test.

Method: (captures F12 key down; works in all browsers)
Add this code to the On key down event for your input field or any field that permits student input. Modify what the event does when the F12 key is pressed to suit your application. I've just included some prompts in the code below to enable some basic debugging to ensure it works.
NOTE: The problem with this solution is that if you don't have an input field on your certificate page, then a student could still raise the Developer tools by pressing F12. You can rectify that by putting two of such fields on the page (and moving them off the page so that they are visible and can accept keyboard input, but at the same time are not visibly accessible to the user). Then force the focus back to the input field at regular intervals or with any key down event. The reason for using two fields set up like this is because it prevents the user from using the tab key and then pressing F12 outside the field. The result is fairly good protection from the activity you've described. I do this with a typing program that we distribute to prevent keystrokes from being entered anywhere except in the the practice typing field.

For a nominal charge, I would be glad to build a paste-in-place module that you could use to bullet-proof your courses from this kind of activity. The theory would be to use either the string encryption method (preferred) or the keyboard trapping described above, or both methods to lock down your course from tampering. However, from what I understand, all of this should be unnecessary if your courses are delivered via an LMS. But if that is not possible, then what is described in this post would be a possible way to go.

Clifton

All fascinating stuff. I do not have any input fields on my certificate page so I would have to figure out what you're up to with the two hidden fields off the page and coding for the focus shifting between the two. I do have some of my course hosted on a Moodle site and the cheating hasn't been an issue there but other issues ... such as having to manually reset all SCORM modules 20 or 30 times a day has me reluctant to put much more on that site. Of course, the "Nominal fee" has me interested as well ... perhaps you could give me an estimate?