when are JATOS cookies cleared?

[beckyann...@gmail.com]

Hi all!

On the data privacy and ethics page in the docs, there is a section on cookies: http://www.jatos.org/Data-Privacy-and-Ethics.html#cookies-used-by-jatos 

For the first cookie type (JATOS_IDS_*), I'm wondering whether this cookie is cleared when the browser tab is closed? Or does it persist after that? If I've understood correctly, I think this cookie is used during a study session but isn't needed after the study has been completed or the page has been closed. The description says "The cookie virtually never expires", but I don't know refers to an expiration that applies only while the study session is unfinished and page is open, or after that as well.

And just to confirm: the second cookie type (JATOS_GENERALSINGLE_UUIDS) is persistent and will remain on the worker/participant's computer until they manually clear their cookies. Is that right?

Thanks!

Becky

[Kristian Lange]

Hi Becky,

Let me go in more detail here than is necessary: you probably know most of this - but others might not. 

Short answer: Both cookie types are set to expire far, far in the future (10,000 days to be precise). There is no indefinite cookie, so setting them to a future day is the closest thing. Additionally JATOS_IDS_* gets deleted when the study run is finished.

Long answer:

The JATOS_GENERALSINGLE_UUIDS cookie stores the IDs of studies that have been done with the General Single worker. The reason behind is to prevent multiple runs of the same study (which the General Single worker does not allow). Ideally this cookie should never expire. Of course the worker can just go to a different browser or delete the cookie. This is not a safe method to prevent multiple study runs - use Personal Single for this. 

Then the JATOS_IDS_* cookies pass on some data from the JATOS server to jatos.js that can be used by the study's JS. Additionally it's needed to request the init data from JATOS for this study run, e.g. study/batch/group session data (basically everything that is too large or sensitive to be put into a cookie). Participants usually run only one JATOS study at the same time in the same browser and this needs only one JATOS_IDS_*. The reason why there are actually up to 10 of those, JATOS_IDS_0 ... JATOS_IDS_9, is that during study development you often want to play around with more then one study run and without necessarily finishing all other runs. And for development of group studies this is actually essential: you can run a group study in the same browser (with up to 10 members). When a study run is properly finished (State FINISHED) the corresponding cookie is removed. Sometimes this does not happen because the study was never properly finished. In those case the cookie stays in the browser until at one point it will be overwritten by a new study run cookie (always the oldest JATOS_IDS_* gets overwritten if there is no empty slot). 

I thought about turning the JATOS_IDS_* cookies into 'session' cookies that are automatically deleted when the browser is closed, but there is a use case for keeping them: components that are reloadable (and their study run) can be continued even if a browser was closed and reopened. With the data from the JATOS_IDS_* cookie jatos.js can load the proper data and the study run can continue at least with the same component and with some usage of the batch session even from the exact same point from when the run was left.

Best,

Kristian

[beckyann...@gmail.com]

Hi Kristian,

Thanks very much for the very quick and helpful reply, as always!

And I completely forgot that participants are able to resume a study that was closed early - I should've realized that this means that the JATOS_IDS_* cookies are not 'session' cookies that are automatically deleted when the page is closed. I do think that this use case outweighs any potential benefit of using normal session cookies, so thanks for leaving it this way. 

Thanks again,

Becky

On Thursday, 17 September 2020 at 03:35:06 UTC-7 Kristian Lange wrote:

Hi Becky,

Let me go in more detail here than is necessary: you probably know most of this - but others might not. 

Short answer: Both cookie types are set to expire far, far in the future (10,000 days to be precise). There is no indefinite cookie, so setting them to a future day is the closest thing. Additionally JATOS_IDS_* gets deleted when the study run is finished.

Long answer:

The JATOS_GENERALSINGLE_UUIDS cookie stores the IDs of studies that have been done with the General Single worker. The reason behind is to prevent multiple runs of the same study (which the General Single worker does not allow). Ideally this cookie should never expire. Of course the worker can just go to a different browser or delete the cookie. This is not a safe method to prevent multiple study runs - use Personal Single for this. 

Then the JATOS_IDS_* cookies pass on some data from the JATOS server to jatos.js that can be used by the study's JS. Additionally it's needed to request the init data from JATOS for this study run, e.g. study/batch/group session data (basically everything that is too large or sensitive to be put into a cookie). Participants usually run only one JATOS study at the same time in the same browser and this needs only one JATOS_IDS_*. The reason why there are actually up to 10 of those, JATOS_IDS_0 ... JATOS_IDS_9, is that during study development you often want to play around with more then one study run and without necessarily finishing all other runs. And for development of group studies this is actually essential: you can run a group study in the same browser (with up to 10 members). When a study run is properly finished (State FINISHED) the corresponding cookie is removed. Sometimes this does not happen because the study was never properly finished. In those case the cookie stays in the browser until at one point it will be overwritten by a new study run cookie (always the oldest JATOS_IDS_* gets overwritten if there is no empty slot). 

I thought about turning the JATOS_IDS_* cookies into 'session' cookies that are automatically deleted when the browser is closed, but there is a use case for keeping them: components that are reloadable (and their study run) can be continued even if a browser was closed and reopened. With the data from the JATOS_IDS_* cookie jatos.js can load the proper data and the study run can continue at least with the same component and with some usage of the batch session even from the exact same point from when the run was left.

Best,

Kristian