Study got replaced with random other study on JATOS server at mindprobe

simon_ruch

About a year ago, I set up an experiment on mindprobe for demonstration purposes (de-activated data logging). Today, I checked whether my demonstrator experiment is still running. Unfortunately, It seems that my experiment has been replaced by a totally different experiment that is in Russian (instead of German). Does anyone have any idea how this could have happened? Has mindprobe been hacked, or is this just an internal error in the database?

Of course, I can just set up a new experiment. No data has been lost. However, I think it would be important to figure out what happened here. Has anyone had similar experiences?

elisa

Hi, weird indeed. Just a few initial questions. How did you access the study? By logging in to mind probe, or via a study link?

Did you share this study (the exported .jzip) publicly? Each study had a UUID (a unique identifier). If somebody downloads the study, modifies it (including assets, HTMLs, etc) and uploads it on to the same server, it will overwrite the previous version of the study with the same UUID. Still this should not have happened if the person uploading it did not have access to your original study but it will help us understand where the problem happened.

kri

I agree with elisa, this is weird indeed and has never happened before to my knowledge. And as far as I am aware Mindprobe's JATOS server has not been hacked. Can you please give me the UUID of this study, then I can have a look whether I see something that might have caused this issue. But what elisa wrote, that your study might have been overwritten, is one possibility. But this would only happen if the user overwriting your study is a member user of this study.

simon_ruch

No, I did not share the jzip publicly. What I shared publicly is the study link:

https://jatos.mindprobe.eu/publix/run?code=ByKh7jLRAWF

The UUID is: 2ea54296-bd27-4003-a9d7-fa86f8bf74de

I am the only user with access. The incorrect study appears both when accessing it via the above link, as well as when accessing it from within mindprobe (via the play button). I downloaded and checked the jzip file - it looks totally foreign to me. So my jzip file must have been replaced somehow.

kri

Hi Simon,

Thanks for your patience while I looked into this. I've dug into it, and it turns out you were right about the wrong study assets folder. It seems there are two studies using the same folder: yours and one in Russian. The Russian study came later in time and somehow managed to use the same study assets folder name and overwrite your assets folder, something that should be prevented by JATOS. That's a flaw in JATOS, and I'm really sorry about it.

The good news is that this should only affect the assets folder, not any of your study's result data, result files, or properties.

I think I've figured out why this happened. In JATOS, you can change your study's assets folder name. Normally, this just renames the folder, but there's a checkbox that lets a study point to a completely different folder that might already exist. It's a handy feature if you want to share assets between related studies, but it looks like it can be used to "kidnap" another study's folder and overwrite it.

I checked all the studies in Mindprobe and found about 34 others (out of around 7,500) that somehow use the same assets folder. I'm guessing in some cases it was done on purpose, but in yours, it definitely wasn't.

My plan now is to fix this problem in JATOS. I'm looking at a few options:

• Scrap the feature: We could just get rid of the option to manually change the assets folder name.
• Add a safety check: We could add a check to make sure you can only point to a folder that already belongs to one of your other studies.
• Automate everything: A more drastic but safer option would be to have JATOS automatically assign a unique folder name (like the study UUID or study ID) and not let users assign/change it at all.

I'm currently leaning toward a combination of the last and first options. It's the safest and most straightforward solution. However, it might be confusing for users who are accustomed to being able to use descriptive folder names instead of something like e8dc1f32-3c6c-406f-81cb-ac4c96a07cfd, which can be difficult to work with. What do you think?