Privacy

TargetX makes network requests in exactly four situations, and no others. The fourth happens only if you choose to sign in.

1. When you press Sync. It signs in to the college portal address you typed and reads your attendance and internal marks — a request to your own college, with your own credentials, at your instruction. app/src/sync/etlab.ts, app/src-tauri/src/etlab.rs.
2. When it refreshes the course catalogue. A plain download of curriculum.json from this project’s own repository, so a KTU curriculum revision does not need a new build. It carries no information about you. app/src/engine/catalogue.ts.
3. A few seconds after launch, to ask whether a newer version exists. A request to GitHub’s release feed, carrying no information about you beyond what any file download carries. app/src/sync/update.ts.
4. When you sign in and ask a question the app could not answer by itself. This is the only request that reaches a server of ours, and the only one that needs an account. Most questions never get here: the app answers attendance, marks, standing and the regulations on your own machine, offline, and only a phrasing it does not recognise is forwarded.
   
   What is sent is your question and the code and title of the subjects you are registered for — the course list, so the question can be matched to a subject. No marks, no attendance, no CGPA, no name, no register number, and no password.
   
   What comes back is not an answer. It is a destination, drawn from a fixed list: one of five screens, or one of the subjects you sent. Anything outside that list is rejected before the app acts on it, so it cannot state a figure about you even in principle — the reply has no field that could carry one. app/src/state/ask.ts, worker/src/schema.ts.
   
   The question text is logged, so the app can learn which phrasings it failed to answer. That log holds the question, the outcome, how many subjects were sent and how long it took. It does not hold who asked: no account id, no token, and not the course codes themselves. Identity and content are kept apart on purpose. worker/src/log.ts.

Your marks are never sent anywhere, by anyone, for any reason. There is no endpoint that would receive them.

Your college portal password is used once, to sign in. It is never written to disk, never logged, and never included in an export. The sign-in happens in the native process rather than the web layer, and the cookie jar it produces lives in that process’s memory and is gone when the application exits — so nothing in the page can read it. app/src-tauri/src/etlab.rs.

If you leave the password field blank, TargetX re-uses the session from earlier in the same run. After a restart there is nothing to re-use, by design.

This is enforced by a test rather than by intention: credential-containment.test.ts puts a sentinel password through a whole sync and then searches for it by value in every outbound request, the saved record, the export, and the text of a failed sync’s error message.

When something inside TargetX fails it writes the failure to a file, so that it still exists afterwards. Without one, a crash leaves nothing behind and “it stopped working” cannot be acted on.

The file holds error messages and the point in the program they came from. It does not hold your marks, your attendance, your password, or the contents of any portal page. It can contain the portal address you typed, because a message about a bad address has to quote it.

Nothing reads the file and nothing uploads it. If you want to report a fault you can open it, read it, and decide for yourself whether to send it — and send it yourself, by hand. On Windows it is at %LOCALAPPDATA%\cv.codedrichy.targetx\logs\targetx.log; the Data screen shows the exact folder for your machine. Deleting it is safe.

There are none. No usage data, no crash telemetry, no identifiers, no counters. The fault log above is written to your own disk and read by nobody; it is not telemetry, because nothing sends it.

Nobody can tell how many people use TargetX. That is a deliberate trade: it costs the project useful information, and it is the only arrangement in which the paragraph above is true without qualification.

Export on the Data screen writes a .json file containing your whole record. It is yours; nothing is withheld from it.

To delete everything TargetX holds, delete the application-data folder named above. Uninstalling removes the program; deleting that folder removes the data.

TargetX is used by students and holds academic performance data, which in most jurisdictions is a protected education record. It is designed so the question of who else can see it does not arise: the data does not leave the device, so there is no processor, no sub-processor and no cross-border transfer to disclose.

An institution deploying TargetX is not sharing student data with this project, or with anyone else, by doing so.

Anything here that is unclear, or that you believe the code contradicts, belongs in an issue.