Privacy policy
Last updated 2026-11-11. Applies to zerkersec.io, the supporter programme, and the Porthole app, daemon and relay.
Short version: the site keeps no accounts and sets no tracking cookies. If you become a supporter, we keep the minimum Patreon gives us plus a hashed key. Porthole keeps your sessions between your phone and your computer; the only thing that ever touches our servers is an encrypted push notice we cannot read. Everything below is the long version.
1. Who we are
This site and the Porthole apps are built and operated by ZerkerEOD, an individual developer based in the United States. For anything in this policy, ZerkerEOD is the data controller. Contact: privacy@zerkersec.io.
2. What this covers
- zerkersec.io, including the project pages, the blog, and the hosted documentation for KrakenHashes and Heimdall Listener.
- The supporter programme at zerkersec.io/supporter, which issues supporter keys to Patreon members.
- Porthole: the mobile app (App Store and Google Play builds), the daemon you run on your computer, and the push relay we operate for supporters.
KrakenHashes and Heimdall Listener are open-source programs that run entirely on your own machines. They do not report to us, contain no telemetry, and are not covered by this policy beyond the documentation pages served from this site. Porthole's daemon is the same: it talks only to your phone and, if you turn push on, to our relay.
3. The website and documentation
The site is static pages served by Cloudflare Workers. We run no accounts, no comments, no forms except the supporter sign-in, and no advertising.
- Request logs. Cloudflare records each request (IP address, URL, user agent, status, timing) in short-lived Workers logs that we use to diagnose errors. Cloudflare keeps them for a few days under its own policy. We do not export, enrich or keep them.
- Rate limiting. The supporter sign-in, GitHub link, key and priority-lookup endpoints count requests per IP address or per key in memory for one minute to slow down abuse. Nothing is written to storage.
- No third-party resources. Fonts, scripts and styles are served from this domain, apart from the analytics script in section 4. The documentation version picker calls this site only. If the KrakenHashes documentation Worker is unavailable, pages may be fetched from GitHub Pages as a fallback; GitHub then sees that request.
- Browser storage. One
sessionStorageflag (zs.boot) remembers that you have seen the intro animation for the length of the tab. It is not a cookie and is not sent anywhere. - Outbound links to X, LinkedIn, GitHub, Patreon and Discord take you to those services under their policies. Nothing is loaded from them on our pages.
4. Analytics
We use Rybbit, a cookieless analytics service, to see which pages are read. The script records the page URL and title, the referrer, UTM parameters, browser and operating system, screen size, approximate country and region, and visit length. It sets no cookies and uses no local storage, so no consent banner is shown. Visitors are counted with an anonymous identifier derived from the IP address and browser signature that rotates daily; the IP address itself is not stored and IP tracking is switched off in our configuration. We do not use analytics to identify you, to build profiles, for advertising, or across other sites, and nothing is sold. Rybbit processes this data on our behalf under its privacy policy. Our basis for this is our legitimate interest in knowing what is being read. If you block the script, the site works exactly the same.
5. The supporter programme
Supporting the project happens on Patreon. Signing in with Patreon on this site links your membership to a supporter key that unlocks supporter features in the apps.
What we receive from Patreon
When you continue with Patreon we request the identity, identity[email] and identity.memberships scopes and read your Patreon user id, your email as Patreon reports it, and your membership on our campaign: status, tier, next and last charge dates and the last charge result. Patreon is the merchant of record. We never see card details, addresses or payment history beyond the charge result. The Patreon access token for your account is used for that one lookup and is not stored.
What we store
| Data | Why | Kept |
|---|---|---|
| Patreon user id and member id | Match webhook updates and refresh your status | While your membership is active and for 30 days after it ends, or until you delete your record |
| Email from Patreon | Send you the key once; show it on your account page | |
| Membership status, renewal date, tier id | Decide whether a key is active and which features it unlocks | |
| A SHA-256 hash of your supporter key and its first four characters | Verify keys without storing them; let you recognise yours | |
| For each phone that uses the key: a random device id the app generated and its platform (iOS or Android) | Limit a key to a handful of devices | 90 days after the device last used the key, or when the record is deleted |
| Patreon webhook event ids (event type, member id, charge date, status) | Ignore duplicate deliveries | 90 days, or when the record is deleted |
| Optional: your GitHub numeric user id and username, if you link GitHub for priority support | Label issues you open in our repositories so supporters are triaged first | Until you unlink, or when the record is deleted |
The full key is shown once on screen and emailed to your Patreon address. We keep only the hash. If you lose it, you regenerate it; the old one stops working.
Priority support on GitHub (optional)
Supporters at the Foothold tier or above can link their GitHub account on the account page. We ask GitHub for no permissions at all: the sign-in returns only your public numeric id and username, and the token is discarded. From then on, when you open an issue in one of our repositories, a GitHub Action asks this site whether that username currently has priority support and, if so, adds a supporter label. The site answers yes or no for the username it is given and nothing else. The label is public: anyone reading the issue can see you support the project. Linking is your choice, is never required for any other perk, and you can unlink at any time; existing labels stay on old issues unless you remove them.
Discord
Supporter roles on our Discord server are granted by Patreon's own Discord integration. You connect Discord on Patreon, and Patreon's bot adds or removes the role as your membership changes. We receive nothing from that and store no Discord identifiers; Patreon's and Discord's policies apply.
Keeping status current
Patreon sends us a webhook when a membership changes, and when your record is older than a day we look your membership up again with our creator token. Both update only the status, renewal date and tier.
Cookies
| Cookie | Purpose | Lifetime |
|---|---|---|
zs_session | Signed session for the account page. HttpOnly, Secure, SameSite=Lax. Contains a record id and timestamps, no personal data. | 20 minutes of inactivity, 2 hours at most, or until you sign out |
zs_newkey | Carries a newly issued key to the account page so it can be shown once. HttpOnly, Secure, scoped to /supporter. | 120 seconds or first view |
No other cookies are set anywhere on the site.
Who processes this for us
- Patreon: membership, billing, and the sign-in.
- Neon: the database, hosted in the United States.
- Emailit: delivers the key email to the address Patreon reported. The sent message is retained by Emailit under its policy.
- Cloudflare: runs the site and the request logs described in section 3.
Deleting your record
The account page has a Delete my record button. It removes your supporter row, your key hash, your device rows, your webhook ids and any linked GitHub id immediately. Your Patreon membership is not affected, and signing in again recreates the record. Records of lapsed memberships are purged automatically 30 days after the membership ends.
6. Porthole: the app and the daemon
Porthole is a remote control for coding-agent sessions on your own computer, built so that your sessions never leave your network. Session transcripts, the terminal screen, your typed input and your approvals travel between the phone and the computer over your own VPN or LAN, encrypted with TLS to a certificate pinned at pairing. We operate nothing in that path and cannot see that traffic.
On your phone
- In the platform keystore: each paired machine (address, certificate fingerprint, access token, the machine's device id and name), your supporter key if you entered one, and the per-machine keys that decrypt push notices.
- In app preferences: a random push device id the app generated, the push grant (which includes the phone's push token), a seven-day cache of session titles and working directories so the list opens instantly, and your settings.
- At pairing, the phone sends your computer its device name so you can recognise it in the daemon's device list.
- QR codes are scanned on the device with the camera. Images are not stored or uploaded.
- If claude-swap is installed on your computer the app displays the account emails and quota figures the daemon reads from it. They come from your computer, not from us.
On your computer
The daemon keeps a local file of paired phones: id, name, a hash of the access token, scopes, pairing time, last-seen time, the push key and the push grant. It makes no network connection except to your phone and, when push is on, to our relay.
Push notifications (supporters only)
To wake the app while it is in the background, Porthole uses Apple's and Google's push services and a small relay we run. On push-capable builds the Firebase Messaging SDK is included only to obtain a push token; that creates a Firebase installation id and push token held by Google (Android) or Apple (iOS). Firebase Analytics is disabled and not included. The app contains no analytics, advertising or crash-reporting SDKs.
7. Porthole: the push relay
- Getting a grant. The phone sends the relay your supporter key, its random device id, its platform and its push token. The relay asks this site whether the key is active (section 5 records the device id and platform), then returns a signed grant containing the device id and push token. The relay stores none of this; the grant lives on your phone and on your computer.
- Sending a notice. Your computer sends the relay the grant, a notice encrypted with a key the relay never sees (at most 480 bytes), and an opaque per-session grouping id so repeated notices replace each other. The relay forwards these to Google FCM or Apple APNs with a fixed, generic alert text. It cannot read the notice and keeps no copy.
- What the relay keeps. Per-device daily counters, deleted after two days, and a deny list of revoked device ids. Cloudflare's short-lived request logs (section 3) apply to the relay too, so the relay sees the IP addresses of your phone and your computer for rate limiting.
- Attestation. Where enabled, the relay verifies that a grant request comes from a genuine store build using Google Play Integrity. The attestation token is checked and discarded.
The relay's source is public and you can run your own; the app accepts any relay URL at build time.
8. Your rights
You can ask for access to, correction of, a copy of, or deletion of the personal data we hold about you, and you can object to processing based on our legitimate interests. For supporter data, the account page shows what we hold and deletes it on request. For anything else, email privacy@zerkersec.io. We answer within 30 days and may ask you to prove you control the Patreon account in question.
If you are in the European Economic Area or the United Kingdom, these rights come from the GDPR and UK GDPR, and you may also complain to your supervisory authority. Our legal bases are: performance of the supporter arrangement you asked for (section 5), consent for push notifications, which you can withdraw in the app at any time (sections 6 and 7), and our legitimate interests in running, securing and understanding the use of the site (sections 3 and 4). We have no establishment in the EU or UK and have not appointed a representative there: our processing is occasional, small in scale, and involves no special categories of data, which is the exemption in Article 27(2).
If you are in California or another US state with a privacy law: we do not sell personal information, do not share it for cross-context behavioural advertising, and do not use sensitive personal information. The rights above apply to you as well.
9. Children
The site and apps are not directed at anyone under 16 and we do not knowingly collect data from them. Patreon requires supporters to be adults. If you believe a child has given us data, email us and we will delete it.
10. Where data lives and how it is protected
Data is processed in the United States by the providers named above. All connections use TLS. Supporter keys are stored only as hashes, session cookies are signed, secrets are never written to logs, and the complete source code of the site, the app, the daemon and the relay is public so these statements can be checked. If a breach affects you we will tell you and, where required, the relevant authority.
11. Changes
When this policy changes, the date at the top changes with it. Material changes to how the apps handle data are also announced in the app and in the project repository before they take effect.