Privacy & information for IRBs

DataPipe is a free, open-source service run by the developers of jsPsych. It moves data out of a participant's browser and into a storage account that you already control. It is a pipe, not an archive: your data lives in the storage account you connect, not in DataPipe.

A submission takes one path:

1. The participant's browser sends the data over HTTPS to pipe.jspsych.org/api/data.
2. DataPipe's server checks that the experiment exists and is accepting data, applies any validation rules you set, and — if you turned on Psych-DS metadata — reads the submission to build column descriptions.
3. The server writes the file into the storage location you connected (e.g., a Google Drive folder, a Dataverse dataset, or a Zenodo deposition), over HTTPS.

Under normal operation all of this happens in seconds, and DataPipe keeps no copy afterwards. The exceptions — a temporary copy held during the transfer, and a longer-lived copy when your provider is unreachable — are described below.

DataPipe receives whatever your experiment chooses to send. It has no way to know whether that content is identifiable, and it never sees your consent form, your protocol, or your recruitment materials. Deciding what leaves a participant's browser is entirely yours.

The server reads a submission for two reasons only: to run the validation rules you configured, and to generate Psych-DS metadata if you enabled it. No person reads a submission in the ordinary course of running the service, and no part of a submission is written to DataPipe's logs.

The condition-assignment feature (/api/condition) receives only an experiment ID. It returns a condition number and increments a counter; no participant data reaches it.

IP addresses. DataPipe's own code never reads, stores, or forwards a participant's IP address or browser user agent, and neither is written to your experiment log or sent to your storage provider. Requests do pass through Google Cloud's infrastructure, and Google keeps its own request logs, separate from DataPipe; those are retained for 30 days (the Google Cloud default for the DataPipe project) and are not accessible to you through DataPipe. Because IP addresses appear in those infrastructure logs, data collected through DataPipe is normally described as de-identified or pseudonymous rather than anonymous.

1. A temporary copy of each submission. Before DataPipe sends the file to your provider, it saves the submission to a private Google Cloud Storage bucket, so that an interruption during the transfer cannot lose a participant's session. That copy is encrypted (see below) and is deleted as soon as the file is safely in your storage — normally within the same second.
2. Trials staged during a session, if your experiment uses incremental upload. Experiments that switch this on send each trial to DataPipe as it is produced, so that a participant who closes the tab partway through does not lose everything they did. Those trials are held in a private database, unreadable by any browser — including the one that wrote them — and are deleted the moment the participant's submission completes, normally within minutes. If the participant never finishes, DataPipe stores what it received as a separate partial file in your storage and then deletes the staged copy. Unlike the two copies above, these trials are not encrypted by DataPipe itself — see Encryption. Incremental upload is off unless your experiment's code asks for it.
3. A record of each session in progress, for your dashboard. While a participant is part-way through a streaming experiment, DataPipe keeps a small record of when their session started and whether their connection is live, so your experiment's dashboard can show it. It holds no participant data and no filename, only you can read it, and it is deleted when the session ends.
4. Queued submissions. If your provider is unavailable, too busy to accept the file, or rejects it, the submission is held in the same private bucket, encrypted, and retried on a schedule. You can download it from your dashboard in the meantime. A queued submission is deleted seven days after it was queued — or up to fourteen if DataPipe could not deliver the failure notification to you, whether or not the retries succeeded, along with its queue record.
5. Dataset metadata, if you enable Psych-DS metadata. The metadata document DataPipe keeps for an experiment describes each column in your data — and for columns that are not numeric it keeps a list (called levels) of every distinct value it has seen in that column. For numeric columns it keeps the minimum and maximum. There is no cap on how many distinct values are recorded. So if a column holds free text, an email address, or a participant identifier, those values are recorded in the metadata document, which persists for the life of the experiment rather than for a matter of days. Psych-DS metadata is off unless you switch it on per experiment.
6. Your experiment's configuration and its log. The log records how many requests of each kind the experiment received and how they turned out, which storage provider it is configured for, when it was created, when it last received a request, a tally of errors by type, and the fifty most recent errors with timestamps. Older error entries are discarded as newer ones arrive; the tallies are not. No participant data is written to it. An error entry can, however, contain the filename your experiment chose and the error message your storage provider returned.
7. Your researcher account. A sign-in record (your email address and the method you signed in with), the list of experiments you own, a notification email address, and your storage provider credentials. The record of each notification email DataPipe sends you exists to manage its delivery, and is deleted seven days after the email is sent.

For providers that limit how many files they will hold, DataPipe periodically merges older session files into a single archive inside your storage, and it can do the same on request when you finalize an experiment. Doing that means downloading your own files back out of your provider, combining them on DataPipe's server, and uploading the archive before deleting the originals. The files are held only for the duration of the merge and are not retained.

• Temporary copy of a submission: deleted when the file reaches your provider. Anything left behind by an interrupted transfer is swept up within about fifteen minutes and moved into the upload queue.
• Trials staged during a session: deleted when the session's submission completes. An abandoned session is collected within about fifteen minutes, stored as a partial file in your storage, and the staged copy deleted. Any session that is never collected is removed twenty-four hours after it started.
• Record of a session in progress: deleted with the session, on the same schedule as its staged trials.
• Queued submission: deleted seven days after it was queued, extended to at most fourteen while a failure notification is undelivered.
• Psych-DS metadata document, experiment configuration, session count, and experiment log: kept for as long as the experiment exists.
• Notification email records: deleted seven days after delivery.
• Account record and stored provider credentials: kept until you delete your account.

Deleting your account removes all of the above in one pass — experiments, metadata documents, logs, queued submissions and their stored files, filename records, records of sessions in progress, notification records, and the account itself. It removes nothing from your storage provider; your data stays where you sent it.

Deleting a single experiment removes its configuration, log, and metadata document. It likewise leaves your provider untouched.

In transit. Requests to pipe.jspsych.org are served over HTTPS. Every call DataPipe makes to a storage provider is over HTTPS, and DataPipe will not connect to a Dataverse server unless its address uses https.

At rest, by DataPipe. The copies of a completed submission that DataPipe holds — the temporary copy and a queued submission — are encrypted with AES-256-GCM before being written, using a key held only by DataPipe's server. Your storage provider credentials — the tokens that let DataPipe write to your storage — are also encrypted with AES-256-GCM before being written to the database.

Trials staged during a session are the exception, and it is worth being plain about why. They are written by the participant's own browser, which has no key and cannot be given one — a key shipped inside an experiment's JavaScript is a key every participant holds, which is not encryption. So those trials rely on the platform encryption below plus access rules: no browser can read that database at any depth, not even the one that wrote the session, and each session is reachable only through an unguessable identifier that DataPipe issues. They are deleted as soon as the session completes.

At rest, by the platform. DataPipe runs on Google Cloud, which encrypts stored data at rest by default underneath everything above. See Google Cloud's default encryption at rest.

Access rules. DataPipe's storage bucket refuses all direct access; only DataPipe's server code can reach it. In the database, an experiment, its log, its metadata, and its queued uploads can be read only by the account that owns the experiment.

This is transport encryption plus encryption at rest. It is not end-to-end encryption: the server necessarily reads each submission in order to validate it and pass it on.

DataPipe is operated by the developers of jsPsych and hosted on Google Cloud through Firebase. Google Cloud is DataPipe's infrastructure provider; DataPipe uses Resend to send notification email to researchers — never to participants.

A small number of project administrators have administrative access that can reach anything DataPipe stores — the temporary and queued copies of submissions, metadata documents, experiment logs, and encrypted provider credentials. That access exists to operate and debug the service, and it is not used for research, analysis, or any other purpose. We would rather state this plainly than claim we cannot see your data.

Once a file reaches your storage provider, DataPipe's access is only what you granted it. For Google Drive, DataPipe can only reach the files and folders it created or that you picked — not the rest of your Drive. For Dataverse, it uses an API token you issued and can revoke. For Zenodo, it uses the authorization you granted. You can disconnect any provider from your account settings at any time.

For a Google Drive connection specifically, what DataPipe keeps is an OAuth refresh token, encrypted at rest, and the identifier of the folder you picked — nothing else about your Drive. Disconnecting Drive from account settings deletes that token and asks Google to revoke DataPipe's authorization; deleting your account does the same. You can also remove DataPipe from your Google Account at any time, independent of DataPipe, from your Google Account permissions page.

Who can see the data at rest is set by your provider, and DataPipe changes none of those settings: a Drive folder is private until you share it, a Zenodo deposition is a private draft until you publish it, a Dataverse dataset is a draft until you publish it.

DataPipe's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

• DataPipe does not sell, rent, license, or share participant data with any third party.
• DataPipe does not use participant data for research, analytics, product development, model training, or advertising.
• DataPipe claims no ownership of, and no rights over, the data that passes through it. It is yours and your institution's.
• DataPipe does not add tracking or analytics to the requests your experiment makes, and its API sets no cookies.
• DataPipe never contacts participants. It holds no participant contact information unless your experiment put some into the data.

Institutional security reviews frequently ask for these, so here is a direct answer. DataPipe is a small, free, academic service. It holds no independent security certification: no SOC 2, no ISO 27001, no FedRAMP authorization, and no HITRUST. It has not been independently penetration tested. It is not HIPAA compliant and no business associate agreement is available, so DataPipe should not be used for protected health information.

The underlying infrastructure carries its own certifications — see Google Cloud's compliance offerings — but those belong to Google, not to DataPipe.

If your protocol involves participants in the EU or UK: you and your institution are typically the data controller for participant data, with DataPipe acting as a processor on your instructions; DataPipe is the controller only for your researcher account information. Whether that arrangement satisfies your institution is a question for your institution, not for us.

DataPipe has no view into your study design, so several protections can only be applied by you.

• What your experiment transmits. We strongly recommend not sending direct identifiers through DataPipe at all. If your study does not need a name, an email address, or an IP address, do not collect one.
• Filenames. The filename your experiment chooses is visible in your storage provider and can appear in an error entry in your experiment log. Keep sensitive identifiers out of filenames and put them inside the data instead.
• Whether to enable Psych-DS metadata. See the levels note above: with metadata on, observed values from non-numeric columns are recorded in a document that lives as long as the experiment.
• Where the data comes to rest, and who can see it there. Choosing a storage provider your institution permits, and setting that provider's sharing permissions, is yours alone.

Your storage provider has its own privacy policy, and it governs the data once it arrives: Google, Zenodo (hosted by CERN, in Switzerland), and — for Dataverse — the policy of the specific installation you use, since each is run by a different institution. Experiments still writing to the Open Science Framework are governed by the Center for Open Science privacy policy; DataPipe no longer accepts new OSF experiments.

DataPipe runs on Google Cloud Platform through Firebase. Its servers run in Google Cloud's us-central1 region, and its database and storage bucket are in Google's US multi-region locations. All of it is inside the United States, and the service is operated from the United States.

Your data does not come to rest there. It is written straight through to the storage provider you chose, which may be in a different jurisdiction entirely — Zenodo is hosted by CERN in Switzerland, a Dataverse installation is wherever its host institution runs it, and a Google Drive folder follows your own Google account. If data residency matters to your protocol, the provider you pick is the decision that settles it.

If you believe data handled by DataPipe has been exposed, or you have found a vulnerability, email the DataPipe team at datapipe@jspsych.org rather than opening a public GitHub issue.

Adapt the paragraph below. Replace the bracketed parts, and delete anything that does not describe your study.

If something here does not answer your reviewer's question, ask. Open an issue in the GitHub repository or use the address on the contact page. Further detail on what DataPipe stores and logs is in the documentation.