Skool Copilot — Local Data Disclosure
Version ID: skool-copilot-local-data-v3
Prepared September 30, 2026. Applies when this exact version is presented and accepted.
Publisher: Amirthan Puvaneswaran trading as Avino Labs, Finnish sole trader, Business ID 3383759-5. Privacy/support contact: copilot@avinolabs.com. Contact address: c/o Amirthan Puvaneswaran, Vapaa-ajanmaa 3 A 20, 33540 Tampere, Finland. Public policy: https://avinolabs.com/products/skool-copilot/privacy. Effective date: when this exact version is presented and accepted.
1. Storage locations
| Location | Data and purpose |
|---|---|
| Local extension database | CRM records and community relations, notes/tags, saved content, drafts, schedules, tasks/events, analytics, local execution/recovery state and media, plus the workspace's account/Skool identity binding. The workspace is not a general hosted CRM. |
| Trusted local storage | Auth session, random installation secret, settings, permitted provider configuration, workspace ownership and highest validated canonical-community revision. Content scripts do not receive these credentials. |
| Extension memory | Exact-document self/group/role/tier proof, bounded page lease, current source descriptor and comparison/coordination state. These are not workspace backups or durable membership grants. |
| Supabase account/access backend | Account email/UUID, opaque Skool identity binding and proof metadata, consent versions/times, installation-secret hash, minimized current canonical membership list, membership-derived access, saved tool choices/cooldown and bounded audit/reconciliation metadata. |
| Separately enabled Cloud services | Only the authorized scheduling, automation, monitoring, Recovery or Plan data described by that feature's disclosure. Encrypted Skool connection/content is distinct from Plan's access-controlled JSON. Account acceptance alone enables none of these services. |
2. Community identity and access checks
The new official community is Skool Copilot. The internal group ID is pinned in the application. A public backend descriptor supplies its current slug and increasing revision. A same-ID URL rename preserves existing membership evidence and choices; a different-ID move resets old membership evidence. No user setting or page message can repoint this authority. The highest validated revision persists locally across restart but never grants offline proof, and is excluded from backups.
An exact signed-in canonical page can reduce only its own self-membership fields for access checks. The raw response, payment details and session material do not leave that proof. A pending-only policy request sends the reduced tier, role and source revision with account/installation/identity authentication. Its temporary client lease has no server-hosted-data or billing authority and is subordinate to durable access. Missing or conflicting evidence fails closed.
An already-entitled account may compare role/tier evidence locally, temporarily quarantine a proven restriction and send a mismatch-semantic request. That request carries no observed tier/role and only asks the independently proved owner source to reconcile. The backend retains the existing source-wide demand/cooldown fields. This bundle does not enable a new server verification hold.
3. Current membership-list reconciliation
A complete owner-proved canonical current membership list contains only opaque current member IDs, roles, recognized tiers, active flags and generation/capture metadata, tied to exact group ID, slug and source revision. No email/hash, name, handle, note, message or CRM record is sent. An ordinary member cannot publish this membership list. The backend replaces the current generation, removes absent members and evaluates only accounts already bound to their corresponding opaque IDs.
The eligible owner pipeline ordinarily checks whether reconciliation is due every five minutes while a supported already-open signed-in context is available. Mismatch-triggered complete snapshots keep the one-hour limit. Source/identity/installation/consent, completeness and stale-work protections remain. Tool choices and the 30-day replacement cooldown are enforced by the backend. A URL change does not alter these limits.
4. Optional external actions
Published/sent content goes to Skool when you deliberately submit or authorize its delivery. Media can upload directly to validated Skool media destinations. Optional Cloud scheduling and automation use their separately disclosed connection and minimum encrypted execution payloads; monitoring and Recovery have bounded evidence and reply checks. Plan sync separately transfers only its disclosed planning data. The workspace remains subject to explicit community connections and feature-specific capture/consent controls.
AI-provider features and Auto-Like are retired. Previous inert metadata or historical legal identifiers do not re-enable those features. Earlier optional-service disclosures remain available under their recorded versions; the product rename does not enlarge their permission or sending scope.
5. Backups and loss
Use the supported backup controls and protect the selected folder/files. Core backups contain readable workspace data and ownership IDs; media bundles use their own explicit controls. Credentials, source-ordering evidence and volatile page leases are excluded. A restored workspace cannot change the canonical group or overwrite the worker's highest community revision. Clearing extension storage or uninstalling can remove all local data and requires a fresh verified source read on a new installation.
Sign-out leaves saved workspace data in place. Account deletion and optional-service teardown do not erase copies you downloaded or published to Skool. Review each deletion/stop control's scope, and cancel unwanted queued work explicitly. The Privacy Notice and feature disclosures describe the separate remote retention boundaries.
Additional v3 boundaries
Optional Cloud connection transfers both the allowed auth_token and, when present, aws-waf-token from the qualifying Skool tab's cookie store over HTTPS. The stored connection uses server-managed AES-256-GCM, not end-to-end encryption. Authorized backend code/key holders can decrypt it and a valid session can act as your Skool user. An explicit identity-conflict “Verify with Skool” action uses a bounded session transiently without retaining a Cloud connection.
Explicit prepared-video capture uses a packaged page script to intercept and suppress one validated native create-post request, retaining only opaque media references. It does not publish during capture or collect arbitrary network traffic. Hosts include Skool, regional S3 us-west-2 and S3 acceleration/dualstack upload buckets, Mux, GIPHY and the fixed Supabase project.
Plan sync is optional access-controlled JSON. Turning it off stops future transfers, not erasure of the remote copy. Verified account deletion removes linked Plan rows. Local records, other devices and downloaded backups remain separate. Oversized local records remain safe on this device; account safety ceilings do not delete existing data.
Disconnect clears live stored session ciphertext and stops connection-dependent work; historical records follow their own retention. It cannot recall an in-flight request or revoke an independently copied Skool session. Full terminal Cloud payloads become eligible for cleanup after seven days, but separately encrypted post titles can remain with job history. The Privacy Notice specifies distinct cleanup triggers, account deletion, independent current membership records and provider-backup limitations.