Privacy at qub

Effective date: 1 May 2026 Version: 1.0 — initial publication

In short: We encrypt your content on your device. We don't read it, we don't store plaintext, we don't sell data, and we don't train AI on it. Your email and handle are used only for the features you turn on. Sealed content is stored permanently and cannot be deleted — once it's there, even we can't remove it. Read §5 carefully before sealing.

Who We Are

qub.social is operated by VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. References to "qub", "we", "us", and "our" mean that entity, which acts as the data controller (GDPR / UK GDPR), the APP entity (Privacy Act 1988 (Cth)), and the "business" (CCPA / CPRA) for personal information processed through the Service.

Privacy contact: Mark Harper — support@qub.social with the subject prefix [PRIVACY].

1. What qub Is

qub is a timed commitment and publication platform. You write a qub, choose a future reveal date, and your browser locks it using a public time-release service so it cannot be opened until that date arrives. The sealed copy is stored in a decentralised permanent storage layer we do not run. After the reveal date, anyone with the link can decrypt and read the content.

The platform is built so that we are not in the trust chain. Locking and unlocking happens on your device. By the time a qub reaches us it is already a sealed package, and the small piece of the link needed to open it stays in your browser by design — subject to the cryptographic assumptions disclosed in our Terms of Use §13.3, and to the narrow recovery-channel opt-in described in §2.3 below. As more of the internet becomes machine-generated, being able to point at a sealed message and prove "this existed at that exact moment" matters more, not less — and that proof works even if our servers are offline, even if we cease to exist.

This privacy policy explains what data we collect, what we do not collect, and the privacy implications of using permanent public storage.

2. Data We Collect

2.1 Content You Seal

When you seal a qub, your content is encrypted on your device before it leaves your browser. Our servers do not receive your plaintext content during sealing. The encrypted payload is written to permanent storage, not to servers we control. The only narrow exception is the explicit recovery-channel opt-in described later in this section, where the per-qub wrapper key is sent to our server alongside the encrypted upload so we can include a working delivery link in your seal-confirmation email; even then, your plaintext content does not reach our servers.

After the reveal date, the content becomes publicly decryptable by anyone who has the storage transaction ID (which is embedded in the qub link you share).

2.2 Device Identifier

On first use, qub generates a random device identifier and stores it in your browser's local storage (IndexedDB). This identifier is used to track your free-tier usage quota and to link paid entitlements to your device. It is not derived from hardware fingerprinting or cross-site tracking.

The device identifier may be lost if you clear browser data, switch devices, or use private browsing. It is not a persistent identity — it is a convenience binding.

2.3 Email Address

We collect your email address only when you use a feature that requires it. Each use is limited to the stated purpose. We do not send marketing emails and do not build profiles from email addresses.

We share email addresses only with Stripe (for purchases) and our transactional email provider (for every other email listed above — see §8 for the current provider). Neither party receives addresses collected by the other.

All emails listed above are transactional or service-related communications sent in response to a specific user action. They are not commercial electronic messages within the meaning of the Spam Act 2003 (Cth), and they are not commercial messages under the US CAN-SPAM Act. We do not send marketing emails, and there is therefore no marketing list to unsubscribe from. Each email type can be disabled at its source: magic-link by not requesting sign-in; notify-me via the unsubscribe link in the notification email; lifecycle / seal-confirmation emails by not opting in at seal time.

When you complete magic-link sign-in for the first time, qub also auto-allocates a public handle on your identity record. The handle is a separate identifier from your email — it is publicly visible and reverse-lookupable, but does not expose the email address it is linked to. See §2.12.

Recovery URLs and lifecycle email opt-in. Each sealed qub is locked with a per-qub key that lives in the part of the share link after the # symbol (https://qub.social/c/<id>#<key>). Browsers don't transmit that part to any server, so by default we never see the key — which means we can't recover your qub if you lose the link.

You can opt into a recovery channel: when you turn on creator lifecycle emails for a specific qub and the email you supply matches your verified identity, we accept the key with the upload, store the full delivery link on your identity's sealed-history record, and put it in your seal-confirmation email so the URL in your inbox actually opens the qub. This is a trade-off — a backup channel in exchange for some end-to-end purity — and it engages only when you opt in, only for the qub you opted in for. Without opt-in (or with an email we can't verify), the key stays in your browser and never reaches our servers.

2.4 Signing Keys

If you generate a signing key, the key pair is created and stored entirely on your device. Only your public key is transmitted to our server — when you sign a qub or verify your identity via email attestation. Your private key never leaves your browser. Public keys and attestation records are stored in our metadata store.

2.5 Payment Information

Payments are processed entirely by Stripe. We do not receive or store your credit card number, expiry date, or CVC. Stripe may collect additional information during checkout, including your name, billing address, and device information, for the purposes of fraud prevention and payment processing. Stripe's privacy policy governs the handling of your payment details: https://stripe.com/privacy

Stripe may begin collecting information (such as data entered into the checkout form) before you complete a purchase. This is standard Stripe behaviour for fraud prevention and is governed by Stripe's privacy policy, not ours.

2.6 Telemetry

qub collects minimal, anonymous product telemetry to understand how the product is used and to diagnose errors. Telemetry events include actions such as "seal completed", "viewer loaded", and "decryption succeeded", along with timing data.

What telemetry does not include:

• Your device identifier
• Your IP address — qub does not log client IP addresses against telemetry events at the application layer; transient request-metadata logging by our infrastructure provider (see §2.9) is governed by their privacy policy and is not joined to telemetry
• Your content or any preview of your content
• Any information that identifies you personally

Because telemetry events contain no information that identifies you and no information we could combine with other data we hold to identify you, we treat them as anonymous information that falls outside the scope of "personal data" under GDPR Art. 4(1) and Recital 26 (and the equivalent definitions under the Privacy Act 1988 (Cth) and CCPA / CPRA). The data protection regime — including the right to object under GDPR Art. 21 — does not apply to anonymous information, and we do not offer a separate opt-out for telemetry.

If a regulator with jurisdiction over you takes a different view of this classification, we will treat the telemetry as personal data on a legitimate-interest basis under GDPR Art. 6(1)(f) for the operational purposes described above. The applicable lawful basis would then sit alongside §4; your other rights are unaffected by the classification choice.

Telemetry events are buffered in memory and flushed periodically. If a flush fails, events are discarded — telemetry never retries or persists to local storage. Telemetry must never interfere with the product experience.

The qub embed iframe fires the same kind of anonymous events back to qub.social — viewer_arrival when the embed loads, and share_clicked when a viewer taps the embed's footer CTA. These events have the same shape as the in-app telemetry above: no IP, no device identifier, no content preview, and no third-party tracker is involved.

2.7 Bot Detection

qub uses a privacy-preserving CAPTCHA alternative to prevent automated abuse of the seal flow. The challenge does not use cookies for tracking and does not fingerprint your device for advertising purposes. The upstream provider and its privacy policy are listed in §8.

2.8 Abuse Reports

If you report a qub, we collect the report reason and optional explanatory text you provide. We store a one-way hash of your IP address with the report — not your IP address in the clear. This hash is used only for rate-limiting report abuse.

2.9 Server Logs

Our infrastructure provider (Cloudflare) may log request metadata (IP addresses, request paths, timestamps) as part of standard service operation. These logs are governed by Cloudflare's privacy policy and are subject to their retention periods, which are typically short — on the order of days to weeks. We do not export or archive Cloudflare's full traffic logs, and we do not enrich them with any other data we hold. The narrow set of network-derived signals we do persist for sanctions and abuse triage is described separately in §2.13.

2.10 Embedded qubs

Publishers may embed sealed qubs on third-party pages (blogs, Notion pages, Substack posts, and so on) using the qub embed snippet. The embed renders inside an iframe that is loaded same-origin from qub.social, so it uses the same encryption, the same storage and drand fetches, and the same anonymous telemetry described above. The host page cannot read the embed iframe's DOM — browser sandbox isolation enforces this — and the embed introduces no new collection or third-party processor.

2.11 Reply-Chain Metadata

When you author a reply qub from another qub's reveal page, the parent qub's storage transaction ID is attached to the new qub's upload as a public tag (Parent-Tx-Id). This tag is what allows the reveal page to render a "Replied to {parent}" back-link without requiring qub-controlled servers to maintain a reverse index. The tag is a public storage property and is permanent for the same reasons §3 and §5 describe. The parent's qub_id (which is the cryptographic identifier the encrypted envelope binds to) is a separate field that lives inside the encrypted envelope and only becomes visible after the reply qub itself unlocks.

You can author a reply qub without ever using qub's reply UI — but if you arrive at the compose screen via the "Seal a reply →" CTA on a reveal page, the parent reference is set automatically. The reply context can be cleared from the compose screen with one tap before sealing.

2.11a Public Attribution (Author Tag) — Opt-In

When you seal a qub, the upload includes an optional Author storage tag that carries your signing-key fingerprint. The reference creator app attaches this tag only when you explicitly enable "Public attribution" on the date-picker step at seal time. When you leave the toggle off, the upload omits your fingerprint, no Author tag is written, and the qub is unattributed in permanent storage.

When you do enable public attribution, the fingerprint resolves to your verified @handle (and any associated public profile fields under §2.12) at viewer-render time. Attribution is decided per qub — you may attribute some of your qubs and not others, and the choice is recorded permanently along with the qub itself.

The plaintext title field on a sealed qub (the optional one-line label you can set on the date-picker step, defaulting to the intent label) is not identity metadata, but it is plaintext on the stored artefact and visible on the viewer countdown before reveal. Treat it accordingly — pick a title you are comfortable being permanent and public.

2.12 Personal Handles and Public Profile Pages

When you complete magic-link sign-in, qub auto-allocates a personal handle on your identity record in the form @adjective_noun_NNN (e.g. @orange_fox_612). The handle is the default public byline shown on qubs you have explicitly chosen to publicly attribute (§2.11a), replacing the raw cryptographic fingerprint with a human-friendly label. The handle is publicly visible and reverse-lookupable via GET /api/v1/handle/{handle}, which returns the owning public-key fingerprint (60-second edge cache). The reverse lookup does not return the email address linked to that identity — a viewer who follows the handle does not learn your email. The reverse-lookup endpoint is unauthenticated and rate-limited at the edge; this is intentional (it is the public-facing identity-verification surface), but it does mean any party who knows your handle can confirm the underlying public-key fingerprint.

You may rename the handle at any time from /signature. The rename request is authenticated by a cryptographic signature from your private key (using the ML-DSA-65 post-quantum signature scheme), capped at one rename every 30 days. Renaming releases the prior handle back to the namespace pool subject to standard reservation rules.

Every claimed handle has a public profile page at /u/{handle} (and /@{handle}, which 302-redirects to the same page). The profile is a pure verified-identity card — it shows:

• Your handle.
• An optional display name and an optional profile URL that you supply yourself. Both fields are blank until you set them and publicly visible once you do. Setting them is authenticated by a separate signed request with replay protection. The display name is normalised to NFC, capped at 50 code points, and stripped of control characters; the URL must be http:// or https:// and is capped at 512 characters.
• A "verified email" pill when an email attestation is on the record. The email address itself is never displayed — only a boolean badge confirming an attestation exists.
• The short cryptographic fingerprint (qub:abcd…1234) as the protocol-level identity anchor.

The profile is intentionally an identity card. It does not list the qubs you have authored. Public attribution is opt-in per qub (§2.11a) — only the qubs you explicitly chose to attribute carry your fingerprint in permanent storage at all, and the profile page does not enumerate them. To direct visitors to a specific qub, share the qub's delivery URL (the link you receive at seal time).

When a search-engine crawler or social-media unfurler fetches a profile page, qub renders a small server-side response containing the page title and a JSON-LD Person schema. Browsers fall through to the same single-page-app shell as the rest of the viewer. The bot-side response carries no information that is not already public on the page itself.

Clearing your display name or profile URL removes those fields from the next render of your profile. Qubs you have publicly attributed cannot be deleted from permanent storage — on request we will denylist a qub, which removes it from qub's viewer; the underlying stored data remains as described in §5.

2.13 Network Signals for Sanctions and Abuse Triage

For meaningful authenticated or account-affecting actions (sign-in, API key creation and use, sealing, account-management requests), we may capture and persist a small set of network-derived signals exposed to our backend by Cloudflare: the approximate country of the request, the network operator (ASN), the Cloudflare request identifier (CF-Ray), and a salted one-way hash of the request IP and user-agent string. We do not persist the raw IP address on a user record or in our application-side event log.

These signals are used under our Sanctions & Restricted Use Policy for risk management, abuse prevention, and to enable us to respond to enquiries about restricted access. IP-derived country is approximate and is not treated as conclusive identity evidence.

The latest values are stored on your identity record for quick triage; an append-only event record is also written to our internal logs each time a meaningful action is observed, and that event log — not the user record — is the authoritative evidence layer if we ever need to explain a decision. Internal documentation describing exactly which fields we keep, where they are stored, and the retention period lives at docs/sanctions-geo-triage.md in our open-source repository.

3. Data We Do Not Collect

• We do not read, scan, or moderate your content before it is sealed; encryption happens on your device. The narrow recovery-channel opt-in described in §2.3 is the only path on which the per-qub wrapper key reaches our servers, and even then your plaintext content does not.
• We do not use advertising trackers, analytics pixels, or third-party marketing scripts.
• We do not sell, rent, or trade any data to third parties. Under the California Consumer Privacy Act (CCPA), we do not "sell" or "share" your personal information for cross-context behavioural advertising.
• We do not use your data to train machine learning models.
• We do not build user profiles or behavioural graphs.

4. Lawful Basis for Processing

Where data protection law requires a lawful basis for processing personal data, ours are as follows:

Telemetry events (§2.6) are anonymous and therefore are not personal data within the meaning of GDPR Art. 4(1) — no lawful basis is required and they do not appear in this table.

5. Permanent Storage — Important Disclosure

This is the most important section of this policy. Please read it carefully.

A pact permanently publishes both parties' email addresses. When a pact is co-signed and sealed, both parties' names and the email addresses each provided are written into the encrypted body. After the reveal date, that body is publicly decryptable and the addresses become permanent and public. Do not stage a pact against an email address whose owner has not explicitly agreed to that publication. This is irreversible.

qub stores sealed content in permanent, tamper-proof public storage. That storage is designed to be permanent and immutable. Once your content is written to permanent storage, it cannot be deleted, modified, or recalled — by you, by us, or by anyone.

What this means in practice:

• Before the reveal date: Your content is encrypted and unreadable (subject to the cryptographic assumptions disclosed in Terms of Use §13.3).
• After the reveal date: Your content becomes publicly decryptable. Anyone with the storage transaction ID (contained in the qub link) can decrypt and read it.
• If you change your mind: We cannot delete or alter content held in permanent storage. We can add the qub to a denylist so that qub's viewer refuses to display it, but the underlying data remains in permanent storage and may be accessible through other means.

The denylist model provides practical removal from qub's product surface. It does not provide deletion from the internet.

You should only seal content that you are comfortable being permanently and publicly available after the reveal date. Consider carefully before sealing content that includes personal information about yourself or others.

Pacts (technical detail). A pact body records both parties' names and contact details (including email addresses) inside the signed CBOR body. Once both parties co-sign and the sealed pact is written to permanent storage, those identifiers become part of the permanent record and are publicly decryptable after the reveal date. See the bolded warning at the top of this section.

Public profile pages. The profile page at /u/{handle} is the verified-identity card described in §2.12 — handle, optional display name, optional URL, "verified email" pill, fingerprint short form. It does not list the qubs you have authored. Renaming your handle replaces the public binding immediately. Qubs you publicly attributed under a prior handle continue to be attributable to the same public-key fingerprint, which now resolves to the new handle through the attestation chain.

5.1 Third Parties in Your Content

When you include another person's personal information in a sealed qub or pact (for example, by naming them, including their email address as a pact counter-party, or quoting their correspondence), you are responsible for ensuring you have the lawful basis to do so under the law of your jurisdiction. We process that information solely on your instructions, in our capacity as a service provider to you. We do not have a direct relationship with the third party and we rely on you to provide them with any notice their applicable privacy law requires. This responsibility is reinforced in our Terms of Use §15 (indemnification) and User-Generated Content Policy.

6. Your Rights and Choices

6.1 Access and Portability

Your sealed qubs are stored in permanent public storage. You already have direct access to them via the transaction IDs in your qub links. No data-access request to us is needed.

6.2 Deletion and Erasure

Permanent storage is permanent, so we cannot delete sealed content. If you ask us to erase a qub, we'll review the request under the procedure in our User-Generated Content Policy §6. If we grant it, we add the qub to our denylist — qub's viewer and cache stop serving it. The underlying data in permanent storage stays put; this is the most our architecture allows.

For data we hold directly (email address, device identifier, entitlement records, identity and attestation records, personal handle, profile display name and URL), you may request deletion by emailing support@qub.social with the subject prefix [PRIVACY]. We'll action these requests within statutory timeframes — usually within 30 days, with extensions where the request is complex or numerous, as permitted by applicable law (GDPR Art. 12(3); APP 12.4; CCPA §1798.130(a)(2)).

6.3 Correction

If any information we hold about you is incorrect (for example, the email associated with your purchase), contact us and we will correct it.

6.4 Objection to Processing

You may object to our legitimate-interest processing under GDPR Art. 21(1). The processings carried out on this basis are listed in §4 and are limited to (a) the device-identifier binding that backs your free-tier quota and paid entitlement, (b) the one-way IP hash attached to abuse reports, and (c) bot-detection signals on the seal flow. Each is necessary either to deliver the Service to you or to protect the integrity of the platform for other users. On a substantively complete objection, we will assess it on the merits and either cease the processing or, where Art. 21(1) permits, demonstrate the compelling legitimate grounds that override your interests, or rely on the Art. 21(1) carve-out for processing necessary for the establishment, exercise or defence of legal claims. To object, email support@qub.social with the subject prefix [PRIVACY].

Telemetry (§2.6) is not subject to this right because it is not personal data — see the explanation at the end of §2.6.

7. Cookies and Local Storage

7.1 Cookies Set by qub

qub sets no cookies — not for tracking, not for advertising, not for session management, not for any other purpose. We do not emit Set-Cookie headers from our application. Authentication uses HMAC-signed magic-link tokens delivered to your email and consumed once; telemetry uses anonymous beacons; entitlement binding uses a device identifier in browser local storage (§7.3). None of these mechanisms require a cookie. Because qub sets no cookies of its own, we display no cookie consent banner.

7.2 Cookies Set by Third-Party Infrastructure

Two infrastructure providers we depend on may interact with your browser's cookie store as part of the normal operation of their services. We do not control these cookies and gain no tracking capability from them:

• Cloudflare, our CDN and edge runtime (§8), may set short-lived strictly-necessary cookies on the qub.social domain (for example __cf_bm) for bot management and rate-limit enforcement. These cookies are not used for cross-site tracking or behavioural advertising. Cloudflare's privacy policy and the Turnstile addendum govern them.
• Stripe runs the payment checkout flow inside an iframe loaded from checkout.stripe.com. Cookies set there belong to Stripe's own domain, are governed by Stripe's privacy policy, and are not readable by qub. They exist only when you visit the checkout flow.

We use no third-party advertising or analytics cookies. There are no Google Analytics tags, no Meta pixels, and no advertising SDKs anywhere on qub.social.

7.3 Local Storage (IndexedDB)

qub uses browser local storage (IndexedDB) to store:

• Your device identifier (for entitlement binding).
• Draft content (saved locally on your device, never transmitted unless you seal it).
• A local cache of your linked identity record and sealed-history index, so a returning device renders without a server round-trip.
• Per-tx_id markers (for example "you have already viewed this qub", "you have already reacted") used by the viewer to suppress duplicate counter increments.
• Application state.

This data stays on your device and is not transmitted to us except as described in this policy. The device identifier is sent with seal and upload requests for entitlement verification.

8. Third-Party Services

9. Children and Age of Consent

qub is not directed at children under 13. We do not knowingly collect personal information from children under 13, consistent with the United States Children's Online Privacy Protection Act (COPPA, 15 U.S.C. §6501 et seq.). If local law in your jurisdiction requires a higher minimum age for digital consent (for example, 16 under the GDPR in some EU member states), you must meet that higher age to use qub.

If we learn that we have collected personal information from a child under the applicable minimum age, we'll delete that information from our systems within a reasonable time. Sealed content already in permanent storage cannot be deleted; the denylist limitation in §5 applies. If you believe a child under the applicable minimum age has used qub, contact us at support@qub.social with the subject prefix [PRIVACY] and we'll take appropriate action.

10. Data Security

Content sealed through qub is encrypted on your device with timelock encryption and an additional outer wrapper before transmission, so our servers do not hold plaintext (subject to the narrow exceptions disclosed in §2.1 and §2.3). Operational infrastructure handles metadata only — entitlement records, denylist entries, telemetry counters, abuse reports, identity records, and attestation data.

We apply technical and organisational measures appropriate to the risk of the processing (GDPR Art. 32; APP 11.1):

• Transport security (TLS) on every connection.
• Encryption at rest in our key-value and object stores, provided by our infrastructure platform.
• Role-restricted operational access to administrative endpoints, gated by signed bearer tokens.
• Audit logging on signing operations, entitlement issuance, and denylist changes.
• Rate-limit and bot-detection (Cloudflare Turnstile) controls on public endpoints.
• Periodic dependency audits and routine patching of build and runtime toolchains.

No system can be guaranteed secure. If we become aware of a personal-data breach that is likely to result in a risk to your rights and freedoms, we will notify the relevant supervisory authority within 72 hours where required (GDPR Art. 33; UK GDPR), and notify the OAIC and affected individuals as soon as practicable where the Privacy Act 1988 (Cth) Part IIIC Notifiable Data Breaches scheme applies.

For security concerns or to report a vulnerability, see our security policy at https://qub.social/security or email support@qub.social with the subject prefix [SECURITY].

11. International Users and Regional Privacy Rights

11.1 Cross-Border Data Transfers

qub operates from Australia. Your encrypted content lives in a global permanent public storage network, and metadata is processed by Cloudflare, Stripe, and Twilio / SendGrid (all in the United States).

When we transfer personal data outside Australia or the EEA / UK to a country without an adequacy decision (notably the United States), we rely on one of these mechanisms:

• the EU–US Data Privacy Framework (and the UK Extension) where the recipient is self-certified;
• the European Commission's 2021 Standard Contractual Clauses, or the UK ICO's International Data Transfer Addendum, as incorporated into the data processing agreements with each processor named in §8; or
• your explicit consent under GDPR Art. 49(1)(a) / APP 8.2(b) where no other mechanism is available.

To find out which mechanism applies to your data, email support@qub.social with the subject prefix [PRIVACY].

11.2 European Users (GDPR and UK GDPR)

If you are in the EEA or UK, you have the right to access, correct, delete, restrict, or port your personal data, and to object to processing based on legitimate interest. To exercise any of these rights, email support@qub.social with the subject prefix [PRIVACY].

For sealed content in permanent storage, deletion at the storage layer is technically impossible. This falls within the recognised limitations under Article 17(3) of the GDPR — notably 17(3)(a) (freedom of expression and information) and 17(3)(e) (where erasure is technically impracticable). On a substantively complete erasure request from the data subject, we will assess the request under the procedure described in our User-Generated Content Policy §6 and, where it is granted, denylist the qub from qub's viewer and embed iframe. We may decline or defer requests that are manifestly unfounded or excessive, that conflict with another party's rights (for example, a counter-party to a sealed pact), or that are precluded by a legal hold. The underlying stored data remains accessible through other means.

Article 27 representative. We have assessed our processing of EEA personal data and currently rely on the GDPR Art. 27(2) exemption: our processing is occasional, does not include special categories of data on a large scale, and is unlikely to result in a risk to the rights and freedoms of natural persons. We will appoint an Art. 27 representative in the EEA, and a separate UK GDPR Art. 27 representative for the United Kingdom, when (a) we begin offering paid plans into either market on a non-occasional basis, (b) the proportion of EEA / UK users on our identity record exceeds the level at which the Art. 27(2) exemption can be reasonably defended, or (c) a competent supervisory authority requests it. Until then, we rely on the Art. 27(2) exemption and reassess at each material product or volume change.

If you believe we have not adequately addressed your concerns, you may complain to the data protection authority of your habitual residence — for example, the UK Information Commissioner's Office (ico.org.uk) for UK users, or your member-state supervisory authority for EEA users.

11.3 California Users (CCPA / CPRA)

If you are a California resident, the CCPA / CPRA provides you with specific rights regarding your personal information. In the preceding 12 months, we have collected the following categories of personal information:

• Identifiers: email address (collected during purchases, sign-in, identity attestation, or notify-me subscriptions); device identifier (randomly generated, stored locally); auto-allocated personal handle and any personalised handle, display name, or profile URL you set on your public profile (§2.12).
• Commercial information: purchase history and entitlement records.
• Internet or other electronic network activity information: request metadata logged by our infrastructure provider (§2.9), one-way hash of IP address attached to abuse reports (§2.8), and browser-supplied request headers necessary for service delivery.

We retain personal information for the periods set out in §2.3 and §6, generally no longer than is necessary for the purpose for which it was collected. We do not collect or process sensitive personal information for purposes that would trigger the right to limit use under CPRA §1798.121.

We do not sell or share your personal information. We do not use or disclose sensitive personal information for purposes beyond those permitted by the CCPA. You have the right to request access to, deletion of, correction of, and information about the personal information we collect, and to designate an authorised agent to make a request on your behalf. We will not discriminate against you for exercising your CCPA rights.

To exercise these rights, email support@qub.social with the subject prefix [PRIVACY]. Requests must be verifiable — we will ask you to demonstrate ownership of the email address or device identifier on the record. If you designate an authorised agent, we may require you to verify the agent's authority and to confirm the request directly.

11.4 Australian Users (Privacy Act 1988)

qub is bound by the Australian Privacy Principles (APPs) under the Privacy Act 1988 (Cth). You may request access to or correction of personal information we hold about you under APP 12 / APP 13 by emailing support@qub.social with the subject prefix [PRIVACY]. We will acknowledge your request within a reasonable period (ordinarily 30 days). Direct-marketing rights under APP 7 are not engaged because we do not send marketing emails (see §2.3).

Overseas disclosures (APP 8.1). Personal information may be disclosed to recipients located in the United States (Cloudflare, Stripe, Twilio / SendGrid) and to the global permanent storage gateway network. Where APP 8.2 exceptions do not apply, by using the Service you consent to those overseas disclosures and acknowledge that APP 8.1 accountability for the act or practice of the overseas recipient is, to that extent, modified.

Complaints. If you are not satisfied with our response to a privacy complaint, you may complain to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.

12. Changes to This Policy

We may update this policy from time to time. The current version number and effective date appear at the top of this page.

Material changes that reduce your rights take effect 30 days after we post the revised policy and provide in-app notice. Other changes take effect on the revised effective date.

A summary of material amendments is maintained in §13 below.

13. Change Log

Subsections inserted into a stable section retain a letter suffix (for example §2.11a) so that cross-references to surrounding sections remain valid across revisions.