Data Processing Agreement
This agreement governs how Weird Network processes personal data on behalf of a venue operator (the "controller"). It is separate from our Terms of Service, which any visitor to the site accepts, and from our Privacy Policy, which describes how we handle our own data. This agreement is signed by the venue operator at signup and stored as a record on the operator's account.
This Data Processing Agreement applies when a venue operator ("you" or "the controller") signs up to use Weird Network. It describes how Weird Network ("we", "us", or "the processor") handles guest personal information on your behalf when guests authenticate through your captive portal. If you are a guest who connected to WiFi at a venue that uses Weird Network and you want your data changed or deleted, contact the venue directly — they hold it.
1. Definitions and roles
For the purposes of this Agreement:
- "Controller" — the venue operator. You decide what personal data you collect, why, and how long you keep it. You are the lawful owner of the relationship with your end users.
- "Processor" — Weird Network. We process guest data on the controller's instructions, solely to operate the captive-portal SaaS you signed up for. We do not decide what to collect and we do not use the data for our own purposes.
- "Sub-processor" — a third party we engage to help process the data (e.g. an email-delivery vendor). The full list is in Section 6.
- "Personal data", "processing", "data subject" — have the meanings given in applicable data-protection law (GDPR Art. 4, CCPA §1798.140, and equivalents).
The parties acknowledge that the controller determines the purposes and means of processing; the processor processes only on documented instructions from the controller, this Agreement being the controller's standing instruction.
2. Subject matter
The subject matter of this processing is the operation of a branded guest-WiFi captive-portal software service on behalf of the venue operator. Specifically, that means running the software that:
- Presents the venue's branded splash page to guests on the WiFi network.
- Collects the fields the venue has configured (typically: name, email, phone, MAC address).
- Routes the guest through to the venue's internet access for a session whose duration is bounded by the configuration the venue has chosen.
- Captures session metadata needed to operate the service (start/end, byte counts, status).
This Agreement does not cover any data the venue operator processes outside of the Weird Network software (e.g. a separate booking platform, a POS system, a guest WiFi network operated by someone else).
3. Duration
This Agreement is effective from the date the venue accepts it during signup (or later, by re-signing in the provider dashboard) and remains in force for the term of the underlying service agreement between the venue and Weird Network.
The following obligations survive termination and continue for as long as the relevant data is retained:
- Confidentiality obligations under Section 7 (Security Commitments).
- Data-return and deletion obligations under Section 9.
- Breach-notification obligations under Section 8 for incidents that occurred during the term.
- Audit obligations under applicable data-protection law for the period required by such law.
4. Nature and purpose of processing
The processing is necessary to provide the captive-portal SaaS. It consists of:
- Routing guest auth requests — delivering the splash page to the guest's device, accepting their submitted fields, deciding whether to grant a session.
- Forwarding submitted PII to the venue's email — per the venue's forwarding configuration (see our Data Retention page), the guest's submitted fields are emailed to the venue; we do not retain them server-side beyond the request.
- Retaining session telemetry — MAC address, session start/end timestamps, byte counts, status, the configured session duration, and any metadata the controller has attached to the venue record.
- Risk-scored aggregates — counters and de-identified aggregates the dashboard uses to flag anomalies (peak hour, repeat MACs, unusual traffic spikes). Aggregates are not personal data because they cannot be tied back to a single guest.
The processor does not enrich the data, does not combine it with any other dataset, and does not transfer it to any party not listed in Section 6.
5. Categories of personal data and data subjects
The categories of data subjects processed under this Agreement are:
End users (guests on the controller's WiFi)
- Identifying fields the venue collects (name, email, phone) — only if the venue's splash page captures them.
- MAC addresses — every authenticated device.
- IP addresses — short-lived in our logs; not retained at the row level beyond a session hash.
- Captured user-agent strings — used only to detect device class for the analytics breakdown.
Venue staff
- Email address, name, optional phone, role, and venue binding — for sub-users the controller invites via the dashboard.
Venue operator (the signer)
- Email, password (hashed), business name, location, payment destination (PayPal email) — standard account data, processed to operate the service.
No special-category data (GDPR Art. 9) is processed unless the controller has separately configured it on their splash page; if so, the controller bears the legal basis for collecting it.
6. Sub-processors
The controller authorises the processor to engage the following sub-processors. Each is limited to the minimum data needed for its function. The processor will give the controller at least 30 days' notice of any new sub-processor via the venues inbox, after which the controller may object.
| Sub-processor | Location | Purpose / data received | Policy |
|---|---|---|---|
| Stripe | United States | Payment processing for subscriptions — payment instrument, email, plan. | stripe.com/privacy |
| Transactional email vendor (Postmark, via Polsia email proxy) | United States | Notification emails the controller asks us to send (magic links, password resets, alerts, digests). | postmarkapp.com/privacy |
| Neon | United States / EU regions available | Hosts the PostgreSQL database; infrastructure-level access only. | neon.tech/privacy |
| Render | United States / EU regions available | Hosts the application process; infrastructure-level access only. | render.com/privacy |
| Cloudflare R2 | United States / EU regions available | Optional file storage for screenshots the controller chooses to upload. | cloudflare.com/privacy |
The list above mirrors the third-party processors listed in our Privacy Policy. If a controller requires processing in a specific region (e.g. EU-only), they may request a region-pinned deployment; the processor will assess feasibility and respond within 30 days.
7. Security commitments
The processor commits to the following technical and organisational measures to protect personal data:
- Transport encryption. All client-facing endpoints are served over TLS; the firmware configuration endpoint enforces TLS on the router side.
- Hashed session tokens. Provider session cookies are opaque to the browser; the corresponding row in
provider_sessionsstores only a SHA-256 hash of the token. A database disclosure does not yield usable sessions. - Encrypted-at-rest infrastructure. The underlying database host (Neon) provides encryption at rest; storage volumes are encrypted at the block level.
- Access logging. Authentication events and admin actions write to an audit log. Application-level access to personal data is minimised and reviewed on a quarterly basis.
- Password hashing with scrypt. Provider passwords are stored using scrypt with strong parameters; no plaintext or reversible storage exists.
- No production data in development. Engineers do not have access to production database rows containing personal data for routine development. Production debugging is performed via aggregated or de-identified snapshots.
- Personnel security. Engineer and personnel onboarding includes confidentiality obligations that survive termination. The processor commits to background-checking personnel with access to production data.
The controller may request a copy of our current security overview via the contact channel below. Where the controller's own security obligations require an audit (e.g. SOC 2, ISO 27001), the processor will cooperate within commercially reasonable limits; until formal certification exists, the processor provides a written summary on request.
8. Breach notification
In the event of a personal-data breach (as defined in GDPR Art. 4(12) or its equivalent in other applicable law), the processor will:
- Notify the affected controller(s) without undue delay, and in any case within 72 hours of becoming aware of the breach.
- Deliver the notification to weird-network@polsia.app, which is monitored continuously and is the same address listed in our Privacy Policy.
- The notification will include, to the extent then known: the nature of the breach, the categories of data and approximate number of data subjects affected, the likely consequences, and the measures taken or proposed to address it.
- The processor will provide reasonable cooperation to support the controller's own notification obligations to supervisory authorities and data subjects.
The processor is not required to notify the controller of incidents that demonstrably do not affect personal data processed on the controller's behalf (e.g. availability incidents on a static asset host).
9. Termination and data return
On termination of the underlying service agreement, the controller may export all retained session metadata (MAC, start/end, byte counts, status) for a period of 30 days. After that:
- Session-level rows are deleted.
- Aggregated, de-identified analytics (counters, peak-hour rollups) may be retained since they cannot be tied back to a single data subject.
- Email-forwarding transcript copies held in the controller's mail provider remain the controller's responsibility; the processor does not retain them.
- Account-level data (controller's name, email, hashed password) is deleted per the controller's deletion request, unless retention is required by applicable law (e.g. tax records).
The processor will execute the deletion within the 30-day window unless the controller requests an earlier cutoff. After deletion, the processor will provide written confirmation on request.
10. End-user rights — venue obligation
The controller is responsible for honouring end-user rights under applicable data-protection law — access, correction, deletion, portability, and objection. This is consistent with our Privacy Policy section "Your rights": the venue holds the data and must respond.
The processor supports the controller in meeting these obligations by providing, on request:
- Export tooling — a JSON export of session-level rows tied to a given MAC or to the controller's whole venue.
- Deletion tooling — a one-click row-level delete for any session row, plus a venue-scoped delete for the controller's full data set.
- Audit evidence — a copy of the controller's signing record for the DPA itself, plus a list of any sub-processor changes during the controller's term.
The processor will action a controller's request within 30 days. Where the controller forwards a data-subject request directly to the processor, the processor will redirect the request to the controller within 5 business days.
11. Governing law and order of precedence
This Agreement is governed by the laws of the State of Wyoming, without regard to conflict-of-laws principles, unless mandatory local law (e.g. GDPR for EU data subjects, CCPA for California residents) provides otherwise for a particular data subject's data.
In the event of any conflict between this Agreement, our Terms of Service, and our Privacy Policy, the following order of precedence applies with respect to the controller's processing of personal data:
- First: this Data Processing Agreement.
- Second: the Privacy Policy, where this Agreement does not speak to a matter.
- Third: the Terms of Service, for anything outside the scope of personal data.
Where a provision of this Agreement is found to be unenforceable in a given jurisdiction, that provision will be severed only to the minimum extent necessary; the remainder of the Agreement remains in effect.
12. Acceptance
Acceptance of this Agreement happens at venue signup. After creating an account, the venue operator reviews the full text of this Agreement (this page) and clicks an in-app Confirm button. The processor records the timestamp, the version of the Agreement accepted (here, v1.0), and the IP address from which acceptance was submitted. A copy of the signing record is available from the provider dashboard on request.
If a future version of this Agreement changes the controller's obligations materially, existing controllers will be asked to re-sign before any feature that depends on the Agreement becomes available. Continued use of the service after the new effective date constitutes acceptance of the updated Agreement by operation of the re-sign flow.
Questions about this Agreement: weird-network@polsia.app.
You will be asked to accept this Agreement as part of the signup flow at /provider/signup — right after creating your account and before your first router can be paired. The dashboard and the router-pairing endpoints will gate-pairing until the acceptance record is in place.