Privacy policy (draft)
DRAFT. NOT LEGAL ADVICE. NOT FOR PUBLICATION.
Drafted by an AI agent (spec decision 10: AI drafts, a qualified lawyer reviews). It must be reviewed and approved by a lawyer qualified in Iraq (and later Australia, and in the Kurdistan Region if relevant) before any use with real users. Nothing here has been verified by a lawyer. Items marked [TBC] are to be confirmed; items marked [UNVERIFIED] are facts or legal points not confirmed against a source. See
assumptions.md,lawyer-review-brief.md,data-processing-records.md.Brand: "Frontra" is an internal working name. The product name, company name, domain and contacts below are placeholders to be filled from the brand configuration (ADR 0008).
| Field | Value |
|---|---|
| Spec reference | SEC-03 (Jira KAN-133), docs/product-spec.md v0.2 |
| Version | 0.1 draft, 2026-10-29 |
| Effective date | [TBC] |
| Languages | English (master). Arabic and Sorani Kurdish are machine translations, see privacy-and-terms-summary.ar.md and privacy-and-terms-summary.ckb.md. Which version prevails if they differ: [TBC: lawyer] |
Part A. Plain-language summary (for everyone)
- If you join a queue as a customer, you do not need an account. We create a ticket for you. You can give a name and a phone number, but these are optional. If you give a phone number and agree, we can send you an alert (web push, WhatsApp, or SMS where the venue has enabled it) when your turn is near.
- The venue (the shop, cafe, clinic or other business) decides to use the queue. We run the service for the venue.
- We do not sell your data and we do not show advertisements based on it. [TBC: confirm this remains true; promo slots are planned for R2]
- Phone numbers are stored in protected form (section 9) and kept only as long as needed. Retention periods are [TBC].
- We use service providers to host the service and send messages. Your data is processed on servers in the Netherlands (Amsterdam) and by messaging providers. See section 7.
- You can ask to see, correct or delete your data, and to stop messages at any time (section 11).
- Clinics: queue tickets at clinics are designed to carry no medical details. Please do not type health information in any free-text field.
- Contact: [TBC: privacy contact email and postal address].
Part B. Full policy
1. Who we are and which role we play
1.1 This policy is issued by [TBC: legal name of the operating company, jurisdiction, registration number] ("we", "us"). Per working assumption (spec decision 6) the product is owned by a new company, and a trusted Iraqi partner or local entity invoices and collects payments in IQD. [TBC: lawyer to confirm which entity is the controller, and whether the Iraqi partner is a joint controller, processor, or independent party for payment data].
1.2 The service has two kinds of users:
- Venue users: owners, managers and staff of businesses that use the platform (our customers), and agents who onboard venues.
- Queue customers: members of the public who join a venue's queue, normally by scanning a QR code or opening a short link.
1.3 Roles [TBC: lawyer]. Our working view:
| Data | Our role | Venue's role |
|---|---|---|
| Venue user account, billing and agent data | We decide purposes and means (controller) | n/a |
| Queue ticket data (name, phone, party size, ticket attributes, notifications) | [TBC] We process on the venue's behalf to run its queue (processor), and decide some purposes ourselves such as security, abuse prevention and service analytics (controller) | Decides to use the queue and which optional fields to enable (controller) |
1.4 Whether the "controller" and "processor" concepts, borrowed from EU law, have legal meaning in Iraq is [UNVERIFIED]. They are used here for clarity only.
2. Scope and legal context
2.1 This policy covers the apps of the platform: customer web app (PWA), staff app, TV display, owner portal, admin console and, from R1b, the agent portal.
2.2 Legal context (all [UNVERIFIED], for the lawyer to confirm): secondary sources consulted by the drafter state that Iraq has no comprehensive personal data protection law in force (only scattered provisions and a draft law), that the Kurdistan Region has no comprehensive data protection law, and that Australia's Privacy Act 1988 applies subject to a small-business exemption that was still in force when the drafter searched. See lawyer-review-brief.md section 2 for sources and caveats. Because the service is hosted in the European Union (Netherlands), EU data protection law may apply in some way [UNVERIFIED: depends on the facts and the lawyer's view]. Until advised otherwise, this draft follows good-practice principles (transparency, minimisation, purpose limitation, security, user rights) and does not claim to meet any named law.
3. Data we collect
Only data the product needs. The list reflects the product specification, ADRs and migrations at the draft date; items still in design are marked.
3.1 Queue customers (anonymous)
| Data | Source | Notes |
|---|---|---|
| Ticket data: queue, ticket number, status history (waiting, called, serving, done, no-show, cancelled, skipped), timestamps | Created when you join and as staff act | Append-only event history per ticket |
| Optional name | You type it | Optional. Clinic template: not collected by default; numbers only on displays (VEN-04) |
| Optional phone number | You type it | Optional. Used only for alerts. Stored protected (section 9). Consent flag and proof of consent recorded (SEC-05) |
| Ticket attributes defined by the venue's template (for example party size, selected service, vehicle plate, doctor chosen) | You select or type | Validated structured fields. Clinic template: no medical fields |
Language choice, and a session identifier so the page restores your ticket (customer_session) | Your browser | See section 12 |
| Web push subscription (browser endpoint and keys) | Your browser, only if you accept the prompt | Used only to alert you for this ticket |
| Notification records: which alert, channel, delivery status, cost | System | For delivery, abuse and cost control (NOT-07) |
| Technical data: IP address, device and browser type, request timing | Automatically, at Cloudflare and our servers | For security, rate limiting and abuse prevention. Application logs are designed not to contain phone numbers, names or free text (ADR 0004). Whether IP addresses appear in logs, and for how long: [TBC] |
| Review prompt interaction | You | Only if the venue enables it |
We do not collect: precise location (a location check-in is a possible future optional venue feature, R2, off by default), customer payment card data, your contacts, or advertising identifiers. [TBC: confirm at each release]
3.2 Venue owners, managers and staff
| Data | Notes |
|---|---|
| Name, phone number and/or email | For sign-up and one-time-code login |
| Role, venue access, invitation records | |
| Device sessions (device name, last seen, approximate city [TBC]) and PIN (stored as a slow hash, never plain, as proposed in the threat model G-08) | Staff devices stay logged in until revoked |
| Venue and business details: name, logo, address, hours, timezone, languages, queue and service configuration | Business information, normally not personal |
| Audit log of sensitive actions: actor, time, target | Security and dispute resolution |
| Terms and privacy acceptance record: version, time, actor, language | TEN-09 |
| Support and feedback reports with automatic context (venue, device, app version, recent errors) | FDB-01 |
| Billing data (commercial release): plan, payments, who collected, receipts and invoices, tax details | Kept for accounting and tax [TBC: period and law] |
3.3 Agents (commercial release)
Name, phone, identity verification details [TBC: what is collected], venues onboarded, payments recorded, commission lines and payout status. A separate agent agreement governs the relationship; this policy covers the personal data.
3.4 Data we do not intend to hold
Logs, analytics events and error reports are designed not to contain phone numbers, names, free-text ticket fields, message bodies, one-time codes, tokens or session identifiers (ADR 0004). Product analytics are internal and no personal customer data leaves the platform (ANA-01).
4. Why we use data and our legal bases
Bases below use common vocabulary. [TBC: the lawyer must choose bases that exist and apply under Iraqi law, Kurdistan Region law and, for hosting and any EU-connected processing, EU law].
| Purpose | Data | Basis (working) |
|---|---|---|
| Run the queue: create ticket, show position and estimate, call you, let staff manage | Ticket data, session identifier | Providing the service you asked for / the venue's operation |
| Alert you when your turn is near | Phone number, push subscription, notification records | Your consent (SEC-05), withdrawable at any time |
| Log in, secure accounts, prevent abuse and fraud (rate limits, one-time code limits, queue flooding) | Technical data, phone, device sessions | Legitimate interests / security [TBC] |
| Provide the service to venues; manage accounts, plans, billing, agent commissions | Venue user, billing, agent data | Contract; legal obligation (accounting, tax) [TBC] |
| Reports for venue owners (waits, no-shows, peak hours) | Ticket events | Contract with the venue |
| Improve the product (internal funnel analytics from domain events) | Pseudonymous events | Legitimate interests [TBC] |
| Support, feedback, dispute resolution, audit | Audit log, reports, ticket events | Legitimate interests; contract |
| Backups and disaster recovery | All stored data, encrypted | Legitimate interests; security |
| Legal compliance and lawful authority requests | As required | Legal obligation [TBC: section 14] |
We do not use customer data for marketing broadcasts. (Opted-in campaigns are a possible R2 feature and would need separate consent and a policy update.) [TBC]
5. Messaging: WhatsApp, SMS, push
5.1 Opt-in. Alerts by phone are sent only if you provide your number and consent at join. We record proof of consent (what you agreed to, when, the policy version) (SEC-05).
5.2 Verification and misuse. Anyone could type another person's number. The security design proposes verifying that you control the number before alerts, and honouring STOP at once (threat model G-12). [TBC: confirm implemented; do not publish a claim of verification until it is]. If you receive a message you did not ask for, reply STOP or contact us (section 15) and we will block your number.
5.3 Channels. Web push and in-app alerts come first. WhatsApp is a fallback if you have not acknowledged the alert after a fixed delay and WhatsApp is enabled for that venue (NOT-05). SMS is off by default and sent only when enabled for the venue and consented. Messages use approved templates in Arabic, Sorani Kurdish or English. Clinic templates use neutral wording.
5.4 One-time codes for login are sent by WhatsApp or SMS to venue users.
5.5 Risks to know. Messages appear on your lock screen and in WhatsApp history; if the phone is shared, others may see that you were in a queue at a venue. WhatsApp is a service of Meta with its own terms and privacy practices. Carrier or data charges, if any, are your own.
5.6 Withdrawing consent. Reply STOP, leave the queue, or ask us. Withdrawal does not affect earlier messages.
6. How long we keep data (retention)
docs/security/data-inventory.mddoes not exist in the repository (main) at the draft date, so retention periods are TO BE CONFIRMED with SEC-04. Where the repository states a proposed value it is quoted with its source. Proposed values are not approved.
| Data | Retention | Source / status |
|---|---|---|
| Active ticket and session | Until the ticket ends or the venue's closing time (QUE-09) | Spec; [TBC] |
| Ticket history and events | Per plan: Free plan 7 days (BIL-03); paid plans [TBC] | Spec BIL-03 (limits are editable data) |
| Phone number (stored protected) | [TBC]. Spec says "retention-limited" with no period. Proposal for the lawyer: delete or irreversibly anonymise shortly after the ticket ends unless the customer asks to be remembered | [TBC] |
| Consent proof records | [TBC] (must outlive the data they justify) | |
| Application logs | Proposed 30 days at info level, longer only for security events | ADR 0004 open question; [TBC] |
| Outbox and processed-event technical records | Proposed 14 and 30 days | ADR 0003 open question; [TBC] |
| Audit log | [TBC] | |
| Venue user account data | While active, and [TBC] after cancellation | TEN-08 (R1b) |
| Billing records | [TBC: legal accounting period for the invoicing entity] | |
| Backups (encrypted exports) | Each export 14 days, then one per week for 4 weeks, then one per month for 3 months: about 3.5 months maximum. Railway point-in-time recovery window about 4 weeks | docs/infra/backup-restore.md (proposal, not approved) |
| Deleted data in backups | Removed from the live system on request, and from backups when the last export containing it expires; backups are not edited | docs/infra/backup-restore.md section 6 |
7. Who receives data (processors and sub-processors)
We share data only with providers needed to run the service, under contract [TBC: data processing agreements to be signed and reviewed by the lawyer]. Locations are as understood by the drafter and [UNVERIFIED] unless stated.
| Provider | What for | Data | Location |
|---|---|---|---|
| Railway | Hosting of application, Postgres database, Redis cache and jobs | All platform data | Amsterdam, Netherlands region (spec section 4). Railway is understood to be US-headquartered, so access from outside the EU may be possible [UNVERIFIED] |
| Cloudflare | Proxy in front of the service (TLS, DDoS and bot protection, DNS) | Traffic including IP addresses and request content in transit | Global network, processed at edge locations near the user [UNVERIFIED] |
| Cloudflare R2 (the "backup storage provider") | Encrypted nightly database exports | Encrypted dump, additionally encrypted with age before leaving Railway; phone numbers inside are ciphertext or keyed hash. Provider cannot read content without our key | Bucket jurisdiction [TBC: EU jurisdiction intended, unverified] |
| Twilio | WhatsApp and SMS sending, one-time codes (Verify), delivery callbacks | Phone number, message content (template variables such as ticket number, venue name) | US-headquartered; processing locations [UNVERIFIED] |
| Meta (WhatsApp) | Carries WhatsApp messages | Phone number, message content and metadata, under WhatsApp's own terms | Global [UNVERIFIED] |
| Browser push services (run by browser vendors such as Google, Apple, Mozilla) | Deliver web push alerts | Encrypted push payload and push endpoint | Global [UNVERIFIED] |
| Error tracking provider | None selected at draft date: ADR 0004 approved structured logs only; a tracker (for example Sentry) may be added later behind an interface with personal data scrubbed. Update this table if added | none yet | [TBC] |
| Payment collectors: our Iraqi partner or local entity, and agents | Collect cash or local payments (commercial release) | Payment details of venues | Iraq [TBC] |
We may disclose data if required by law or valid legal process (section 14).
8. International transfers
8.1 Our servers are in the Netherlands (European Union). Most users are in Iraq, so data moves from Iraq to the EU when you use the service. Some providers (Twilio, Meta, Railway, Cloudflare) are understood to be headquartered or to operate outside both Iraq and the EU, notably in the United States [UNVERIFIED].
8.2 [TBC: lawyer.] Whether Iraqi law restricts sending personal data abroad, and whether EU transfer mechanisms (for example standard contractual clauses) are needed with sub-processors, is not verified. Secondary sources indicate no statutory cross-border transfer regime in Iraq [UNVERIFIED]. EU hosting was chosen over Gulf regions deliberately (spec decision 4). A later Australian regional deployment would keep Australian data in Australia (spec R5); it is not live.
8.3 By using the service you acknowledge these transfers. [TBC: whether a transfer notice or consent is useful or needed; do not rely on consent where it is not freely given.]
9. Security measures (high level)
- Encrypted connections (HTTPS) between your device and Cloudflare, and between Cloudflare and our servers; encrypted database and cache connections where supported.
- Each venue's data is separated from other venues' at database level (row-level security), tested automatically on every build.
- Phone numbers are stored in protected form: a keyed hash for matching, and application-level encryption where the number must be recovered to send a message; masked display to staff. [Proposal in
docs/security/encryption-and-secrets.mdsection 4, not approved. TBC before publishing this sentence] - Secrets held in a platform secret store, never in code; secret scanning and dependency and container vulnerability scanning in development.
- Encrypted off-platform backups, access limited to named people.
- Access control by role and venue; audit logging of sensitive actions; revocable device sessions; rate limiting and abuse controls.
- Logging designed to exclude phone numbers, names and free text.
- Independent security review before public launch (SEC-07, planned).
No system is perfectly secure. A known limit: provider disk encryption at rest is not confirmed (docs/security/encryption-and-secrets.md section 3). We will notify affected venues and users, and authorities where required, if a breach occurs [TBC: obligations and timelines under applicable law] (incident runbook SEC-08, planned).
10. Children
10.1 We do not knowingly collect a child's phone number for alerts without a parent or guardian's involvement. [TBC: lawyer to decide an age threshold and approach under Iraqi law.]
10.2 Venue accounts are for adults (owners and staff). Venues must not enter children's personal data beyond what is needed (for example a first name on a ticket).
10.3 Clinics may involve minors. See section 13.
11. Your rights and choices
Subject to applicable law [TBC: lawyer to state the rights that actually apply], we aim to honour these requests:
- Access: ask what we hold about you.
- Correction.
- Deletion: we delete or anonymise your ticket data on request; backups expire as in section 6.
- Withdraw consent / stop messages: reply STOP or contact us.
- Object to or restrict some processing.
- Data export for venues (CSV, commercial release, plan dependent).
- Complaint: to us first, and to a competent authority [TBC: no authority identified by the drafter for Iraq or the Kurdistan Region].
Customers are anonymous. To act on a request we may need the ticket number, venue and time, or the phone number, and may need to verify you control it (for example by a code). We will not ask for more identity data than necessary. Response time target [TBC]. For data a venue holds itself (for example exports it made), the venue is responsible and we help. Venue data deletion at cancellation: TEN-08 (R1b).
12. Cookies, local storage and similar technologies
12.1 Customer web app: stores your language and a ticket or session token on your device so that closing and reopening the page restores your ticket (CUS-05). This is essential to the service. Whether it is a cookie, local storage or IndexedDB is [TBC: engineering to confirm; the code for this is not in the repository yet]. The threat model proposes an HttpOnly, Secure, SameSite cookie scoped to the venue, expiring at end of day (G-02).
12.2 If you accept notifications, your browser stores a push subscription. You can remove it in browser settings.
12.3 Staff and owner apps: session tokens and device-session identifiers for login. Paired TV displays store a pairing credential.
12.4 A service worker caches app files for speed and offline use.
12.5 We do not use advertising cookies or third-party analytics trackers on customer screens (ANA-01). [TBC: confirm]. Free-tier venues show "Powered by" branding; that is a link, not tracking.
13. Special notice: clinics and sensitive venues
Visits to a clinic or dentist can reveal health information. The clinic template is designed to collect no medical fields, use neutral alert wording and show ticket numbers instead of names (VEN-04). Please do not enter health details in any field. Messages on shared phones can still reveal a visit (accepted residual risk R-04 in the threat model). Per decision 10, clinics are not onboarded beyond one privacy-test pilot venue until a lawyer has reviewed this policy. [TBC: lawyer; rules on sensitive data and professional secrecy for health providers]
14. Requests from authorities
[TBC: lawyer to define.] Working intent: respond only to lawful requests from competent authorities, review each for legality and scope, disclose the minimum, and notify the affected venue or person where the law allows. Minimal data and short retention limit what could be disclosed (threat model R-09).
15. Contact
- Privacy contact: [TBC: email, address, phone]
- Representative / data protection officer, if any: [TBC]
- Complaints: [TBC]
- Brand and domain: [from brand configuration, ADR 0008]
16. Changes to this policy
We will publish the updated policy with a new version and date. For material changes affecting venue users we will require re-acceptance (TEN-09). For queue customers we show a link to the current version at join and, where a change affects consent, ask again. [TBC: notice period, language versions]
17. Pilot period note
During the pilot (R1a) venues sign a short pilot agreement and the full policy is not yet published. This draft is the intended base for the full policy before public launch (R1b). Clinic onboarding waits for lawyer review (decision 10).