Privacy Policy

NomVote (“we,” “our,” or “the app”) is a group food-decision app available through the Android app, nomvote.com, installed participant PWA, and invitation links. This policy explains the information these surfaces use, including optional verification and push notifications. We do not sell personal information.

1. Information We Collect

Accounts and sessions:

• Verified account identity — registered users provide a phone number to Google Firebase Authentication. NomVote stores the verified phone number and Firebase identity on the account while it remains active.
• Display name (optional) — a name you choose; shown to people in sessions with you.
• Session and restaurant data — search coordinates, dining preferences, candidate snapshots, participants, rounds, decisions, and lifecycle events needed to run and recover a session.
• Legacy live-session mirror — for the current native live-update path, Google Firestore receives the session UUID, status, decided place ID, per-place like/pass/veto counts, participant account UUIDs, voter progress counts, and update time. PostgreSQL remains the authoritative store.
• Votes and receipts — ballot choices, abstentions, idempotency evidence, and result snapshots used to compute and preserve the group result.

Anonymous invitation-link participants:

• The browser receives random session-scoped credentials and stores only bounded resume, draft, submission, and receipt state. Anonymous ballots and receipts are not represented as a verified human identity.
• During eligible anonymous participation, NomVote automatically records only approved coarse entry, ballot-receipt, install-offer, browser, OS, and device categories. Raw IP addresses and full user-agent strings are not stored in the NomVote application database.

Contacts, sharing, and optional features:

• Route 1 contact matching — when you tap “Load and Match Device Contacts” and grant Android Contacts access, every normalized phone number in the address book is sent over TLS, in batches of up to 500, for a transient match. The server derives keyed comparison digests; raw candidate numbers are not written to the application database or application logs. Separately, selecting or restoring a saved group transiently rechecks that group's unresolved saved phone numbers without reading the device address book.
• Legacy contact sync — the older opt-in sync sends SHA-256 phone hashes and optional contact display names. Those values are stored for matching and removed after they have been stale for 30 days.
• Selected recipients — unresolved phone numbers may remain in an Android session draft or saved group and may be handed to the operating-system share or messaging screen when the host chooses. NomVote does not treat selection as consent and cannot tell whether the host sent or the recipient received the message. A group message can expose recipients' phone numbers to one another.
• Place tags — notes or labels you attach to restaurants (e.g., “great patio”), stored against your account. Global tags are shared; personal tags can be shown to a session group with your display name; and “Only me” tags are limited to your participant view. When a shared tag is visible, NomVote may record an impression, a like, or a final-decision event with the tag, account, and session identifiers to measure tag use. These events do not change votes or results. A reported shared tag is hidden pending operator review; the operator can review the tag text, kind, restaurant identifier, author display name, report count, and first-report time, then restore it or keep it removed.
• Home-cooked meals — a title, optional description, and optional photo you save. The photo is hosted at a random public URL: it is not listed publicly, but anyone who obtains the URL can fetch it. Meal details, including that URL, can be copied into a session for its participants.
• Dietary preferences & favorite cuisines — stored in your settings to filter session results.
• Gender (broad category) — completely optional. If you choose to provide it, we store one of: Male, Female, Non-binary, Other, or Prefer not to say. This is used only for anonymous aggregate reporting (e.g., “35% of Female users prefer Sit Down over Take Out”). It is never linked back to your account in any report.
• Age group (broad category) — completely optional. If you choose to provide it, we store one of eight ranges (e.g., 25–34). Used only for the same anonymous aggregate reporting as gender above. Never linked to your account in any report.
• Household type (broad category) — completely optional. One of: Single, Couple, Family with kids, Roommates, or Other. Used only for anonymous aggregate reporting. Never linked to your account in any report.
• Primary use case (broad category) — completely optional. How you most often use NomVote: Family, Date nights, Work lunches, Friend groups, or Other. Used only for anonymous aggregate reporting. Never linked to your account in any report.
• Feedback and uploads — the title, description, and optional screenshot you choose to submit. NomVote automatically adds your display name, verified phone, account UUID, most recent hosted session UUID, platform/device model, app version/build, and submission time so the report can be diagnosed.
• Push subscriptions — encrypted FCM or Web Push endpoint material, a random device identifier, permission time, client family, and delivery-state evidence. Notification payloads contain generic event and session-routing fields, not phone numbers, names, votes, or restaurant results.
• Verification abuse controls — before a requested verification message, NomVote derives pseudonymous HMAC bucket keys from the direct-peer IP, random device identifier, phone number, and, when applicable, session and account identifiers. The application database stores only those bucket keys, counters, and expiry times, not the raw phone or IP in these records. The browser also stores a random device identifier and a short local cooldown record even when push is not enabled.
• Account abuse restrictions — when needed to protect the service, NomVote stores versioned keyed identity digests and an encrypted E.164 phone snapshot in a separate restriction record. Operator lists show a masked number; viewing the full number is an explicit audited action. Restriction apply, renewal, permanent, override, reinstatement, and reveal actions retain the operator account identifier, bounded reason, status change, and time.
• Operational logs — NomVote application request logs record a short random request ID, method, sanitized path family, response status, and duration. Application and infrastructure providers may also process operational error and request metadata needed to run and secure the service.

2. How We Use Your Information

• Authenticate your identity and maintain your account.
• Find nearby restaurants matching your session preferences.
• Compute group voting results and deliver push notifications about outcomes.
• Match selected contacts with verified NomVote accounts.
• Generate aggregate, anonymous usage statistics to improve the app (e.g., most popular cuisines, session completion rates, demographic breakdowns where users have opted in).
• Measure whether visible restaurant tags are shown alongside likes or a final decision, without using those events to alter a ballot or result.
• Respond to feedback or bug reports you submit in-app.

3. Information Sharing

We do not sell, rent, or trade your personal information. We share data only in these limited circumstances:

• Google (Firebase, Firestore, Places, Maps, and Mobile Ads) — Firebase handles optional phone verification, its selected browser identity persistence, and native push delivery. Firestore processes the pseudonymous live-session mirror described above. Places processes search location and restaurant queries. The Android Maps SDK processes map views; opening directions or a search in the external Google Maps app hands that request to Google. The Android app initializes Google Mobile Ads and makes banner requests by default; Google's SDK may process device, network, ad, and request metadata under Google's terms and the project's live ad settings.
• Browser push services — the push service selected by your browser or operating system processes the subscription and generic push needed to deliver a Web Push notification.
• Cloudflare and hosting infrastructure — these providers process network traffic and ordinary request metadata to terminate TLS, protect the service, and deliver requests. They may technically process request content while providing those functions.
• Your chosen share or messaging app — when a host explicitly shares an invitation or result, the operating system and selected provider process the recipients and message under their own terms.
• Support email and Forgejo — the configured support email service receives the feedback text, automatically added account/session/device metadata, and optional screenshot. NomVote's Forgejo issue tracker receives the text and metadata plus a note when a screenshot was included; it does not receive the screenshot attachment. Do not include information in a feedback report that is not needed to investigate it.
• Twilio — Twilio is not used for Route 1 phone verification, invitation texts, decision texts, or push fallback.
• Legal requirements — we may disclose information if required by law or to protect the safety of our users.

4. Data Retention

• Account profile, verified phone, settings, saved groups, and tags remain until you remove them or delete the account.
• Tag interaction records follow their linked tag, account, or session deletion rule. Reports and an append-only moderation ledger retain immutable tag and actor/subject references, action, state change, bounded reason, report count, and time after the tag or account is deleted. They do not contain tag text or phone numbers.
• Account abuse restrictions and their append-only lifecycle/reveal audit events survive account deletion so deleting and recreating an account cannot bypass an active restriction. Time-limited restrictions default to one year and may expire or be renewed; an operator may instead make one permanent or explicitly override it. NomVote has not yet published a separate automatic deletion cutoff for this security evidence.
• Route 1 decided-session core data and results are scheduled for removal 365 days after the decision. Canceled and expired session data is scheduled for removal after 30 days. Active sessions remain until they reach a terminal state.
• Anonymous browser credentials and identifying links follow the applicable terminal session cutoff. Coarse browser analytics and delivery/outbox evidence are retained for 90 days.
• Revoked or invalid push endpoints are retained for up to 30 days for bounded cleanup. Active endpoints remain until opt-out, invalidation, expiry, or account deletion.
• Legacy contact hashes and uploaded display names are removed after 30 days without a fresh sync. Route 1 raw contact candidates are transient.
• Feedback copies in support email and Forgejo follow those systems' support workflow and retention. Account deletion does not currently remove those external copies automatically. Contact us to request review, correction, or removal where the support system permits it.
• Deleted records may remain in immutable backup copies; application deletion cannot selectively edit a backup. NomVote has not yet published a verified backup-rotation or restore-handling promise for those copies.
• Home-meal records remain until you delete the meal or account. Account deletion durably queues eligible photo-file cleanup and retries failures; deleting an individual meal removes its eligible photo immediately.
• The legacy Firestore live-session mirror has no separately verified public deletion cutoff today. Account deletion durably queues reconciliation of affected retained session documents without the deleted participant UUID. Provider failures retry automatically. Bounded terminal failures remain visible to an operator and can be deliberately requeued.
• NomVote has not yet published a verified application-log or infrastructure- log deletion cutoff. Provider-side logs follow the provider's configuration and terms.

5. Children’s Privacy

NomVote is not directed at children under 13. We do not knowingly collect personal information from children under 13. If you believe a child has provided us with personal information, please contact us so we can investigate and apply the deletion process available for the affected data.

6. Security

NomVote uses TLS in transit, token-based authorization, origin and CSRF controls where applicable, rate limits, and restricted administrative access. Push endpoint material and provider references are envelope-encrypted by the application. This statement does not claim that every database field, including the verified account phone field, has separate field-level encryption. No system is perfectly secure.

7. Your Rights & Choices

• Access and correction: app settings expose and allow changes to the profile and preference fields supported by the current client. Contact us for another access or correction request.
• Account deletion: use the in-app deletion action or the public deletion page. Local identifying account, group, contact, tag, and endpoint records are removed transactionally. Ballot, receipt, and session content may remain deidentified until the applicable 30-day or 365-day session cutoff. Firebase identity, linked external document, and eligible image-object cleanup are durably queued with the local deletion, run after commit, and retry provider failures. Bounded terminal failures remain blocked from account recreation and visible for operator follow-up.
• Anonymous browser data: you can clear site data to remove local resume state. A submitted anonymous ballot or receipt may remain with the session until its retention cutoff.
• Notifications: native and installed-PWA controls can revoke the endpoint. The PWA also provides “Sign out and forget this device.” If cleanup is temporarily unavailable, the client reports that state and retries rather than claiming success.
• Advertising: the current Android app does not provide an in-app advertising consent or disable control. A generic ad request does not, by itself, establish whether the provider serves a personalized ad; Google and Android account/device controls may provide additional choices.
• Opt-out of demographic data: gender, age group, household type, and primary use case fields are optional. The current Android client does not expose those controls; contact us to review, correct, or clear an existing value until the controls are restored.

8. Changes to This Policy

We may update this policy as the product changes. The “Last updated” date identifies the published version. A statement on this page does not activate a provider or messaging program that the product does not currently use.

9. Contact Us

Questions or requests about your data? Contact us at:
privacy@nomvote.com