Security
A summary for IT and security teams reviewing Snowkit for use at work.
How Snowkit is built
The short answer for a security review, with the detail one click away.
Architecture
- Snowkit is a static website. Every tool runs as JavaScript and WebAssembly inside the visitor's browser.
- Files and text entered into a tool are processed in memory on the visitor's device and are never transmitted to Snowkit.
- The site is served over HTTPS only, with HSTS.
Network access
Each tool page carries its own Content Security Policy. Tool pages may load only Snowkit's own scripts and styles, and almost all of them are blocked from making any network connection at all.
A few tools exist to look things up on the internet, and each one says so on its page. The expiry checker reads public RDAP and certificate transparency records. DNS lookup asks the public resolvers of Cloudflare and Google. The citation generator looks up a DOI or ISBN with Crossref and Open Library. The HTTP header checker, the pre-launch scan and the live site check in Snowkit Launch fetch the public address you type through Snowkit's own server. The MCP tester connects to the server address you enter. Only the domain, address or identifier you type is sent, never your files.
Opening files from, and saving results to, Dropbox, Google Drive or OneDrive is available on the pages that offer it. That service's own picker script loads only when someone chooses it, and only those pages allow that service's addresses in their Content Security Policy. Files go straight between the browser and the service, never through Snowkit, and the short-lived permission the service grants is held only in the open page.
What we never use
- No analytics tags or ad networks. The only third-party scripts are the file pickers described under Network access, loaded when someone chooses that service.
- No tracking or advertising cookies. Visitors who don't sign in get no cookies at all; your theme choice is stored in your own browser's local storage.
- No passwords. Accounts are optional and use passkeys or GitHub or Google sign-in, so Snowkit never sees or stores a password.
Other headers
Pages cannot be framed by other sites, MIME sniffing is disabled, referrers are trimmed when leaving the site, and camera, microphone, location and payment features are disabled unless a tool needs them.
Content-Security-Policy- Only Snowkit's own scripts and styles load. Plugins and framing are blocked.
Strict-Transport-Security- HTTPS only, remembered for a year, subdomains included.
X-Frame-Options- DENY. Other sites cannot frame a Snowkit page.
X-Content-Type-Options- nosniff. Files are only ever read as the type they are served as.
Referrer-Policy- strict-origin-when-cross-origin. Other sites see only snowkit.io, never the page you were on.
Permissions-Policy- Camera, microphone, location and payment are off unless a tool needs them.
Cross-Origin-Opener-Policy- same-origin. Windows opened from other sites can't reach into a Snowkit page.
Optional accounts
Signing in stores a name and email address when the sign-in method provides them, the sign-in provider's account ID and the tools you save as favourites. Sessions use a random token kept in a secure, HttpOnly, first-party cookie, with a second cookie holding only your initial for the page header and a third holding only a picture version when you add a profile picture, and only a hash of the token is stored on our side. Files and text used in tools are never linked to an account. You can delete your account and everything in it from the account page at any time.
Passkeys
Passkeys use WebAuthn with user verification preferred. The server issues a single-use challenge that expires after five minutes, checks the origin, relying party and signature counter, and stores only the credential's public key. Email sign-in links, where offered, work once, expire after 15 minutes and are stored only as a hash.
Private sync
Signed-in visitors can choose to sync their Library, Your Snowkit, saved steps and favourite tools between their devices. Sync is end-to-end encrypted: each item is encrypted in the browser before upload, and the server holds ciphertext only.
- Cipher
- AES-GCM with 256-bit keys
- Nonce
- A fresh 96-bit nonce for every save
- Vault key
- 256 random bits, made in the browser
- Key wrapping
- Passkey PRF with HKDF-SHA-256, or a 128-bit recovery key with PBKDF2-SHA-256 at 600,000 iterations
- Library files
- Their own key for every version, sealed in 8 MiB chunks
- Server holds
- Ciphertext, wrapped keys, the account ID, timestamps and sizes
- A random 256-bit vault key is made in the browser when sync is turned on. Items are encrypted with AES-GCM using a 256-bit key and a fresh 96-bit nonce for every save, with the section name and version bound as additional authenticated data.
- The vault key never leaves the device unencrypted. It is wrapped with AES-GCM by each passkey that supports the WebAuthn PRF extension, using a key derived from the PRF output with HKDF-SHA-256, and by a recovery key of 128 random bits shown to the person once, using PBKDF2-SHA-256 with 600,000 iterations.
- The server stores the wrapped keys, the encrypted items, the account ID, timestamps and sizes. It holds no key that can decrypt them, so there is no recovery by Snowkit: if every passkey and the recovery key are lost, the synced data can't be opened by anyone.
- Library files are synced only when sync is on. Each file version is sealed with its own random 256-bit key in 8 MiB chunks, each chunk bound to its object ID, position and count, and stored under a random object ID. The per-file keys, names, types and projects live only inside the encrypted Library index, so the server sees opaque IDs, sizes and timestamps.
- Files that are only opened in a tool are never synced. Each account has a storage limit; when it is reached, uploads pause and nothing is deleted. Turning sync off deletes the encrypted copy from the server.
A display name and an optional profile picture are account details, not sync data. The picture is resized in the browser and stored unencrypted with the account, served only to that signed-in account with private caching, and deleted with the account.
What we do see
Like any website, our host processes standard request data such as IP addresses to deliver pages. We count page views by path, without cookies and without storing IP addresses. Gap Radar counts searches with no result, unanswered Kitsune questions, missing pages and short error codes as daily totals only, with no cookie, identifier or IP address; search text is cleaned on the device, and rare text that has not come up 5 times within 28 days is never shown and is deleted. Messages sent through the feedback form reach the Snowkit team by email. See the privacy policy for details.
Reporting a vulnerability
Email [email protected] with the details and steps to reproduce. We will acknowledge your report and keep you updated while we fix it. Our security.txt lists the same contact.
Security contact: [email protected] · security.txt