Privacy
There is no account and no sign-in, so everything you set and every paper you sit stays in this browser. Submitting a paper also sends one record of the numbers, and that is on for everyone.
What stays in this browser
All of this is held in local storage on the device you are reading on. None of it is sent anywhere, none of it follows you to another device, and a private window may drop the lot when it closes.
- Your board marks, the SSC and HSSC percentages an aggregate is worked out from.
- Every paper you have sat: the questions served, the answers you gave, which ones you flagged, the seconds each took, and the score.
- The paper you are in the middle of, until you submit it or delete it.
- The programme you are aiming at, which every gap is stated against.
- The vocabulary schedule: which words are due, and which box each one is in.
- Whether you asked for reduced motion.
There are no cookies and no third-party script on any screen. The font, the question bank and everything else a page loads come from NUST Bench’s own server.
What one submitted paper sends
Pressing submit writes the paper to this browser first, and then sends one record to NUST Bench’s server. It happens on every paper. There is no switch for it and you are not asked. The record is these fields and nothing else.
- Paper
- Its label, such as Full NET or a sectional, and the draw mode it was built with. A realism flag sits in the shape as well and is always sent as false, because a finished paper does not keep whether that mode was on.
- Score
- The score, the number of questions, and the NET percentage the two produce.
- Sections
- For each section the paper carried, the score and the number of questions in it.
- Time taken
- Seconds spent on the paper with it on screen, and whether it carried a clock at all.
- Questions
- One row a question: the bank’s own question id, whether it was right, wrong or skipped, and the seconds spent on it. These rows are the reason the record is worth sending, because they are the only way to find which questions are actually hard rather than which ones the author thought were.
- Submit time
- Rounded down to the hour before it leaves the browser.
- Build
- A record version and the release it came from, 2026.09, so records written by an older build stay readable.
Your board marks are not in it, and neither is the aggregate they produce. What is sent is the paper, not the candidate.
What a record does not carry
No name, no email and no account, because there are none to take. No device id, no session id and no cookie. Nothing about the request either: the endpoint writes no IP address, no user agent and no header of any kind, since those are the fields that would turn a pile of anonymous records into an identifiable one.
One header is read and not kept, and the difference matters enough to write down. The endpoint is open and it writes to a database, so it counts how many records one caller has sent in the last ten minutes and refuses the thirteenth. Telling one caller from another means having something to count against, and what it counts against is the forwarded address hashed with a salt the server makes when it starts and never writes down. That hash is held in memory for ten minutes. It cannot be turned back into an address, it is never written to the database, it is never logged, and it stops meaning anything the next time the server restarts. It is there so that one person with a script cannot fill the collection and turn the figures on the cohort screen into fiction.
Two of the omissions are deliberate rather than incidental. The attempt id is withheld: every paper on this device has one, it is how the browser links its own papers together, and sending it would hand that link over. The submit time is blunted for the same reason, because a precise one is close enough to an identifier that someone who knew roughly when you sat a paper could pick your record out of a day’s worth. It is rounded down to the hour in the browser and rounded again on arrival.
What follows from that is the whole case for sending it at all. There is no field to join two records on, so ten papers arrive as ten unrelated records rather than as your history. Because it is on by default and you are not asked, that case cannot be consent, and it is not claimed as consent. It is that a record carries no identifier: there is nothing in one to tie it to you, and nothing to tie it to the next one.
What the server keeps, and what comes back out
The endpoint that receives a record is open to the internet, so it treats what it is handed as hostile. It rebuilds the record field by field from the shape above rather than storing the body it was sent, which is what stops a caller inventing a field and having it written: anything outside the list is dropped. A record that does not fit the shape is rejected rather than kept.
Records sit in one collection and nothing is written beside them. Only aggregates come back out: counts and percentages computed in the database, never a document, so no submission is served back to anyone. Any per-question figure resting on fewer than 5 separate papers is withheld rather than published, because a cohort percentage from three people is noise wearing a percentage sign.
A deployment with no database configured stores nothing at all. The endpoint answers that the record was not stored, the browser never waits for that answer, and nothing is retried.
Deleting what is on this device
The controls are in Settings. Export writes a JSON file of every attempt, which is the only copy that survives a delete. Import merges a file back in, here or on another machine, and an attempt already on file wins, so importing twice cannot double a paper. Delete removes every attempt from this browser and cannot be undone.
Delete does not reach the board marks, the target programme, the vocabulary schedule or the motion preference. Those are settings rather than history, and clearing this site’s data in your browser removes them along with everything else.
Records already sent cannot be deleted on request, and that is a consequence of how they are built rather than a policy: with no identifier in them there is no way to find which ones are yours. What can be said about them is the field list above, which is all of it.