Privacy & Security

What we collect

When you visit a page on mogambo.info, the following is recorded by our self-hosted analytics:

• The page URL you visited
• An anonymized referrer (where you came from, if applicable)
• Your browser and OS family (e.g. "Edge on Windows")
• Your country (derived from IP, then the IP itself is discarded)
• The date and time of the visit

We do not collect: your full IP address, your name, your email, your device fingerprint, your behaviour across other websites, or any personally identifying information.

Your analytics controls

Even though our analytics is cookieless and stores no personal data, we honor two opt-out signals. If either is active, the analytics script never loads on your device and nothing is sent.

1. Do Not Track. If your browser sends the DNT: 1 header (Firefox, Brave, and some Edge/Safari configurations support this in their privacy settings), we automatically suppress analytics. No action needed from you.
2. One-click toggle on this page. Click the button below to opt out (or back in) for this device. Your choice is stored in your browser's localStorage and persists across visits until you clear site data.

What we don't do

• No cookies. Zero. The site sets no cookies of any kind, first-party or third-party. You will never see a cookie banner because there is nothing to consent to.
• No third-party trackers, no third-party CDNs. No Google Analytics, no Facebook Pixel, no advertising networks, no tag managers, no embedded viewers. The only outbound request from any page on this site is to our own analytics server (analytics.mogambo.info), and that request is suppressed entirely for readers using Do Not Track or our opt-out toggle above. One processor — Mailjet — handles outbound email relay (confirmations, the monthly digest, per-moment notifications, feedback notifications to Amit). That's the only external service involved in any user-facing path; the email section below documents what Mailjet sees and doesn't see. Every asset the browser fetches — HTML, CSS, JavaScript, fonts, icons, images — is served from mogambo.info itself. The interactive tools used to load Tailwind CSS and Lucide icons from third-party CDNs; as of May 2026 those have been extracted and self-hosted alongside the rest of the site. Word documents embedded in research pages are pre-converted to PDF and served from this site — your browser's built-in PDF viewer handles them with no external request. Defense in depth: our Content Security Policy header blocks any future accidental re-introduction of a third-party CDN at the browser level.
• No data sharing. Nothing about your visit is sold, traded, or made available to advertisers, data brokers, or any third party.
• No tracking pixels. No 1×1 transparent images, no beacon requests on link clicks, no fingerprinting scripts.

How we secure the site

• HTTPS-only. The site is served over TLS using a Let's Encrypt certificate. All HTTP requests redirect to HTTPS automatically. There is no plaintext fallback.
• Self-hosted infrastructure. The site runs on a single dedicated VPS that we administer directly. The analytics database (Umami) runs on the same VPS in an isolated Docker container. No third-party SaaS holds your visit data.
• Self-hosted fonts. The Newsreader, Inter, and JetBrains Mono fonts are served from our own server, not Google Fonts. This means visiting a page does not leak your IP to Google's font CDN.
• Minimal attack surface. The site is currently static HTML with no user accounts, no comment system, no contact form posting to a backend. The only writeable surface is the analytics container, which is reachable only through our nginx reverse proxy and is rate-limited at the network edge.
• CSRF protection on form POSTs. The two writeable endpoints (the feedback form and the newsletter signup) verify the request's Origin / Referer header against this site's origin before accepting the submission. Combined with the cookieless design (no session to forge), this stops the trivial cross-origin form-submit attack class.
• Subscribe-bombing defense. The newsletter signup endpoint applies two independent rate limits: per-IP (3 requests/min, enforced at the nginx layer) and per-target-email (one confirmation send per email address per 24 hours, regardless of how many IPs the request comes from). The second guards against the harassment vector where an attacker uses a residential-proxy pool to flood a victim's inbox with confirmation emails.
• Single-VPS posture — resilience caveats. The site, analytics, feedback database, and subscriber database all live on one VPS. This is a deliberate privacy choice (no third-party SaaS holds your data) and a resilience tradeoff (a single host compromise or hardware failure has a broader blast radius than a multi-host setup). Backup posture: a nightly SQLite .backup snapshot of the subscriber and feedback tables runs on the VPS at 03:00 UTC and is retained for 14 days. The latest snapshots are mirrored at 04:00 local time via rsync to a separate FileVault-encrypted disk on Amit's machine — off-VPS, encrypted at rest, multi-day rolling history. Site HTML/CSS/JS is reproducible from the Git repository (the deploy is itself an rsync from that repo). nginx config and the Go service binary are reproducible from the same repo. Worst-case recovery window: roughly 24 hours of subscriber and feedback data could be lost between the last snapshot and a single-host failure. Honest scope: no third-party off-site replica yet (would add cost and a processor relationship we don't currently want); we'll revisit if subscriber count grows enough to make the 24-hour window unacceptable.

Independently verified, not just claimed

You don't have to take our word for the security posture above. Three independent scanners report the following grades against https://mogambo.info/ as of 2026-05-15:

• securityheaders.com — grade A+. Confirms HSTS preload header, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy, and the Cross-Origin embedder/opener/resource trio are all set correctly.
• Mozilla Observatory — clean passes on Content Security Policy (no 'unsafe-inline' or 'unsafe-eval'), Cookies (none), CORS, Redirection, Referrer Policy, Strict Transport Security, Subresource Integrity, X-Content-Type-Options, X-Frame-Options, and Cross-Origin Resource Policy. The single tightening recommendation (default-src 'none' in CSP, replacing default-src 'self') shipped 2026-05-15.
• SSL Labs (Qualys) — grade A. TLS 1.3-only (no 1.2/1.1/1.0 fallback). Post-Quantum-Cryptography key exchange supported (X25519MLKEM768). HSTS with 1-year max-age + includeSubDomains + preload. DNS CAA policy restricts cert issuance to Let's Encrypt. ECDSA-256 cert, 384-bit signature. The remaining A-not-A+ gap is HSTS preload-list inclusion (header is set; domain submission to hstspreload.org in progress).

Re-run any of these whenever you want a fresh read. The grades are not paid placements; they reflect what response headers and TLS config the scanners actually observe.

What CSP and HSTS preload actually protect against — and what they don't

Scanner grades sometimes get summarized as "strict CSP and HSTS preload make the site virtually immune to XSS and MITM attacks." That's overstated, and we'd rather call out the residual risk explicitly than imply stronger guarantees than the controls provide. Honest read:

• What default-src 'none' CSP actually stops. Injected <script src=evil.com> tags fail to load. Inline <script> blocks without a matching SHA-256 hash fail. eval() and new Function() are refused. Most of the textbook XSS classes are dead on arrival.
• What CSP doesn't stop. DOM-based XSS where attacker-controlled input flows into the page through legitimate same-origin code paths (e.g., user input written into .innerHTML without sanitization). Our tools do post-innerHTML DOM mutation in the wellness tracker, so the protection there is "trusted input + careful authoring," not "CSP catches it." Hash-collision exploits against the allowlisted inline blocks are cryptographically implausible, not impossible. And a single careless 'unsafe-inline' reintroduction in one location block would undo a lot of the posture — what catches that is the CSP diff in our deploy pipeline plus the version-controlled nginx-config snapshots that get reviewed every change.
• What HSTS preload actually stops. SSL-stripping man-in-the-middle attacks (where an attacker downgrades a victim's connection from HTTPS to HTTP). Once a domain is on Chrome's preload list, every Chromium-based browser everywhere refuses to even attempt HTTP for that domain.
• What HSTS preload doesn't stop. Man-in-the-middle attacks using a valid certificate — for instance, if a Certificate Authority is compromised or fraudulently issues a cert for mogambo.info. (DNS CAA pinning to Let's Encrypt narrows this surface but doesn't eliminate it.) And HSTS preload protection only kicks in once the domain is actually on Chrome's preload list. We submitted to hstspreload.org earlier this month; Chrome's review queue is typically 6-12 weeks. Until inclusion ships in a Chrome release, first-visit trust-on-first-use still applies for any browser without the HSTS header cached.
• Where the remaining attack surface actually is. Application-layer logic bugs in our Go feedback / subscribe service. Upstream provider account compromise (Mailjet, Microsoft 365, GoDaddy DNS, DigitalOcean). Amit's personal device credentials. None of those are CSP or HSTS problems — they're operational hygiene problems, and they get the attention they deserve.

The point of the section above isn't "this site is unhackable" — nothing is. It's "we've moved the controllable layers as far as they go, named the layers we haven't, and you can verify both."

What our tools store locally on your device

Content pages (everything under /moments/, the pillar landings, About, and so on) store nothing on your device — no cookies, no localStorage, no IndexedDB. Three interactive tools are different: they keep state in your browser's localStorage so your progress survives a page reload. Nothing is sent to our server; the data lives in your browser and is wiped when you clear site data for mogambo.info.

• 5-Week Wellness Tracker (/wellness/5k-under-30/tools/tracker.html) — stores your day-by-day program progress, profile (training band, name if entered), and tool-usage analytics. Three keys.
• M365 Posture Sandbox (/practice/m365-copilot-architecture/tools/posture-sandbox.html) — stores the tenant baseline you configure (Slot A), so you can return to the same configuration later. One key.
• IPO Framework Calculator (/family/ipo-investment-framework/tools/sizing-calculator.html) — stateless. Inputs are kept in URL parameters only; nothing persists.

To inspect or wipe: in any browser, open DevTools → Application tab → Local Storage → https://mogambo.info. To clear it, right-click → Clear. To delete it permanently for this site, browser settings → Site Settings → mogambo.info → Clear data.

Documents render in your browser, not a third party's

Research pages on this site (M365 Copilot Architecture, the IPO Investment Framework) include embedded documents. Until early May 2026 those documents were rendered via Microsoft's Office Online public viewer, which meant your IP address was visible to Microsoft during the iframe load. That dependency is now gone. Microsoft deprecated their public viewer service in May 2026; we responded by pre-converting the source Word documents to PDF on Amit's local machine and serving the PDFs directly from this site. Your browser's built-in PDF viewer renders them inline. No third-party server sees your visit. If you want the original Word document, request it by email — the link is on the relevant research page.

If you contact us

The site lists mogambo@mogambo.info for feedback, corrections, and questions. Email you send to that address is read by Amit personally and stored in a regular email inbox under standard email-service security (TLS in transit, encrypted at rest with the provider). If you'd like a piece of feedback to remain anonymous, just say so and we won't reference your name or email in any update.

How feedback form submissions are handled

Every ah-ha moment carries an inline "Tell Mogambo" form at the bottom. When you submit it:

• Where it goes. The form POSTs to our own server (a small Go service on the same VPS that serves the site). No third-party form service, no Zapier, no Google Forms, no external analytics.
• What gets stored. Your feedback text, the moment's slug (which page it was about), your optional name and email (only if you fill them in), and a salted SHA-256 hash of your IP address (used as a rate-limit key only; the raw IP is never written to disk). Plus a user-agent string for spam triage. Stored in a SQLite database on the same VPS, readable only by Amit. What the IP hash is and isn't: it's a rate-limit primitive, not a privacy primitive. Because the salt sits on the same VPS as the hashed values, an attacker who compromised the VPS could in principle iterate the IPv4 address space against the salt and recover the original IPs. So this avoids storing raw IPs in the normal-operations case, but it should not be relied on as anonymization under a server-compromise threat model. We're calling it out explicitly rather than implying stronger guarantees than it provides.
• What does not get stored. Your raw IP address. Your browsing history. Cookies. Anything tying the submission to other site activity.
• Rate limit. 5 submissions per hour, 20 per day, per hashed-IP. Honors the "thoughtful submissions, not spam" expectation; bots get throttled.
• Optional fields. Name and email are exactly that — optional. Leave them blank and the submission is fully anonymous (Amit sees "(no name)" + "(no email)" in his admin view). If you leave an email, Amit may write back when the next version of the piece ships, with credit to your pushback (with your permission).
• Email notification to Amit. Each submission triggers a plain-text email to mogambo@mogambo.info — a push notification so Amit reads pushback within hours, not weeks. The notification is relayed through Mailjet (operated by Sinch UK Holdings Ltd., GDPR-compliant), a transactional email service that briefly handles the message in transit before delivery. Mailjet does not retain message content beyond its standard delivery window. The email is then delivered to Amit's Microsoft 365 mailbox under standard mailbox security. The email content includes the feedback body, the optional name/email, and the moment slug — the same data already stored on the VPS.
• What is not in any of this: no comments section appears on the moment page after submission. Feedback gets synthesized into v+1 updates (see Evolution), not displayed publicly. The reader sees the result of feedback — corrected claims, v+1 updates, dated "Mogambo khush hua — corrected" notes — not the raw submissions.

If you subscribe to Mogambo's newsletter

Mogambo offers an optional email subscription on the subscribe page and on every ah-ha moment's feedback form. Two channels: a monthly digest (~once on the 1st) and per-moment notifications (an email each time something new ships). You can pick either, both, or neither.

• What gets stored. Your email address, which channels you selected (digest, per-moment, or both), your current status (pending / confirmed / unsubscribed / bounced), and timestamps (signed-up, confirmed, unsubscribed). Plus two opaque tokens — one for the one-click confirmation link, one for the one-click unsubscribe link in every send. Stored in the same SQLite database on the same VPS as feedback submissions, readable only by Amit.
• What does not get stored. Open tracking pixels. Click tracking. Read receipts. Engagement scoring. We don't measure whether you opened an email, whether you clicked a link in one, or how long you spent reading it. Send-side telemetry stops at "delivered to Mailjet for relay" — beyond that, nothing comes back into our records.
• Double opt-in. A confirmation email is sent after every signup with a unique one-click link. Your status stays pending until you click; nothing else happens until then, and pending rows that aren't confirmed within 7 days are eligible for cleanup. This is how we prevent accidental signups and signup-spam by third parties.
• How sends work. Outgoing emails (confirmation, monthly digest, per-moment notifications) are built on our own VPS and relayed through Mailjet (operated by Sinch UK Holdings Ltd., GDPR-compliant) — the same transactional email path the feedback-notification flow uses. Mailjet briefly handles the message in transit, then drops it.
• Unsubscribe. Every email carries a one-click unsubscribe link with a unique token. Clicking it flips your status to unsubscribed immediately — no login, no "are you sure", no friction. The List-Unsubscribe header is also set per RFC 8058, so Outlook / Gmail / Apple Mail show a one-click "Unsubscribe" button in their UI. You can also email mogambo@mogambo.info with the address you signed up under and Amit will unsubscribe you manually within a couple of days.
• Rate limiting. The signup endpoint is rate-limited at 3 submissions per minute per IP (5 burst) at the nginx layer, plus an application-level dedup that refuses to send a second confirmation to the same address within 5 minutes. This defends both the inbox you're signing up with and our outbound reputation.
• Retention. Confirmed subscriber rows live as long as you're subscribed. Unsubscribed rows are kept so we don't accidentally re-add you on a later automated flow; they're not actively used. Bounced rows are kept for diagnostic visibility (the address kept failing) and may be purged at Amit's discretion. If you'd like your row deleted entirely — including the unsubscribed record — see the data-request section below.

Requesting your data (or its deletion)

If you'd like to see what we have on you, or have it deleted entirely, email mogambo@mogambo.info with the address you signed up under (or any contact you've had with us) and a short note describing what you want. Amit fulfills these manually — no self-service portal, but a real human reads the request and responds.

• What we'll send back if you ask for your data. A plain-text or PDF export covering: every feedback submission tied to your email or name; your subscriber row (email, channels, status, timestamps) if you've subscribed; any record of email correspondence with mogambo@mogambo.info. We will NOT include the secret salt used to hash IPs (that's site-wide infrastructure, not personal data), but we will tell you the dates on which submissions tied to your hashed IP exist if it helps verify the picture.
• What we'll do if you ask for deletion. Delete your subscriber row (full removal, not just status=unsubscribed); redact your name and email from every feedback submission row (we leave the feedback body so the editorial record stays intact, but strip the identifiers); and discard any retained email correspondence. The hashed-IP rate-limit entries age out on their own — no manual step needed.
• Response window. 30 days, usually within a week. If the request is more complex (e.g., "show me everything you have on me across all surfaces"), Amit may write back to confirm scope before fulfilling.
• If 30 days is going to slip. Manual fulfillment depends on Amit's availability. If a busy stretch, illness, or holiday is going to push a response past the 30-day window, Amit will reply within the first 14 days acknowledging your request, explaining the delay, and proposing a revised completion date (GDPR Article 12 permits a one-time 60-day extension with explanation). No request goes unanswered; if you don't hear back within 14 days of submitting, that itself is a signal something has gone wrong — nudge the same address again.
• Verification. Requests need to come from the email address whose data you're asking about. If you've changed email addresses, mention both — Amit will reply to both to confirm.

What's coming (and how it'll be handled)

The Lab is small today. One future change will introduce more data handling. We're documenting it here so you know what to expect:

• Account management for direct AI access. A future capability is letting external visitors sign in and interact with MogamboAI directly. When that ships, we will publish a separate, more detailed account-data policy at that time, covering: what's stored, retention windows, deletion-on-request, and conversation logging. We are committing in advance that conversations with MogamboAI will not be used to train external models or sold to data brokers.

If anything in this policy materially changes, the page will carry a dated "Updated" line and a brief note describing what changed.

Verifying any of the above

You don't have to take our word for it. From any Lab page:

• Open browser DevTools (F12) → Network tab → reload. Every outbound request is visible. You'll see requests to mogambo.info (for the page itself), analytics.mogambo.info (the tracking ping), and the self-hosted fonts. If you submit feedback, you'll see one additional POST to mogambo.info/feedback/submit — our own form-receiver, no third-party. Nothing else.
• Open the Application tab → Cookies. The cookie list for mogambo.info will be empty.
• Open the Application tab → Local Storage / Session Storage. Empty on content pages. The three tool pages listed under "What our tools store locally" will show keys you control.
• Run curl -I https://mogambo.info from a terminal. The response headers will show strict-transport-security (HSTS) and the standard set of security headers, plus the Let's Encrypt cert chain.

Found a discrepancy between this policy and what your browser's DevTools shows you? Tell us. We treat that as a security report and respond within a few days.

Last updated: 2026-05-14 — Phase G live: newsletter subscription added. Two new sections above — "If you subscribe to Mogambo's newsletter" covers what's stored, the double opt-in, send path through Mailjet, retention; "Requesting your data (or its deletion)" documents the GDPR-aligned data-export / right-to-erasure workflow (manual fulfillment, 30-day window).