Privacy

Last updated 2 October 2026.

This describes what IDoc records, why, where it is kept, and who can see it. It is written from what the software does. Where something is possible in the code but switched off here, this says so rather than claiming the capability does not exist.

1 Who runs IDoc

IDoc is built and operated by prosAIdon, New Jersey, for coursework at Rutgers University. Rutgers holds your education records; prosAIdon runs the platform on its behalf, as a school official under FERPA.

Questions, and requests to see, correct or delete your data: to.prosaidon@gmail.com. Write from your Rutgers address so we can tell it is you.

2 What we record

Your account: your NetID, your name, your Rutgers email address, and the date you last signed in. Your password is stored only as an Argon2id hash. We cannot read it and cannot recover it.

Your coursework: what you submit, the answers in it, the marks, and every later correction to a mark. Corrections are added rather than written over, so the history stays complete.

Sign-in events: each sign-in and failed sign-in is written to an append-only log along with the time and a shortened form of your network address. The address is truncated before it is written, so it identifies a network and not a machine.

Keystroke recording is not implemented. There is no code anywhere in IDoc that captures what you type, and no setting that would turn such a thing on.

3 Where your documents live

On this deployment your documents are not kept on our server. You choose a folder on your own computer or a GitHub repository, and your work stays there. We hold the marks and submissions for a course; we do not hold your drafts.

If you connect Google Drive, your documents live in your Drive under Google's terms, not ours.

4 Running code

Code you run goes to whichever target you pick. In the browser it never leaves the page. On your own machine it never leaves your machine. On our runner it is sent to a separate machine that has no route to the internet, runs as a non-privileged user on a read-only filesystem, and is given a fixed slice of memory and time. Nothing about a run is logged or kept: the working directory is deleted when the program ends.

If a teacher offers a Google Colab target, code sent there goes to Google.

5 AI autocomplete

Autocomplete is off until you turn it on, and nothing is sent anywhere until you do.

When you turn it on you choose the provider and supply your own key. If you choose Ollama, the text stays on your machine. If you choose Anthropic, OpenAI or Google, then each time it fires we send that provider roughly the two thousand characters before your cursor, the six hundred after it, and a short list of names defined elsewhere in your project. We do not send the whole document. What that provider then does with it is governed by their terms, not ours.

Suggestions are held in memory in your browser and are gone when you reload. We do not store them and we do not train anything on your work.

6 Marking scanned papers

Handwriting on a scanned paper is read on the marker's own computer, by a model running there. The software refuses to send it anywhere else: a reading service that is not on a private address is rejected before any request is made. The marks that come out are stored; the images are not sent to any third party.

7 Exams

During a proctored exam, and only then, we record when the exam window loses focus and when it leaves full screen. You are shown exactly this before you start. Copy and paste are blocked during an exam; blocking is all that happens, and no paste is recorded. There is no camera, no microphone and no screen capture.

8 Who can see your work

Your own workspace is yours. Other students cannot reach it.

Instructors and teaching assistants see the work you submit for their course and the marks on it. A role in one course gives no access to another. Every time a member of staff opens a student's record, that is written to the append-only log, so there is a permanent record of who looked at what.

9 What we do not do

We do not sell or trade your data. We do not use your work to train models. We run no analytics, no tracking and no error-reporting service: there is no third-party tracking code anywhere in IDoc, and the only cookie we set is the one that keeps you signed in.

One third party does see that you visited: the sign-in and dashboard pages load their typeface from Google Fonts, which tells Google your network address and browser. That happens before you sign in and whether or not you ever connect a Google account.

10 If you connect a Google account

Connecting Google is optional and nothing is requested unless you do.

We ask Google for these and nothing else:

• drive.file, which covers only files you create or open through IDoc. It does not

• let us see the rest of your Drive.

• calendar.events and calendar.readonly, to read your schedule and put course

• events on it.

• openid, email and profile, which give us your Google sign-in name and address,

• to link that account to yours.

IDoc does not request access to Gmail. The ability to read an inbox for deadlines exists in the code, and the setting that would turn it on is not present on our servers, so the permission is never asked for and the feature cannot run. If that changes, this policy changes first.

Connecting GitHub asks for repository access, which is what lets IDoc read and write the repository you chose as your workspace. GitHub grants this at the account level rather than per repository.

Tokens for both are encrypted before they are stored. Disconnecting deletes our copy; you can also revoke access from your Google or GitHub account settings.

11 Where your data is held

On Google Cloud, in Montréal, Canada. The servers are there because it costs less; your records stay under our control and are not handled by anyone else because of where they sit.

Education records are on a machine with no public address. It can be reached only from the application server and from nowhere else. Answers and marks are encrypted where they are stored, as are backups.

12 How long we keep it

• Coursework, submissions and marks: seven years, then deleted.

• Unsubmitted drafts: ninety days.

• Bug reports: one year.

• Backups: fourteen days.

• The sign-in and record-access log: kept permanently. It records that something

• happened, never the contents of your work, and it cannot be edited or deleted

• without breaking the chain that proves it is intact.

13 Reporting a bug

If you send a bug report, we keep what you wrote and the time you sent it. If you leave the box ticked we also keep the page you were on, your browser, and the version of IDoc you were running; the form shows you exactly that and nothing else. A screenshot is included only if you attach one. If you ask for a reply we keep your email address so we can send one.

Reports go to a separate database used for nothing else, and an email to the person who maintains IDoc. They are not sent to any outside service.

14 Your rights

Your education records are protected by FERPA. You may see them, ask for a correction, and ask who has been given them. Write to your instructor, or to the address at the top of this policy, or use the Rutgers Registrar's formal process.

You may ask us to delete data that is not part of a required academic record. We do this by hand, on request, and record that we did it.

15 Changes

If this policy changes in a way that matters, the date at the top changes and course staff will say so. The current version is always the one in the app, and at idoc.page/privacy.

16 Contact

Write to to.prosaidon@gmail.com from your Rutgers address to see what we hold, to have it corrected, to have it deleted, or to ask a question this does not answer. You can also go to your instructor, or to the Rutgers Registrar.