URL of experiment:
reward on each trial I just save 1000).
How do you prevent subjects from hacking the javascript?
That’s a very tricky one, since you could hack on all kinds of levels; not just the JS but also modify the network traffic etc. One workaround that could make it a bit harder is minifying/uglifying the JS
The idea above is based on how to prevent cheating in online games. Threads about that could provide you with more tips.
https://duckduckgo.com/?q=prevent+cheating+HTML5+games&t=fpas&ia=qa
I don’t know much about how PsychoPy works online, but I do have some knowledge in working with databases/web technology. As @thomas_pronk says, it’s not really possible to entirely stop clients/users from changing javascript or anything else that is run on the client side. All you can do is turn this into more of a hassle for the users. Ultimately it’s up to users to send whatever request/data they want, though it might take more or less work for them to tweak the request.
When it comes to ensuring that no malicious data are actually stored in your database (e. g. a set of .csv files, or some other structured way to store data), a different type of question is usually more effective. Basically, you want to consider “how do I clean and/or control the data that my server receives before storing them to my database?”. Again, I don’t know much about how Pavlovia/PsychoPy does this. Ideally it would be possible to specify things like “data that are to be saved to this field (column in a .csv file) must be integers, and be in the range of 0-100”. If any of the checks fail, an error would be raised and the participant would e. g. be asked to contact you as the researcher, and you would also receive some kind of notification that things have gone awry.
Of course, stopping participants from sending malicious and/or misleading data doesn’t mean that you instead get correct data from them. But if it’s a participant who is deliberately messing with the javascript and the requests/data they are sending, it’s unlikely that they will participate as expected either way.
Thanks for your answers. We will look into minifying and other options as at least a barrier to this.
After reading a bit more on this, it seems that it impossible to prevent cheating if you do everything client side. One solution is to have only the events on the client side and the rest of the logic on the server side. This would, i imagine require a major change in the way pavlovia is written, but something that i think should be considered. In the meantime, i think that the js code for the task should be minified automatically to make it a little harder to hack.
pavlovia uses https, so hacking at the network level seems harder.
With https you can’t do a man-in-the-middle attack, but you could still craft your own network requests submitting whatever data you’d like