Data processing

Who is who

On the hosted service

• Controller: you, or your institution. You decide what personal data goes into the system, why, and for how long. If your review involves human-subjects data, your existing ethics approval governs it.
• Processor: Dhrubojyoti Saha, who operates the service and wrote the software. Processing is limited to running the application for you — there is no analytics, no profiling, no advertising, and no use of your research data for any purpose of ours.
• Sub-processors: Vercel (application hosting) and Supabase (managed PostgreSQL and authentication). Both are named here rather than in a list you have to request.

On your own copy

• Controller: you. As above.
• Processor: also you. The software runs under your administration and nobody else holds credentials to your instance.
• The author of this software: neither. No telemetry, no analytics, no error reporting, no phone-home. There is no code in this project that sends anything about your usage anywhere, and you can verify that rather than take it on faith.

Where your instance reaches out

Three categories of outbound traffic exist in both deployments, and an ethics committee will want each of them named.

• Bibliographic search. Using the search screen queries OpenAlex, Crossref, arXiv, Europe PMC and Semantic Scholar. What leaves is your query string and the server’s IP address. These are public scholarly indexes; no project data, no member identity and no screening decision is sent. If even the query is sensitive, use import instead of search and no request is made.
• Email delivery. Sign-in codes are emailed. On the hosted service that goes through Supabase’s mail provider, which sees the recipient address and the code. Running your own copy locally, it goes to a mail catcher on your machine and leaves nothing; point it at a real mail provider and that provider becomes your sub-processor.
• Google Workspace, only if connected. Nothing touches Google until a project member deliberately connects an account. From then on, documents in that folder are held by Google under Google’s terms, in that member’s Drive — outside this application’s boundary entirely, and readable by Google. The scope requested is drive.file, which reaches only files this app created or the member explicitly picked.

Which data is which

The distinction that matters most for a risk assessment is not “encrypted or not”, it is who can read it. On the hosted service the answer for the middle tier is the operator and the sub-processors above; self-hosted, it is your own database administrator. Either way it is a real answer and it should go in the assessment.

• Unreadable to the server, in both deployments: project messages, direct messages and LaTeX sources. Sealed in the browser under keys derived from a passphrase the server never holds.
• Readable to whoever administers the database: membership and roles, screening decisions, annotations, extracted answers, and the activity log. This has to be readable — sorting, counting and the PRISMA diagram are all work done on it.
• Public by nature: paper titles, DOIs, authors and venues.

The security page has the full table and the threat model behind it. If your corpus composition is itself sensitive — which paper set a lab is reading can leak a research direction before publication — that is the fact that should decide between the two deployments.

Rights, retention and deletion

The app has project deletion, account deletion and export to CSV and Excel, so access, rectification and erasure requests can be satisfied through the interface on either deployment. Self-hosted, you hold the database and SQL covers whatever the app does not.

Account deletion anonymises rather than erases, and the difference matters to an assessment. Email address, display name, avatar, ORCID, affiliation and every encryption key are destroyed; the user record itself survives, carrying the person’s screening decisions, extractions and annotations under the label “Former member”. It has to: a review must be able to answer “who excluded these forty papers, and when” a year later, and that answer cannot be removable by one of the people who gave it. Treat it as pseudonymisation under Article 4(5), not erasure under Article 17.

No retention period is imposed by this software: nothing expires, nothing is archived on your behalf, and nothing is kept after you delete it. On the hosted service, backups are the operator’s to schedule and purge; on your own copy they are yours.

One exception is worth stating because it surprises people: deleting a user does not make previously sent encrypted messages readable or unreadable to anyone else. Removing a member — or a member deleting their own account — flags the project key for rotation rather than rotating it there and then: the rotation happens in a browser, when one of that project’s admins next unlocks it, because the server holds no key to rotate with. There is a window, and it is as long as it takes an admin to visit.

If you need a signed agreement

The hosted service is run by one person as academic infrastructure, not by a company with a legal department. If your institution requires a countersigned data-processing agreement, an audit right or a specific breach notification window before you can use it, the honest options are to ask — dhrubojyoti.saha@g.bracu.ac.bd — or to run your own copy, where no agreement is needed because no third party is processing anything.

Not legal advice

This page describes where data goes. It is not a legal opinion and it is not a substitute for your institution’s own review. If your privacy office needs something in a particular form, the factual detail they will need is here, on security, and in the privacy policy — and the source is available so they can check any of it.