Privacy and retention¶
Three claims on this page are worth stating before the details, because they are the ones that decide whether this is usable on data you are responsible for. The third is an exception to the second, and it is stated here rather than in a footnote because a privacy page that rounds off is worse than one that does not make the claim at all.
The local path never uploads a pixel. Tiling, quality control, packing, embedding and reading a result all happen on your machine. A slide you tile locally stays where it is, and so do its label and macro images, which the container has no member for.
The package sends nothing home. No telemetry, no usage counter, no crash report, no version check. If you never call the hosted API, nothing about your work is observable to the service — there is no channel through which it could be.
One thing does reach the network, and it is not your data. Running an encoder on your own machine needs that encoder's weights, and they are fetched from Hugging Face the first time and cached after that. What Hugging Face can see is which model repository and revision were requested, and when — never an image, a coordinate, a gene or a result. If a request of that shape is itself something you must not make, the encoder can be told to refuse the network outright and fail unless the weights are already in the local cache. Nothing else in the package opens a socket.
What is stored when you do submit¶
Only what a submission needs: the observation you uploaded, the covariates you sent, the job's record and its result. No request or response payloads are logged. Logs carry a request identifier, the key's public prefix and the job identifier — enough to answer "what happened to this job", and nothing that reconstructs its contents.
For how long¶
| What | Kept for | Why |
|---|---|---|
| Uploaded input | 7 days after the job finishes | the input is only needed while the job that reads it is alive, and for a short window afterwards in case it has to be re-run |
| Result file | 90 days | long enough to fetch, re-fetch and archive it yourself; not a storage service |
| Submitted embeddings | deleted when the job finishes, unless retention is requested | an embedding is derived from your pixels, so the default is not to keep it |
Deletion on request is immediate and audited: you can delete an upload, a job and its result, and the deletion is recorded rather than being something you have to take on trust. Retention is an upper bound, not a promise to keep anything — treat a downloaded result as the copy that matters.
What is public¶
Nothing you submit. Results are yours; they are not used as training data, not shown to anyone else, and not published. Aggregate service health — is it up, how deep is the queue — is public, and contains no reference to any submission.
Anonymisation is yours¶
The service does not inspect your images for identifiers and cannot remove them. Removing patient identifiers, personal data and protected health information — including metadata embedded in a slide file — is your responsibility before anything is uploaded, and it is a condition of use. See Responsible use.
Two things help. Tile locally: the container carries tiles, a manifest and an
optional low-resolution overview, and has no member for a slide label, a macro
image or vendor metadata. Or submit embeddings: then the pixels never move at
all.
Where it runs¶
Uploads, results and account records are stored and processed on infrastructure in Switzerland, and the service is designed to align with Swiss and European data-protection standards. The published Privacy Policy is the full statement, including the operational service providers involved in running the website.