Collect almost nothing
No account is required to play, and the server holds only a cloud save, a session, and any feedback you sent. Data we never take cannot be leaked.
TrustSecurity
The safest data is the data nobody holds. Aeonfold is built so that almost nothing about you exists on a server in the first place — and this page says exactly how the remainder is protected, where the limits are, and how to tell us if we got something wrong.
Section 1Principles
Four decisions, made early, that do more for your security than any amount of hardening after the fact.
No passwords to steal
We never handle credentials. Sign-in is delegated to Google, payment to Stripe. There is no password database here because there are no passwords.
Small surface on purpose
The site server is plain Node with zero third-party runtime dependencies — a handful of routes and no npm supply chain to inherit a compromise from.
Say what's true
Section 6 lists the things this design deliberately does not protect against. A security page that only lists strengths is marketing, not security.
Section 2How your data is protected
In transit
- Everything is served over HTTPS/TLS, with HSTS instructing browsers never to fall back to plain HTTP.
- Baseline security headers are set on every response, and the private admin console is additionally marked
no-storeandnoindex.
Your session
- Signing in with Google produces a session token that is cryptographically signed (HMAC-SHA256) by the server. A tampered token is rejected; the comparison is constant-time.
- The cookie is
HttpOnly(unreadable by scripts),SameSite=Lax(not sent from other sites' pages),Secureover HTTPS, and expires after 30 days. - Google's identity token is verified server-side on every sign-in — audience, issuer and expiry are all checked before a session is issued.
Your cloud save
- Saves are stored under a one-way SHA-256 hash of your account id, so the filename on disk reveals nothing about who you are.
- Reading or writing a save requires your own valid session — the account id is taken from the signed session, never from anything the client sends.
- Uploads are capped at 2 MB and must be well-formed JSON, so a hostile payload cannot fill the disk or wedge the server.
Payments
- Card details are entered on Stripe's own hosted checkout. They never reach our server, our logs, or our disk — there is no code path that could receive them.
- Whether a purchase was paid is always confirmed by asking Stripe's API. A client claiming “I paid” is never believed.
The admin console
- Its files live outside the public web root and are never served without an authenticated session.
- Access requires a Google-verified email address on a server-side allowlist. Client-side checks are never the gate.
- Every state-changing admin request carries a CSRF token derived from the session, which a cross-site page can neither read nor forge.
Section 3Abuse and availability
Aeonfold is one small server. Keeping it up is a security property too.
- Per-IP rate limits on every class of route — sign-in, checkout, feedback, cloud save, API and static files each have their own budget, so hammering one cannot starve the others.
- Request caps and timeouts — bodies are size-limited, headers and slow clients time out, and an edge proxy in front applies its own request, connection and body limits before traffic reaches the application.
- Feedback abuse controls — every field is length-capped, and the store stops accepting new entries long before disk pressure becomes a problem.
- Path handling — static file serving is guarded against traversal, and malformed URL encodings are rejected cleanly rather than crashing the process.
- Volumetric flooding is a hosting-layer concern rather than an application one, and is handled at the network edge — deliberately kept separate from the code that holds your save.
Section 4Inside the game
- Links are guarded. Only
httpslinks can ever be opened, and they always open in your real browser — never in an in-app web view that could imitate a login page. - Unclaimed links are never shown. A community or donation link is hidden until the handle behind it is genuinely registered, so nobody can squat a printed name and phish players with it.
- Saves are parsed defensively. A corrupted or hand-edited save cannot crash the game into an unrecoverable loop.
- Ads use the official SDKs — Google AdMob on mobile and Google's H5 Games Ads on the web, each with its own consent flow. Rewarded only: nothing plays that you did not start.
- No hidden telemetry. The game ships no analytics or crash-reporting SDK. Its only network calls are the ones this page and the Privacy Policy describe.
Section 5What we deliberately don't do
- No analytics, tracking pixels, fingerprinting or advertising cookies on this website.
- No selling, renting or sharing of personal data — there is no data broker relationship of any kind.
- No storing of payment credentials, ever.
- No reading of your local save. It stays on your device unless you upload it yourself.
- No dark patterns around consent: declining advertising consent costs you nothing in the game.
Section 6Known limitations, stated plainly
These are conscious trade-offs for a single-player game with cosmetic-only purchases. We would rather you read them here than discover them yourself.
- Your local save is editable. It is stored in ordinary browser or app storage, and a determined player can change it — including to grant themselves cosmetic unlocks. The game is single-player and nothing purchasable affects progression, so we accept this rather than build an anti-cheat backend that would cost you privacy and us the server bill. It is a breach of the Terms to use it to obtain paid items, and a tampered save is not something we can repair.
- Offline progress trusts your device clock. Moving the clock forward grants progress. Same reasoning as above.
- Cloud saves are backups, not a guarantee. They are stored on one server. Keep anything irreplaceable in mind accordingly — see Terms section 8.
- There are no leaderboards or multiplayer, which is precisely why the two points above are harmless. If competitive features ever ship, the trade-offs above get revisited before they do.
- One developer, no 24/7 rota. A serious report gets attention quickly, but not necessarily within an hour of it landing.
Section 7Reporting a vulnerability
If you have found a security problem in Aeonfold, please tell us. Reports are genuinely welcome — a quiet fix beats a public incident, and you will be thanked for it.
How to report
- Email aeonfold@gmail.com with SECURITY at the start of the subject line. That is the channel we watch for this.
- If email is not an option, the feedback form works — choose Bug report, start the title with SECURITY, and leave a contact detail so we can reply. Please keep exploit details out of the form where you can; a “contact me about a security issue” note is enough to start.
- Do not post details publicly — not in a Discord, a subreddit, an issue tracker or a video — until a fix has shipped.
What to include
- What the issue is and what an attacker could actually achieve with it.
- Clear steps to reproduce it, including the URL or screen, and the browser or device you used.
- Any proof-of-concept you have — a request, a payload, a short recording.
- Whether you believe any real player data was exposed.
What to expect from us
- An acknowledgement within 5 working days, from a person, not an autoresponder.
- An assessment and a rough timeline within 10 working days.
- A fix as fast as severity warrants — critical issues are treated as drop-everything work.
- Notification when it ships, and public credit in the changelog if you would like it. If real player data was affected, we will say so publicly and notify anyone involved.
Aeonfold is a free game made by one person: there is no paid bug-bounty programme, and we would rather be honest about that up front than imply a reward that will not arrive. What we can offer is a fast response, a real fix, and credit.
Section 8Scope
In scope
- aeonfold.space — the website, its APIs, and the browser version of the game.
- The Aeonfold mobile applications, once released.
- Anything that exposes another player's data, breaks authentication or the session mechanism, allows remote code execution, or takes the service down with modest effort.
Out of scope
- Volumetric denial-of-service, stress testing and traffic floods. Please never run these against a live server.
- Editing your own local save, or granting yourself cosmetic items on your own device — see section 6; this is known and accepted.
- Manipulating your device clock for offline progress — likewise known and accepted.
- Reports produced solely by an automated scanner, with no demonstrated impact.
- Missing hardening headers, missing rate limits or weak TLS configuration with no working exploit path.
- Self-XSS, clickjacking on pages with no state-changing action, and issues requiring a rooted, jailbroken or otherwise compromised device.
- Social engineering, phishing, or physical attacks against the developer or any provider.
- Vulnerabilities in third-party services (Google, Stripe, the app stores, hosting providers) — report those to them directly.
Section 9Safe harbour
If you research in good faith and follow the rules below, we will treat your work as authorised: we will not pursue legal action against you, we will not report you, and if a third party does, we will make it known that your testing was authorised under this policy.
- Only ever test against accounts and data that are your own.
- Stop at proof — do not access, modify, download or retain another player's data, and tell us immediately if you encounter any by accident.
- No denial-of-service, no spam, no destructive testing, and no automated traffic heavy enough to degrade the service for players.
- Do not pivot beyond the in-scope systems above.
- Give us reasonable time to fix the issue before disclosing it — 90 days is the default, and we will nearly always be much faster. If we are being slow, say so; we will agree a date rather than run out the clock.
- Comply with the law. This policy grants no authorisation that we do not ourselves have to give.