Niska is privacy-first, but it's still software running on real servers, so let's be exact about what that means. Below is the honest breakdown of where each tool runs and what our servers can and can't see, including the parts where your data does leave your machine, and what we do to keep that to a minimum.
| Tool | Where it runs | What our server sees | Retention |
|---|---|---|---|
| File-share.sh | Our servers | The file, or only ciphertext if you encrypt it (encrypted and decrypted in your browser, so we only ever hold bytes we can't read), plus your IP | Until expiry, one-time view, or you delete it |
| Pastebin.txt | Our servers | The paste, or only ciphertext if you encrypt it (encrypted and decrypted in your browser, so we only ever hold text we can't read), plus your IP | Until expiry or one-time view, or you delete it |
| GeoIP.db | Our servers (local database) | The IP/hostname you look up, and your own IP | Not stored per user; your search history stays in your browser |
| Password.key | Your browser | Nothing, the analyzer and generator never send your input anywhere | Nothing leaves your device |
| Encode.enc | Your browser | Nothing, encoding, ciphers, hashing and encryption all run on your device | Nothing leaves your device |
Password.key and Encode.enc are live and fully client-side, carrying the runs in your browser · nothing leaves badge.
Files and pastes can be encrypted with AES-256-GCM. The key is derived from
your passphrase and never stored on our servers. It lives in the share link,
after the #:
files: /aB3xK9p.pdf#your-key pastes: /p/3f9a2c4e#your-key ← everything after the # stays in your browser
That fragment (#…) is the part your browser never puts in the
request URL, so it stays out of our access logs. Encrypted files and pastes are
both end-to-end: your browser encrypts them before they reach us and decrypts them again on
open, so we only ever store ciphertext and never see the key at all. GCM
authentication means a wrong key fails loudly instead of returning garbage. The trade-off is
deliberate: lose the link and the content is gone for good, encrypted pastes can't be
edited or syntax-highlighted (we can't read them to colour them), and encrypted files can't be
previewed by a link unfurler.
# fragment, which is never send to us.
We don't claim "no logs", that's almost never true, and we'd rather be precise. We keep operational access logs to run and debug the service and to enforce rate limits. They are request metadata, not a profile of who you are. A real log line looks like this:
{"timestamp":"2026-06-13T19:28:34Z","method":"GET",
"path":"/p/3f9a2c4e#NEVER-REACHES-OUR-LOGS","status":200,
"client_ip":"203.0.113.7","request_id":"e930bb9b","latency_ms":3}
| Cookie | Purpose | Notes |
|---|---|---|
nsk_access |
Your signed-in session (a short-lived token) | HttpOnly, SameSite=Lax, 15 min |
nsk_refresh |
Renews your session without re-login | HttpOnly, only ever sent to /api/auth |
nsk_csrf |
Protects forms against cross-site forgery | Readable by JS (so requests can echo it back), 12 h |
There are zero analytics or tracking cookies. Consent banners exist to ask permission for tracking, we don't track, so there's nothing to ask, and no banner. Cookies only appear once you log in or submit a form.
The source is closed for now, so this page and what you can observe yourself are the trust story. Open your browser's developer tools → Network tab and watch:
# is never in the
request
URL, your data is encrypted entirely client-side in your browser.nosniff, and no third-party script origins.