Raxx · internal docs

internal · gated

Waitlist Privacy Notice — Raxx

Status: DRAFT — pending attorney sign-off. This document is NOT legally operative. This document does NOT constitute legal or tax advice. Before publishing, consult a privacy attorney familiar with CAN-SPAM, GDPR Article 13, CASL, and CCPA/CPRA. The notice must be live at /marketing/privacy before this form is wired to a real endpoint (dependency per issue #589). Last updated: 2026-05-14 UTC. Legal entity: MooseQuest LLC, doing business as Raxx.

Purpose of This Document

This document covers two distinct deliverables:

  1. The in-form privacy notice — the short disclosure that appears at the point of email collection on the waitlist signup form. This text goes directly into the WaitlistSection.js component.

  2. The waitlist-specific section for the main Privacy Policy — the text that lives in privacy-policy-draft-2026-05-14.md Section 2.1 under "Waitlist email." Cross-reference that document; the categories are already included.

  3. Recommended UX placement and acceptance flow — where each element lives in the UI.

  4. Open questions requiring attorney sign-off before the endpoint goes live.

Part 1: In-Form Privacy Notice Copy

The notice should appear below the email input field and above the submit button, as inline text — not hidden behind a "more info" link. The privacy policy link must be functional (not a hash stub) before this form is wired to a live endpoint.

1.2 Copy — Standard Version (US Users)

By joining, you'll receive product updates and launch news from Raxx.
We won't share your email. You can unsubscribe at any time.
See our Privacy Policy.

Where "Privacy Policy" links to /marketing/privacy.

1.3 Copy — Extended Version (for GDPR/EEA Users or Global-Default)

If Raxx cannot geo-gate the form to US-only visitors (or chooses a single global notice for simplicity), use this fuller version to satisfy GDPR Article 13 at the point of collection:

By joining the Raxx waitlist, you agree to receive updates about Raxx product
availability and launch announcements. We will store your email address for this
purpose and delete it if you unsubscribe or request deletion. We will not share
your email with third parties for marketing purposes.

Legal basis for processing (GDPR): consent (Article 6(1)(a)).
Controller: MooseQuest LLC dba Raxx — support@raxx.app

For full details on your rights (including the right to access, correct, delete,
or object), see our Privacy Policy.

Where "Privacy Policy" links to /marketing/privacy.

1.4 Checkbox vs. Inline Notice — Recommendation

Recommendation: explicit opt-in checkbox for the waitlist form.

Recommended checkbox copy:

[ ] Yes, notify me when Raxx launches. I agree to receive product updates and launch
    news. I can unsubscribe at any time. See Privacy Policy.

The checkbox must be unchecked by default. "See Privacy Policy" links to /marketing/privacy.

UX placement:

[Email address field]

[ ] Yes, notify me when Raxx launches. I agree to receive product updates and launch
    news. I can unsubscribe at any time. See Privacy Policy.

[Join Waitlist button — disabled until checkbox is checked]

Disabling the submit button until the checkbox is checked is an acceptable UX pattern and provides a clean implementation-level record that consent was explicitly given.

Part 2: Success State and Confirmation

2.1 Post-Submission Success Message

After successful form submission, replace the form with:

You are on the list. We will be in touch when Raxx launches.

(This is the copy specified in issue #589's acceptance criteria.)

Do not add marketing copy to the success state. Keep it confirmatory only — any promotional copy in the post-submission state may undermine the transactional/consent classification of the collection.

2.2 Confirmation Email (Phase 2 — Not for v1)

A confirmation email to the waitlist subscriber is out of scope for v1 per issue #589. Phase 2 planning note: when a confirmation email is added, it must satisfy:

Attorney must review the confirmation email template before it ships.

Part 3: Unsubscribe and Data Deletion Flow

3.1 Unsubscribe Mechanism

Every marketing email sent to waitlist subscribers must include a functioning unsubscribe link or mechanism. Under CAN-SPAM, unsubscribe requests must be honored within 10 business days. Under CASL, within 10 business days. Under GDPR, without undue delay.

For the v1 waitlist (no emails sent at signup, per issue #589), the unsubscribe mechanism becomes relevant when launch-announcement emails are sent. At that time, the mechanism must be in place before send.

Implementation note: the waitlist_entries table (in Postgres per issue #589 grooming update 2026-05-11) should include an unsubscribed_at timestamp column and an unsubscribe_token column from day one, even if unsubscribe emails are not sent at v1. This avoids a schema migration when emails do go out.

3.2 Data Deletion Request

A user may request deletion of their waitlist entry by emailing support@raxx.app. Per the Privacy Policy, we will process verified deletion requests within 30 days.

Part 4: IP Hash and Rate-Limiting — Privacy Notice Implication

Per issue #589, the POST /api/waitlist/subscribe endpoint stores a salted SHA-256 hash of the submitting IP address for rate-limiting and abuse-prevention purposes. This constitutes collection of technical data derived from personal data (IP address).

The main Privacy Policy (Section 2.1, "Technical and device data") already covers IP address collection for security and rate-limiting purposes with a 90-day retention period. The waitlist form need not separately disclose the IP hash, provided the main Privacy Policy is linked from the form notice and is accurate.

Implementation requirement for issue #589: The IP address must be salted before hashing. Storing an unsalted SHA-256 of a raw IP address from a known IP range is effectively reversible. The salt must be stored as a server-side secret (not in the database alongside the hash).

Part 5: Quebec Geo-Block Interaction

Per project_quebec_geoblock_decision.md and the grooming update in issue #589 (2026-05-11), the POST /api/waitlist/subscribe endpoint must apply the Quebec jurisdiction check before writing to the store.

The waitlist form should display the geographic restriction notice consistent with the ToS Section 4.2. No special additional language is required in the form privacy notice — users from blocked jurisdictions will not reach the form submission endpoint.

If the geo-block relies on IP-based jurisdiction detection, the detection must occur before any personal data (including the IP address itself) is stored for the blocked user.

Open Questions for Attorney Sign-Off

Attorney type for these questions: privacy attorney familiar with CAN-SPAM, GDPR, CASL, and CCPA. Bring the waitlist form wireframe and the POST /api/waitlist/subscribe endpoint data-flow diagram to the review.

OQ-WL-1 (CASL — express consent record-keeping): For Canadian waitlist subscribers, CASL requires that express consent be documented. The waitlist_entries table stores email, timestamp, IP hash. Attorney should confirm whether storing the timestamp and IP hash constitutes sufficient consent documentation under CASL s. 13, or whether additional fields are required (e.g., the consent form version/text displayed at time of signup). Source: https://crtc.gc.ca/eng/com500/faq500.htm

OQ-WL-2 (GDPR — consent documentation): For EEA waitlist subscribers, GDPR Article 7(1) requires that the controller be able to demonstrate that consent was given. The database stores email and submission timestamp. Attorney should confirm whether storing the consent form version/text displayed at signup (as a separate field or audit log) is required to satisfy Art. 7(1) in a regulatory inquiry. Source: https://gdpr-info.eu/art-7-gdpr/

OQ-WL-3 (CAN-SPAM — is the waitlist form a commercial solicitation?): The waitlist form collects email for the purpose of sending "launch announcements." Under 15 U.S.C. § 7702(2)(A), a message is a "commercial electronic mail message" if its primary purpose is "commercial advertisement or promotion of a commercial product or service." A launch announcement for a paid SaaS product may qualify as a commercial electronic mail message, triggering CAN-SPAM's opt-out, physical address, and subject-line requirements. Attorney should confirm the correct classification and whether the opt-in checkbox is sufficient, or whether a double opt-in workflow is required. Source: https://www.law.cornell.edu/uscode/text/15/7702

OQ-WL-4 (CCPA — waitlist data at 100K record threshold): Each waitlist email submission from a California resident counts toward the CCPA 100,000 consumer record threshold. At v1 launch volume, this is unlikely to be a concern. Attorney should advise on the trigger level at which a waitlist-to-subscriber pipeline would require a formal CCPA "Right to Know" and "Do Not Sell" disclosure flow, and whether a pre-emptive disclosure (linking the Privacy Policy) from day one is the appropriate risk mitigation. Source: https://oag.ca.gov/privacy/ccpa

OQ-WL-5 (No marketing without separate consent — scope confirmation): Issue #589 states: "Does NOT send any email on submit." Phase 2 will add launch announcement emails. Attorney should confirm that the opt-in checkbox consent captured at v1 signup is legally sufficient to send launch-announcement emails at a later (undefined) date, or whether re-consent is required if the time gap between signup and first email is long (e.g., >12 months). GDPR's purpose-limitation principle and CASL's implied-consent decay rules may require re-consent after a period of inactivity.

Sources