Security

Everything you enter into the scheduler is held in your own browser, in a storage area called IndexedDB, and is never transmitted to us. This applies to every account, free and Pro alike.

When your browser needs a travel time, it sends a pair of postcodes and nothing else — no names, no addresses, no account identifier. Those postcode pairs are cached so we do not repeat the same lookup, and the cache records nothing about who asked.

A carer’s round is encoded into the web link itself, after the “#” symbol. Browsers never transmit that part of a URL — it is stripped from the request and from the referrer header — so the round passes from your device to theirs without reaching our servers, our logs, or our analytics.

There is nothing to guess. Most sharing links work by putting a short secret code in the address, which points at a copy of the data sitting on a server. Anyone who works out a code reaches the data behind it, and a breach of that server exposes every round at once.

There is no code here and no copy. The link does not refer to a round; it contains one, as roughly a thousand characters of compressed data. Changing characters at random does not reveal somebody else’s round, because there is no store of rounds to land in — it produces something that fails to decode. There is no list to enumerate, no database to breach, and nothing to hand over if we were compelled to.

What that does not protect against. Because the link is the round, anyone holding the link can read it. Treat it exactly as you would the printed rota: send it to the person doing the round, and no further. It also cannot be withdrawn once sent, since there is no server-side record to revoke — so issue a fresh link each day rather than relying on an old one expiring, and expect it to remain readable in the recipient’s browser history.

• Accounts. Email and authentication are handled by Supabase. Passwords are hashed by them and never seen by us.
• Payments. Card details go directly to Stripe. We hold only a customer reference.
• Database access rules. Every remaining table uses row-level security, so an account can only ever read its own record. Administrative access is restricted to the account owner.
• Diagnostics. Error reports have the fragment stripped from the URL before storage, so a shared round can never appear in them.

• HTTPS everywhere, with HSTS set for two years including subdomains. Plain HTTP is redirected before anything is served.
• A Content-Security-Policy restricting scripts, styles, images and connections to a short list of known origins.
• X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy set on every response.
• Pages that display a round are excluded from analytics entirely and marked noindex.

We rely on Cloudflare (hosting), Supabase (authentication and our own records), Stripe (payments), OpenRouteService (travel times from postcodes) and postcodes.io (postcode validation). None of them receives your clients’ details, because we never have them to pass on.

If you believe you have found a security issue, please email support@georoutes.co.uk with enough detail to reproduce it. Please give us a reasonable opportunity to fix it before disclosing it publicly.

We will not pursue legal action against anyone acting in good faith who reports an issue, avoids privacy violations and does not degrade the service while testing. Please do not run automated scanning that places load on the site, and do not access data belonging to anyone but yourself.

This policy is also published at /.well-known/security.txt.

GeoRoutes is run by one person. There is no 24/7 security operations centre, no formal certification such as ISO 27001 or Cyber Essentials, and no contractual uptime guarantee. What there is instead is an architecture that holds as little as possible, so that the consequences of any failure are correspondingly small.

If your organisation requires certification or a signed data processing agreement before adopting a supplier, please get in touch and we can discuss what is possible.

See also our Privacy Policy and Terms of Service.