Skool Copilot — Privacy Notice

Version ID: skool-copilot-privacy-v3. Prepared September 30, 2026. Applies when this exact version is presented and accepted.

Publisher and contact

Skool Copilot is provided by Amirthan Puvaneswaran trading as Avino Labs, Finnish sole trader, Business ID 3383759-5. It is an independent Chrome extension and is not affiliated with or endorsed by Skool. Contact us about privacy or account data at copilot@avinolabs.com. Contact address: c/o Amirthan Puvaneswaran, Vapaa-ajanmaa 3 A 20, 33540 Tampere, Finland. Support: copilot@avinolabs.com. Public policy: https://avinolabs.com/products/skool-copilot/privacy. Effective date: when this exact version is presented and accepted.

The publisher determines the purposes and means of account administration, access eligibility, security and support. Community operators determine their own member-workflow purposes and targets and must establish authority for those workflows. A feature opt-in does not establish a processing agreement or a lawful basis for processing another person’s data. Local-only CRM data remains under the operator’s control.

1. What stays on your device

Your local workspace can contain member/contact identities and community relationships, notes, tags, pipeline stages, saved content, drafts, schedules, events, planning records, activity observations and media you create or import. Records come from information you enter, deliberately save/drop/import, explicitly sync, or allow supported scoped capture to read on Skool. Features use their own account, community and capture controls. Local CRM records are not uploaded as a general hosted CRM.

Trusted extension storage also holds your Skool Copilot Auth session, random installation secret, settings, provider configuration you enter and workspace identity. Ordinary page scripts and content messages do not receive the Auth tokens or installation secret. Your browser profile, device and retained backup files remain security boundaries; local content and backups are readable, not end-to-end encrypted.

2. Account, identity and access

The fixed Supabase backend receives your independent account email/UUID, authentication metadata, bound opaque Skool user ID and binding/proof metadata, an installation-secret hash, exact accepted notice IDs/timestamps, saved tool choices and replacement cooldown, membership-derived role/tier/access status, and bounded security/reconciliation metadata. Your Skool Copilot email and password are separate from Skool. Supabase Auth handles the account password; Skool Copilot does not ask for your Skool password. Confirmation and recovery email use the configured transactional-email service.

Product access uses the official Skool Copilot community's stable internal group ID and current protected slug/revision. An eligible verified owner supplies a complete current membership list: opaque member IDs, recognized membership roles and tiers, active flags, group/source identity and capture/generation metadata. This includes members who do not have extension accounts. No member email/hash, name, handle, CRM note or message is included. A later complete snapshot replaces the previous current list and removes absent members. An ordinary member cannot upload this list.

While durable membership access is pending, an exact currently signed-in canonical page may reduce its own self-membership evidence to opaque self/group IDs, role, recognized tier and source revision. An older membership shape may require one exact read-only self membership-product request. Only the reduced proof and existing account/installation authentication reach the policy service. Raw page/payment responses are not archived. The temporary memory-only client lease expires and cannot authorize server-hosted records or billing. For active access, a restrictive local observation may temporarily restrict features and request owner reconciliation; that request sends no observed tier or role. The pipeline ordinarily performs lightweight due-checks every five minutes in an eligible already-open context, with source-wide limits on full reconciliation.

An explicit “Verify with Skool” action during an identity conflict can send a bounded Skool session once over HTTPS for the backend to ask Skool which account is signed in. This proof uses transient server memory and stores binding/proof outcome metadata, not the session envelope. It does not create a Cloud connection. The separate Cloud connection described next has different retention.

3. Optional Cloud connections and operations

Account acceptance does not enable optional Cloud services. When you explicitly connect a supported Cloud service, trusted extension background code reads the allowed Skool auth_token and, when present, aws-waf-token from the exact qualifying tab's cookie store. It sends this bounded session, browser User-Agent and capture/expiry metadata over HTTPS to the fixed backend for identity proof and authorized Cloud operations. Both allowed cookie values can be included in the encrypted stored connection. The optional WAF value can also be used transiently as an exact media-upload header in the browser.

These credentials can act as your Skool session. The backend encrypts the connection using server-managed AES-256-GCM with random IVs and identity-bound associated data. Supported Cloud content is also encrypted with server-managed keys. This is not end-to-end encryption: authorized backend code, or an operator or attacker with the necessary backend/key access, can decrypt it. Some routing, identity, consent, timestamps, status, lease and replay metadata are access-controlled records rather than encrypted content. A valid session remains powerful even if storage is encrypted. The public Supabase client key is not a decryption key or a grant to read these records.

Separately enabled scheduling, event reminders and Auto DMs transfer the minimum authored content, supported opaque media capabilities, exact targets, time/configuration and execution metadata needed for authorized unattended delivery. Raw local media uploads directly to validated Skool destinations; the Cloud scheduler receives supported opaque references, not your local media library. Remote delivery can run while your browser and computer are off. No uncertain action is automatically retried after irreversible send intent; consult its outcome and Skool before creating a new action.

Community-by-community membership monitoring reads directory responses temporarily and retains an encrypted latest comparison of opaque members and membership/tier/billing-status evidence plus scan progress. It can create selected bounded events with encrypted minimum display identity. This latest comparison is replaced rather than archived after every scan. Independently enabled Recovery or automations may share permitted membership observations; notification consent alone does not authorize messaging.

Payment Recovery uses separately enabled communities, exact recipients, encrypted case/configuration data and minimum display identity. Reply safety reads a bounded window of an existing exact conversation before follow-ups, temporarily processes reply text/attachment evidence, then discards message bodies rather than storing a conversation archive. Encrypted routing/check boundaries and pause state remain as needed for the case. Recovery retains per-case revenue/currency/time summaries for the owning account; an ownerless all-time currency aggregate can survive account deletion, subject to a contributor floor before display. It contains no stored owner/community/member field; this is a limited aggregate, not a promise that every derived number is erased on deletion.

4. Optional Plan sync

Plan sync is separately optional. It transfers task titles/descriptions/status/dates, planning and tracked goals, daily results, focus intervals/durations, minimized own-post IDs/timestamps, community IDs/names and the disclosed planning preference. These are access-controlled JSON, not application-layer encrypted or end-to-end encrypted. Task descriptions may include information you entered. Plan does not copy your CRM, other members' records, post bodies, messages, media or Skool cookies.

Turning sync off stops future synchronization on that device; it does not erase the remote copy or another device. Locally valid records too large for sync stay on the device with identifiable diagnostics. Account storage/rate safety ceilings can stop additional growth without deleting existing data. Local work, other devices and previously downloaded backups have separate deletion controls. Verified account deletion removes the account's Plan records; contact the publisher for a request you cannot complete through the account interface.

5. Media, destinations and browser scope

Skool receives normal page requests, exact access checks, and content/media you deliberately submit or authorize a workflow to deliver. Uploads use validated Skool destinations including regional Amazon S3 us-west-2 bucket hosts, S3 acceleration/dualstack bucket hosts and Mux. A requested GIF fallback sends the search query to GIPHY under the existing provider configuration. Chosen backups, downloads, clipboard and operating-system share targets are destinations you control.

The extension does not request general browsing-history or all-sites access. Host access is limited to Skool, the named media-host families, GIPHY and the fixed Supabase project. Storage, alarms, side-panel, scripting, notification and narrowly scoped cookie capabilities support the disclosed features. A packaged page script intercepts one exact native create-post request only during an explicitly initiated prepared-video capture: it validates and suppresses that request so it does not publish, then retains validated opaque media references. It does not collect arbitrary network traffic.

AI-provider integration and Auto-Like are retired. This build does not send AI prompts or workspace context to OpenRouter, Anthropic or another model provider. Historical legal documents or inert backup metadata do not re-enable them.

6. Purposes, roles and lawful basis

We use the data described here to provide account access and security, preserve exact consent and identity boundaries, operate features you request or separately enable, retain necessary replay/operational history, and respond to support/rights requests. Membership-based access is determined automatically from current evidence and saved tool choices. Incorrect or unavailable evidence can restrict access; contact support for review. You can ask the publisher for human review of an incorrect access decision.

Account administration and the account, Plan and Cloud services you request rely on contractual necessity where processing is objectively necessary to supply that service. Security, replay prevention and minimum membership-access verification serve the publisher’s legitimate interests in securing the service and restricting access to eligible members. You may object to processing based on legitimate interests. Community operators must establish their own basis for member workflows. Optional choices control operations and can be disabled; accepting a notice is not blanket consent to process every category of data.

7. Recipients and international transfers

Visible recipients are Supabase for authentication/database/Edge backend services; Namecheap Private Email (Namecheap Inc. and its service affiliates) for account email; Skool and its validated media destinations (Amazon S3 and Mux) for selected uploads/content; GIPHY for requested search; and destinations you choose for exports/sharing. Provider infrastructure can receive normal request/security metadata such as IP addresses and timestamps even where application content is minimized.

The Supabase project is hosted in Paris, France (eu-west-3). Account confirmation and recovery emails use Namecheap Private Email, provided by Namecheap Inc. and its service affiliates, through mail.privateemail.com. The selected Skool, upload and GIF services have their own infrastructure and privacy practices; an EU database region does not mean every email, support, media or security-log recipient is in the EU. Contact the publisher for information about applicable provider processing and transfer safeguards.

8. Retention and deletion

Local user records generally remain until you edit/delete/reset them, clear extension data or uninstall. Local activity observations are bounded to 90 days and focus evidence to its 400-day window. Exported files and your selected backup folder are independent copies. Automatic folder backups rotate verified current copies and a bounded 30-day restore-point set; an OS/cloud-sync service may retain its own copies. Skool Copilot cannot delete files or content you copied elsewhere merely because you sign out or delete the account.

Account, binding, installation, consent and enabled-service records generally remain while the account/service exists. Entitlement audit records have a 90-day cutoff and old reconciliation history a 30-day cutoff, with current/latest snapshot references retained; cleanup is opportunistic during successful snapshot application, not a guarantee of erasure at the exact deadline. Deleted Auth account references in limited audit rows become null. The independent canonical current membership list may still contain an opaque Skool ID until a replacement omits it, without an account link.

Plan raw own-post evidence has a 90-day cutoff and server focus a 401-date-key cutoff to accommodate device/UTC boundaries, cleaned on the next sync. Tasks, goals, daily results and tombstones persist until their content is deleted or the account is removed; deleting a task removes its content but leaves a replay-safe deletion marker.

Terminal Cloud full-body/recipient/media payloads normally become eligible for cleanup seven days after terminal outcome. Separately encrypted post titles can remain with terminal job history. Job/event shells generally have a 90-day cutoff; referenced or active data can remain until safe cleanup conditions hold. Disabled automation state follows its documented purge/cleanup conditions. Current membership comparison remains while needed for active or paused configurations; selected notification events and mutation markers expire within 30 days and have event-count caps. Active or reply-paused Recovery cases retain only the routing/evidence needed for operation and review; terminal reply routing follows the seven-day cleanup. Content-free operation/replay fences may persist for account lifetime to prevent accidental duplicate execution.

Disconnect clears the primary live stored Skool-session ciphertext and stops work using that connection, including cancellation of undispatched supported queue work. It does not necessarily delete every historical job, definition, comparison or consent row immediately. It cannot recall an in-flight request, delete already published Skool content or revoke a Skool cookie independently copied elsewhere. Use Skool/browser session controls for that separate boundary.

Account deletion requires a confirmed signed-in account and active installation proof, then deletes the Auth account and cascades ordinary linked Cloud/Plan data. It does not erase your local workspace, other devices, downloaded backups or already submitted Skool content. Sign-out removes this installation's Auth session and volatile access proof; it does not erase saved workspace data. Local reset, sign-out, disconnect and account deletion are separate actions.

The Supabase project is hosted in Paris, France (eu-west-3). Daily physical database backups are available through the provider’s seven-day Pro backup window. Deletion is not immediate erasure of every provider backup or security-log copy. Backup and log copies have provider-controlled retention and access restrictions; these are separate from deletion in the live application database. Contact the publisher for a rights request concerning these copies.

9. Rights and requests

Contact copilot@avinolabs.com for access, correction, erasure, restriction, objection or portability where applicable, including inaccessible accounts. Amirthan Puvaneswaran handles requests. We may require proportionate identity verification; do not send passwords or Skool cookies. Requests are answered through a verified private channel within one month; any lawful extension will be explained within that month. You may complain to Finland’s Office of the Data Protection Ombudsman (tietosuoja.fi). Community members may also contact their community operator.

10. Changes

Material changes use new exact notice IDs and a reviewed acceptance boundary. Earlier accepted documents and timestamps are not rewritten or relabelled. Optional Cloud and Plan notices retain separate choices. The public policy, Store disclosures and in-product notices must describe the same released practices.

Related notices: Terms v3 and Local Data v3.