Privacy Policy

1. Data we don't collect

We only store the personal data described in this policy — nothing beyond what's needed to run the Service. We don't buy, sell, or trade personal data, and we don't run advertising of any kind. In particular:

• Sign-in to the dashboard doesn't record your IP address or geographic location — this is explicitly disabled in our authentication provider's configuration.
• Submitting a request through the browser userscript doesn't require an account, and we don't collect your email address, real name, or Waze account credentials through that flow.
• We never see or store your Waze account password.

2. Data we do collect

Dashboard accounts (editors, moderators, admins)

• Name and email address, provided when your account is created or invited.
• A securely hashed password, if you sign in with email/password.
• If you use "Sign in with Discord", your Discord account ID and the email address Discord provides us, used only to link or authenticate your existing dashboard account.
• Session tokens (via cookies) that keep you signed in.
• If you enable browser push notifications, an opaque push subscription endpoint and encryption keys issued by your browser — these identify a browser installation, not you personally.

Requests submitted via the userscript

When a Waze editor submits a downlock/uplock/imagery/PUR request from inside the Waze Map Editor, the Service stores:

• Your Waze editor username (as entered/detected in WME) and editor rank.
• The WME permalink to the relevant map location, and any notes you add.
• An optional screenshot of the map viewport, if you choose to attach one.
• The request type, lock level, and timestamps.

A Waze username is a public in-game identifier you chose yourself, not your legal name — but we recognize it can still identify you, and we treat it accordingly under this policy.

Integration credentials (admin-configured)

Global admins and users who configure notification channels may store webhook URLs, bot tokens, Google service-account keys, or SMTP/Postmark/Mailgun credentials so the Service can deliver notifications on their behalf. These are encrypted at rest (see § 5) and are never displayed again after saving.

3. Notifications and external providers

A country's admins choose which of the following channels, if any, receive a copy of a submitted request (permalink, notes, lock level, submitter username, and screenshot if attached). We only send data to a channel that's been deliberately configured — nothing is sent to a third party by default.

• Slack — via an Incoming Webhook or bot token, posted to a channel of the admin's choosing.
• Discord — via a server webhook (message or forum-thread post).
• Telegram — via the Telegram Bot API, to a chat/channel the admin controls.
• Google Chat — via a Google Chat incoming webhook.
• Google Sheets — via the Google Sheets API, appending a row to a spreadsheet the admin's Google service account has been given access to.
• Email — via Postmark, Mailgun, or an SMTP server the admin has configured with their own credentials.
• ntfy and Gotify — self-hosted or third-party push-notification servers, posted to an endpoint the admin controls.
• Custom webhook — a plain JSON payload posted to any URL the admin supplies.
• Web Push — native browser notifications for signed-in users who opt in via "Notify me". Delivery is relayed through your browser vendor's push service (e.g. Google, Mozilla, or Apple), which only sees an encrypted payload and the delivery endpoint, not its contents.
• Public RSS feed — a read-only feed of recent requests that anyone can pull into their own RSS reader. This isn't a push to a third party; it's the same public request data already shown on the dashboard, made available for you to fetch on your own terms.

None of these providers receive dashboard account data (your login email/password) — only the request content described above, and only for the countries/regions their channel is scoped to.

4. Analytics — PostHog

We use PostHog (hosted in the EU) for product analytics — understanding which features are used and catching errors. There are two categories:

• Browser analytics (consent-gated) — page views, button/feature usage, sign-in events, and client-side error capture in your browser. This is off by default and only starts after you accept it in the cookie banner (see § 6); you can withdraw consent at any time from that banner. For signed-in dashboard users who accept, your user ID, name, and email are attached to your analytics profile so we can distinguish one editor's usage from another's.
• Server-side operational events (not cookie-gated) — when the API itself performs an action (e.g. a request is created, a notification channel is tested, an invite is sent), our server logs that event to PostHog for operational monitoring, similar to a server access log. These use your account ID if you're signed in, or a random per-submission identifier for anonymous userscript submissions — never anything else that identifies you — and aren't affected by the cookie banner choice, since they're a direct, necessary record of the action the API just performed rather than behavioral tracking of you browsing the site.

Declining browser analytics doesn't affect your ability to use the Service.

5. Cloudflare and infrastructure

The Service runs entirely on Cloudflare's platform:

• Cloudflare Workers — hosts the dashboard and API, and sits in front of every request to the Service.
• Cloudflare D1 — the database storing accounts, requests, notification-channel configuration, and encrypted credentials.
• Cloudflare R2 — stores screenshots attached to requests.
• Cloudflare Turnstile — a privacy-preserving bot-verification challenge on the sign-in and password-reset forms, used to block automated abuse. It does not track you across other sites.

As our infrastructure provider, Cloudflare processes this data on our behalf under its own privacy and security commitments; it is not used by Cloudflare for its own purposes.

6. Cookies

• Strictly necessary — a session cookie that keeps you signed in to the dashboard. These can't be disabled and aren't covered by the cookie banner, since the Service can't function without them.
• Analytics (optional) — PostHog cookies/local storage, set only after you accept analytics in the cookie banner. See § 4.
• Cloudflare Turnstile — may set a short-lived cookie while verifying you're not a bot on the sign-in/password-reset forms.

You can change your analytics choice at any time — clear your browser's local storage for this site to see the cookie banner again.

7. Security

• All traffic is served over HTTPS via Cloudflare.
• Passwords are hashed, never stored or logged in plain text.
• Third-party integration credentials (bot tokens, service-account keys, SMTP/email credentials) are encrypted at rest with a dedicated encryption key held only as a server-side secret, and are never re-displayed after saving.
• Access to admin functions (Admin, Reports) requires an authenticated session and is scoped by role and by country/region.
• Cloudflare Turnstile helps prevent automated credential-stuffing and abuse of the sign-in and password-reset forms.

No system is perfectly secure, but we design the Service to minimize what personal data it holds in the first place, so there's less to protect and less at risk if something goes wrong.

8. Data retention

Request records (including notes, screenshots, and permalinks) are automatically and permanently deleted 24 hours after submission, or sooner if an admin removes them manually. Account and configuration data (users, countries, channels) is kept for as long as they're operationally useful, and deleted when an admin removes them. Analytics events in PostHog follow PostHog's own retention settings for our account.

9. Your rights

Depending on where you're located, you may have rights under data protection law (such as the GDPR) to access, correct, export, or delete your personal data, or to object to or restrict certain processing. To exercise any of these, or for any other privacy question, email wazer@wazetools.com. We'll respond as soon as we reasonably can.

10. Changes to this policy

We may update this policy as the Service changes. Material changes will be reflected by updating the effective date above.