Privacy policy

01Who we are and what this covers

CLItrail is a hosted service operated by Vulture Labs, Inc., a Delaware corporation based in San Francisco, California, USA (“CLItrail”, “we”). CLItrail is a project developed by Pilot Protocol, which Vulture Labs, Inc. also operates, so our email address is on that domain. Write to founders@pilotprotocol.network about anything in this policy.

This policy covers CLItrail only:

• the website at clitrail.com and its documentation;
• the dashboard;
• the website tag and the installer hook;
• the collection service.

Vulture Labs’ other websites and products have their own policies.

It covers three groups of people:

• Customers: people who sign in to CLItrail and belong to an organisation that adds CLItrail to its website and installer. Websites, destinations, install paths, the plan and billing belong to the organisation.
• Visitors: people who visit a customer’s website where the CLItrail tag runs.
• Installers: people who install or run a customer’s command-line tool that includes the CLItrail installer hook.

02Our two roles

For account, organisation and billing data, we are the controller. Where the California Consumer Privacy Act applies, we act as a business for this data and follow its rules. We decide how your sign-in details, memberships, billing records and support requests are used. We use them only to run, secure, bill and support the service. Sections 11 to 17 describe this data.

For visitor and installer data, we are a processor. Where the California Consumer Privacy Act or another US state privacy law applies, we act as the customer’s service provider or processor (Data Processing Addendum).

• The customer organisation that installs the tag and hook is the controller, and its privacy notice applies. It decides which identifiers are collected, which destinations receive them and how long they are kept.
• We process this data only to provide the service to that organisation and to keep the service secure. We never use it for our own advertising or analytics, and we never combine it across customers.
• Our Data Processing Addendum sets out these commitments and forms part of our terms.

If you visited a website or installed a tool and want to use your privacy rights, contact that company first. We help customers answer such requests, and you can also write to founders@pilotprotocol.network.

03What the website tag collects

The tag is one script, browser.js, served by CLItrail. On a page where it runs, it fetches the website’s public settings, registers the visit and then confirms it.

• Ad identifiers. It reads Google Ads, Meta, TikTok and X identifiers only for the providers the customer keeps enabled. By default, all of them are enabled.
• GA4 IDs. It reads GA4 client and session IDs from the website’s own GA4 tag whenever a measurement ID is known. That can be one the GA4 tag declares, one set on the CLItrail tag, or one from a GA4 destination.
• Consent. The tag collects nothing at all when the customer starts it with enabled: false, for example until a visitor consents.
• Plans. It works the same way on every plan.

The tag reads only the first-party cookies listed above and sets no cookies. It saves up to five things in the visitor’s browser:

• A visit receipt in the website’s private browser storage (the Origin Private File System), in a file named opfs-install-attribution.<website>.<page>.json. The file holds:
  • the format and version;
  • the website and page IDs and the origin;
  • a random 256-bit receipt;
  • its creation and expiry times.

  It contains no ad or analytics identifiers.

• clitrail_source in session storage: the campaign source for the current tab.
• google_session_attributes in local storage: Google’s session attributes.
  • The tag writes it when the landing page’s address carries gclid, gbraid or a gad_* parameter, unless the website starts the tag with a providers list that leaves out Google Ads.
  • CLItrail keeps the attributes only if the website’s provider settings include Google Ads.
  • Google’s own helper uses the same key.
• clitrail_ttclid in local storage: the last TikTok click ID that arrived in a page address, and when. Not written if the providers list leaves out TikTok.
• clitrail_twclid in local storage: the last X click ID that arrived in a page address, and when. Not written if the providers list leaves out X.

The two click times are sent to CLItrail to date each click, never to the platforms. A website that starts the tag in handoff mode saves nothing in the browser: no receipt and none of the values above.

When a website prepares a copyable install command, the tag creates a handoff token tied to the visit, usable by one installation. To do this it sends the visit’s receipt, or, when no receipt could be written, the same visit data.

Visitors can remove everything the tag saved by clearing the website’s data in their browser. The cookie notice lists these items with their lifetimes, for customers’ own cookie notices.

04What the installer hook reads and sends

The installer hook is a plain-text POSIX shell script that a customer runs after their tool installs, or when the tool first starts. The installer page describes it in full. In short:

What it reads

• Only the current user’s browser website-storage folders, for:
  • Chrome, including its Beta, Dev and Canary channels;
  • Chromium, Edge, Brave, Vivaldi and Firefox;
  • on Linux®, also Zen, and the Snap and Flatpak folders.
• In those folders it checks files of 80 to 4,096 bytes for the CLItrail receipt format. It keeps only valid, unexpired receipts for that one website. Anything else is discarded, never stored or sent.
• It stops after four seconds or 20,000 files.

What it asks the system

• A few coarse facts:
  • the processor architecture;
  • the default web browser: on macOS, the https handler macOS keeps in its settings; on Linux, what xdg-settings or xdg-mime reports;
  • the time zone;
  • the language setting.
• Each question takes at most one second. If there is no answer, the value is left out.

What it sends: one HTTPS request containing:

• the website ID, and the install path ID when the hook has one;
• the event type (install_started, install_completed or first_run);
• a random event ID and a random installation ID;
• up to 64 receipts it found, or, when the website prepared the install command, a handoff token tied to that visit;
• darwin or linux, and the architecture (arm64 or x86_64);
• which browser families have a folder on the computer, and the default browser’s family;
• a time zone name such as Europe/Berlin and a language tag such as en-US.

Like any web request, it carries the computer’s IP address (see section 6).

What it writes: one small file under ~/.local/state/clitrail/, holding the random installation ID, so that repeated runs are counted once. Older copies of the hook kept this file in ~/.local/state/opfs-attribution-shell/; an ID found there is reused rather than replaced.

What it never does

• It never reads browsing history, cookies, passwords, bookmarks or Safari’s protected storage.
• It never sends file names, paths, user or host names, or environment variables and command output as they are. System answers are reduced to the short values listed above.
• It never runs when DO_NOT_TRACK=1 or CLITRAIL_DISABLE=1 is set, or in a detected CI environment (see opt-outs).

05Attribution and plans

The tag and the hook behave the same on every plan. What CLItrail does with a report depends on the organisation’s plan.

Free

No matching of any kind.
Visits are stored with the same fields as on paid plans (section 6), except the reconstruction signals and the links between repeat visits. While the organisation stays on Free, they are used only for visit counts and for browser, operating-system and device distributions. If it upgrades, a visit whose receipt has not yet expired (30 days) can be matched to an install reported after the upgrade, or be linked to a later visit, and that visit’s identifiers can then reach the destinations the customer sets up.
Installs are stored with their event type, event ID, installation ID, time, install path, platform, architecture, browser families and default browser. They are used only for counts and distributions, and installs reported while on Free are never matched later.
Receipts and handoff tokens sent by the hook are never looked up or used for matching. The only trace of them is the label the request log keeps for every request: the last six characters and a keyed hash (section 8).
There is no reconstruction, no network hashes, no journeys, no campaign or channel derivation and no deliveries while on Free.

Standard and Enterprise

An install is matched to a visit by a receipt the hook found, or by a handoff token. When neither arrives, reconstruction can suggest a visit from other signals (below).
An install that stays unattributed is marked:
• Safari when the computer’s default browser is Safari, or when it is a Mac with no profile folder of a browser the hook can read;
• External otherwise (another computer, a phone, a container or a remote agent).

Reconstruction

On paid plans only. On by default, and can be switched off for each website.
It compares an install with recent visits from the same public network: the same IPv4 address or IPv6 /64, or, as a weaker signal, the same IPv4 /24. It scores them on how recent the visit was, the operating system, time zone, language, browser and architecture, whether that visit already led to another install on the same install path, and how many browsers share the network.
It never matches on a network where more than three browsers visited in the window. It needs the network plus at least one other signal that agrees.
Results are labelled probable, with a confidence of high or medium and the list of signals that agreed or disagreed.

Over a monthly quota

On Free, visits and installs beyond the month’s quota are counted but not stored. Paid plans are never cut off.

Paused install paths

After a downgrade, installs on an install path beyond the plan’s limit are counted, but not matched or delivered, until the owner chooses which paths to keep.

06What we store, and what we never store

Receipts and tokens

Only SHA-256 hashes; the request log keeps only a label with the last six characters and a keyed hash (section 8). The receipt itself exists only in the visitor’s browser and in the installer’s request. On Free, handoff tokens are not stored at all.

IP addresses

Never stored in the clear, either in our database or in our logs. An address is used in memory for three things:
• Rate limits. Their counters use a keyed hash of the address and are deleted when the limit’s window ends, after at most one day.
• The request log keeps a keyed hash of it (section 8).
• Reconstruction. On paid plans with reconstruction on, it is used to compute the keyed network hashes below.
A keyed hash cannot be turned back into the address without our key. It can still link requests from the same address, so we treat it as personal data.
Our hosting provider’s short-lived platform logs can include the address (section 14).

Visits

Website, page, origin, referrer, campaign source, the provider identifiers in section 3, the GPC flag, the browser family and major version, operating-system family, device type and timestamps. Google’s session attributes, which include the browser’s user-agent string, are kept as received so that they can be forwarded to Google Ads. These fields are stored on every plan.

Reconstruction signals

Only on paid plans with reconstruction on:
• keyed hashes of the visit’s public network and of its IPv4 /24;
• a keyed hash of its user-agent string;
• its operating-system family, time zone, language and architecture.
They are kept for the reconstruction window (72 hours by default, at most 7 days) and deleted within about a minute after it ends. Switching reconstruction off deletes them at once. On a plan without reconstruction, the next maintenance pass deletes them.

Install events

On every plan: event type, installation ID, install path, platform, architecture, the browser families found and the default browser family.
On paid plans, also:
• the time zone and language;
• the attribution result (matched, ambiguous, unmatched or probable) and the method (receipt, handoff or reconstructed);
• for reconstructed installs, the confidence and the signals;
• for unattributed installs, the reason (Safari or External);
• the visits the install matched, oldest first.

Deliveries

The payload prepared for each destination, and its status. Error messages from platforms are stored with credentials removed.

Usage counters

One count per organisation and month of install-page visits and reported installs, for the plan’s monthly quota.

Logs

The telemetry described in section 8.

07Where data goes

Nothing leaves CLItrail for an analytics or advertising platform unless an organisation on a paid plan adds a destination and switches it from test mode to live. In test mode, events are prepared and shown in the dashboard but never sent.

The only recipients are the destinations below that the customer sets up, by pasting credentials from its own accounts. Each ad platform and GA4 receives its own identifiers from the visits the install matched, following the website’s attribution policy. Install starts (install_started) go only to webhooks.

Global Privacy Control. Visits made with GPC are never used for Google Ads, Meta, TikTok or X. GA4 and webhooks still receive them as the customer’s own measurement, and webhook payloads mark them gpc: true.

Reconstructed installs. Probable installs reach GA4 or an ad platform only if the customer turns on “Include reconstructed installs” for that destination. Webhooks receive every event with its result.

Before going live. An advertising destination cannot go live until the customer:

• verifies its website’s domain; and
• confirms that it meets the platform’s notice and consent requirements.

We record when the confirmation was given and by which account.

The platforms’ own role. Each recipient uses the data under its own terms and privacy policy, not ours:

• Meta. For people in the EU, the customer and Meta Platforms Ireland are joint controllers for collecting this data and sending it to Meta.
• TikTok. For people in the EEA, the UK and Switzerland, the customer and TikTok are joint controllers for collecting and sending it.
• X. X processes conversion data both on the customer’s behalf and as an independent controller for its own advertising purposes.
• Google. Google processes the data under its advertising and Analytics terms.

Opting out of interest-based ads. Use the choices each platform offers. For example:

• X’s controls for personalised ads;
• the industry tools at optout.aboutads.info and youronlinechoices.eu.

Log streams. Customers on the Enterprise plan can also stream their organisation’s logs to their own storage (section 8).

08Telemetry and logs

CLItrail records every request it receives and every call it makes, so that customers can see exactly what happened and we can operate and secure the service. Recording is always on and cannot be switched off.

Inbound

Every collection request (visits, visit confirmations, handoffs and install reports), including rejected, rate-limited and malformed ones. The record holds:
• the body exactly as received, which includes the identifiers in section 3 and the hook fields in section 4;
• the method, route, time, response status and error code;
• the website and organisation;
• the derived browser and operating system;
• the resulting visit or event IDs.
Each receipt and handoff token in the body is replaced by a label with its last six characters and a keyed hash. The connection’s IP address is kept at most as a keyed hash. Oversized bodies are kept truncated, with the reason. Stripe’s notifications to us are logged with only their event ID, type and result, never their content.

Outbound

These calls are recorded:
• every delivery attempt and connection test for GA4, Google Ads, Meta, TikTok, X and webhooks;
• every log-stream batch;
• every call the service makes to Stripe, to Google (sign-in checks, and the token requests for Google Ads destinations) and to Cloudflare’s DNS resolver for domain verification.
Each record keeps the request and response bodies (up to 64 KB each), the endpoint, method, status, duration and attempt. Access tokens, API secrets, keys, signatures and Authorization headers are replaced by [redacted].

Whose records

Organisation records. Calls made for an organisation belong to its logs: deliveries, tests, log-stream batches, domain checks, and Stripe checkout and billing-portal requests. A Stripe checkout request includes the email address of the owner who subscribes.
Service records. Some calls belong to no organisation: the calls made at sign-in (the fetch of Google’s public keys and the account check) and the token requests for Google Ads destinations. The account check’s response is Google’s record of the signed-in account: your Firebase user ID, email address and the profile details Google returns with it.

Activity

Every account and organisation action (who, what, when; never a secret value), plus internal errors, alerts and service health.

Who can see them

Everyone in the organisation can read its records in the dashboard’s Logs view. Members, admins and owners can also export them (viewers cannot). On Free, attribution fields are redacted there, as everywhere else. Service records are not shown to any organisation.

Retention

Organisation records: 30 days by default, within the plan’s limit:
• Free: always 7 days;
• Standard: 7 to 30 days;
• Enterprise: 7 to 90 days.
Owners and admins choose the period. Older records are deleted automatically. All of an organisation’s records are deleted when the organisation is deleted.
Service records: 30 days.

Customer log streams

Enterprise organisations can send copies of their own records to storage they choose, under their own agreement with its provider: an Amazon S3, Cloudflare® R2 or other S3-compatible bucket, or a webhook. What happens to those copies is up to the customer.

Our operator copy

A copy of every record, from every organisation and from the service itself, goes to CLItrail’s own storage: a Cloudflare R2 bucket. We use it to operate, debug and secure the service, and only the people who run the service can read it.
Deleting a website, an organisation or an account does not remove records already copied there.

09Privacy signals and opt-outs

On websites

• Global Privacy Control is recorded with the visit and keeps it away from advertising platforms (section 7).
• The customer’s consent choice. A website can keep the tag inactive with enabled: false or data-enabled="false". It then collects and stores nothing.
• Clearing site data removes the receipt and the four stored values.

In terminals

These settings stop the hook itself. Some installers download the hook while they install (for example curl … | sh, or a prepared command). In that case the download reaches CLItrail before the hook can check the settings:

• Like any download, it carries the connection’s IP address and the download tool’s name and version, and its address holds the website ID.
• It is not recorded in CLItrail’s logs. Our hosting provider’s short-lived platform logs can include it.
• The hook then exits without reading or sending anything.

A hook shipped inside the tool’s package makes no request at all. See the installer page.

Deleting ~/.local/state/clitrail/ removes the stored installation ID, and a later run creates a new one. If an older copy of the hook created ~/.local/state/opfs-attribution-shell/, delete that folder too.

10How long we keep data

11Accounts and organisations

Sign-in with Google.

• How it works. You sign in to CLItrail with your Google account, through Google’s Firebase Authentication. Google checks your password and 2-Step Verification; CLItrail never sees them. After you sign in, Google gives the dashboard a signed token. Our server checks it with Google, including whether the account has been disabled or its sessions revoked, and exchanges it once for a CLItrail session.
• What we keep. From the token we keep your Firebase user ID, your email address, whether Google has verified that address, and the sign-in provider.
• Your name. If your Google account has a name, we use it once to name your personal organisation (for example “Ada’s organisation”). If it has none, we use the part of your email address before the @. You can rename that organisation.
• What we do not ask for. We ask Google only for the standard sign-in details (your basic profile and email address). We ask for no other access to your Google account.

Sign-in with an email link. Instead of Google, you can ask for a sign-in link by email.

• Google’s Firebase sends that email to the address you enter, on our behalf.
• Until you open the link, the dashboard keeps the address in your browser’s local storage, so that it can finish the sign-in on the same device.
• Opening the link shows that you control the address. We then keep the same details as for Google sign-in.

Your sign-in record at Google. Firebase keeps a user record for our project in Google’s systems:

• your Firebase user ID and email address;
• the Google account it is linked to, if you sign in with Google;
• when it was created and when you last signed in.

Google uses your IP address and your browser’s user-agent string during sign-in to secure it and prevent abuse. It keeps logged IP addresses for a few weeks, and it runs Firebase Authentication only in US data centres.

Deleting your CLItrail account does not remove this record automatically. Write to us and we will delete it too.

Organisations. For each organisation we keep:

• its name and plan;
• its members, with their email address, role (owner, admin, member or viewer) and when they joined;
• pending invitations, with the invited email address, role, expiry and a hash of the invitation link’s token.

Every user gets a personal organisation on first sign-in. If you were invited, an admin of that organisation gave us your email address. They share the invitation link with you themselves.

Billing. For an organisation on a paid plan we keep:

• its Stripe customer ID and subscription ID;
• the subscription status and plan, and the end of the current period;
• any scheduled cancellation.

We send Stripe:

• the organisation’s ID and the chosen plan;
• for a new Stripe customer, the email address of the owner who subscribes.

You enter card details on Stripe’s own pages; they go to Stripe, never to us. You change payment methods, see invoices and cancel in Stripe’s billing portal.

Support. For requests you send from the support page while signed in, we keep:

• your email address and organisation;
• the topic and website;
• your message and any diagnostics you paste;
• the request’s status and our reply.

Before a request is stored, anything that looks like a credential is removed. Our reply appears on the support page. We also keep emails you send to founders@pilotprotocol.network, and our replies.

Sessions and activity.

• Your sign-in sessions: a hashed token, with its creation and last-use times.
• An activity log of security and configuration changes: who, what and when, never a secret value.

Email. We do not send marketing email.

• The service itself sends no email, except the sign-in links that Google sends for us when you choose email sign-in.
• We write to organisation owners ourselves only for the notices our terms and Data Processing Addendum require, never for marketing.
• Invitations are links you share yourself, and our replies to support requests appear on the support page.

12Why we use account data, and on what legal basis

We use the data in section 11 only for the purposes below. Where the GDPR or the UK GDPR applies, each purpose has the legal basis shown.

• Providing data. You need an email address, which comes from the account you sign in with, to hold a CLItrail account. Without it you cannot use the dashboard. Visitors and installers do not have to provide anything, and the opt-outs in section 9 apply.
• No automated decisions. We make no decisions about you based solely on automated processing that have legal or similarly significant effects on you.
• No other use. We do not use account data for advertising and do not sell it. We use the information we receive from your Google account only to sign you in and run your account.
• Objecting. Where we rely on legitimate interests, you can object (section 16).

13Security

• Secrets in a separate store. Everything a customer gives us to reach another service is encrypted with AES-256-GCM. That covers:
  • GA4 API secrets;
  • Google service-account keys;
  • Meta and TikTok access tokens;
  • X app keys and access tokens;
  • S3 access keys;
  • webhook and log-stream signing secrets.

  Each is bound to its own record, so it cannot be moved to another, and the keys can be rotated. The encrypted values live in a dedicated secret store kept apart from the main database. The main database holds only a reference, the last four characters and a fingerprint. For a Google service-account key, it also holds the service account’s email address, and the last four characters are those of the key’s ID rather than of the key. Deleting a secret erases it from the store.

• Keys apart from both stores. The encryption keys come only from the hosting environment’s secret settings, never from either store. The service does not start without them.
• Hashed, never recoverable. Sign-in session tokens, invitation tokens, visit receipts and handoff tokens are stored only as hashes, and network addresses only as keyed hashes.
• Write-only credentials. Once saved, a credential is never shown again. The dashboard displays only its last four characters, a fingerprint and when it changed, and for a Google service-account key the service account’s email address and the last four characters of its key ID.
• Access. Every dashboard and API request is checked against your organisation role. You must confirm with a fresh sign-in before deleting a website, an organisation that has websites, or your account.
• Transport and browser. Credentials are accepted only over HTTPS. Our pages load no third-party code, apart from Google’s sign-in helper on the dashboard (section 18). They are served with:
  • a strict Content Security Policy;
  • HSTS;
  • headers that block framing and limit referrers.
• Abuse limits. Collection endpoints are rate limited per website and per network, and each plan has the limits listed in the terms.

No system is perfectly secure. If we learn of a personal data breach that affects your data, we will tell the affected customers and the authorities as the law requires.

14Service providers

We use three service providers. For visitor and installer data (our processor role), the providers are Cloudflare, and Google (Google Workspace) for anything sent to us by email. Google’s Firebase Authentication and Stripe handle only account and billing data. The current list of the providers that handle visitor and installer data, with its changes, is on the Subprocessors page.

Stripe’s own role. Stripe processes some payment data for us and some as an independent controller for its own purposes, such as preventing fraud and meeting its legal duties. Its Data Processing Agreement sets out how this works, and its privacy policy applies to the second part.

Other recipients. Destinations and log streams are recipients the customer chooses (section 7), not our providers. We use no advertising or analytics providers of our own. We disclose personal data to public authorities only when the law requires it.

15International transfers

Vulture Labs is a US company, and CLItrail runs on providers based in the United States. If you are in the EEA, the UK or Switzerland:

• your account data is collected by us in the United States;
• visitor and installer data reaches us from our customers.

Our providers. Cloudflare, Inc., Google LLC and Stripe, LLC each state that they comply with the EU-U.S. Data Privacy Framework, its UK Extension and the Swiss-U.S. Data Privacy Framework. Cloudflare and Stripe also rely on the European Commission’s Standard Contractual Clauses where needed. Each provider’s privacy policy describes these safeguards and how to obtain a copy:

• Cloudflare
• Google (Firebase)
• Stripe

Customers’ data. For visitor and installer data sent to us by customers in the EEA, the UK or Switzerland, the safeguard is the European Commission’s Standard Contractual Clauses (Module 2, and Module 3 where the customer is itself a processor), with the UK Addendum and the Swiss adaptations, as set out in our Data Processing Addendum. That published addendum is the copy of the safeguard.

16Deletion, export and your rights

Customers

• Export. Export a website’s install events as CSV from its settings (paid plans). Export logs as CSV or NDJSON from the Logs view.
• Delete a website to remove:
  • its visits, handoffs, events, journeys and delivery queue;
  • its destinations, with their credentials;
  • its activity log.

  The organisation keeps a one-line record that the website was deleted.

• Delete an organisation. Owners can do this after cancelling any active subscription. You cannot delete your only organisation; delete your account instead. It removes:
  • its websites, as above;
  • its install paths;
  • its log streams, with their credentials;
  • its billing record and settings;
  • its logs.
• Delete your account to remove:
  • your sessions, support requests and your own activity log;
  • every organisation you are the only member of.

  If you are the last owner of an organisation with other members, first make someone else an owner. Cancel the subscription of any organisation you are the only member of first. Your past actions there stay in its activity log, without your name. To remove your sign-in record at Google as well, write to us (section 11).

• Correct your details. Your email address comes from the account you sign in with. For Google sign-in, change it in your Google account, and your next sign-in updates it here. If you sign in with an email link, write to us to change it. Owners and admins can rename organisations.

Deletion takes effect immediately in the live database and in the secret store. Some copies go later:

• logs expire with their retention period;
• recovery copies expire after 30 days;
• records already in our operator copy are not removed (section 8).

Visitors and installers

Contact the company whose website or tool you used; it controls this data. You can also write to founders@pilotprotocol.network.

CLItrail does not know who you are. To find your records, we need something we store, such as:

• the website and your installation ID (the file in ~/.local/state/clitrail/); or
• a click identifier from an ad you clicked.

We pass requests to the company concerned and help it answer them.

Your rights

Depending on where you live, you may have the right:

• to access your personal data and get a copy;
• to correct it or have it deleted;
• to restrict how it is used;
• to receive it in a portable format;
• to object to its use, including use based on legitimate interests.

To use these rights, write to founders@pilotprotocol.network. We may ask you to confirm the request from the email address on your account, or by signing in, so that we give data only to the right person.

We answer within the time the law sets:

• GDPR and UK GDPR: one month. It can be extended by two further months for complex requests; we will tell you if it is.
• California: 45 days. It can be extended once by 45 days; we will tell you if it is.

You can also complain to a data protection authority. In the EEA, that is the authority where you live or work; in the UK, the Information Commissioner’s Office; in Switzerland, the Federal Data Protection and Information Commissioner.

Ad platforms. Customers decide whether to send data to advertising platforms, and they are responsible for any notice or opt-out that this requires.

17Notice for California residents

This section applies to California residents. Where the California Consumer Privacy Act applies to us, it is our notice at collection, and the California part of this policy, for the personal information we control: account, organisation, billing and support data.

For visitors and installers, we act as the customer’s service provider (section 2), and the customer’s notice at collection applies. For customers writing their own notices, CLItrail processes these categories for them:

• identifiers: random receipts, installation IDs, ad click and cookie identifiers, and keyed hashes of IP addresses;
• internet or other electronic network activity: pages visited on the customer’s website, referrers and campaign values;
• device information: browser, operating system, device type, architecture, time zone and language.

Notice at collection

What we do not do

• No sale or sharing. We do not sell personal information or share it for cross-context behavioural advertising, and we have not done so in the preceding 12 months.
• No under-16s. We have no actual knowledge of selling or sharing the personal information of consumers under 16.
• Sensitive personal information. We collect none, beyond the sign-in credentials needed to access your account. We use those only to authenticate you, which is a purpose permitted by 11 CCR §7027(m).
• Business-purpose disclosures. In the preceding 12 months we disclosed the categories above only to the service providers in section 14, for the business purposes shown.

Your California rights

• the right to know what personal information we have collected about you, including specific pieces, sources, purposes and the categories of recipients;
• the right to delete it;
• the right to correct it;
• the right not to be treated differently for using these rights.

We do not sell or share personal information or use sensitive personal information beyond permitted purposes, so there is no sale, sharing or sensitive-information use for you to opt out of or limit.

How to make a request

• Write to us. Email founders@pilotprotocol.network. CLItrail operates only online, so email is our method for requests.
• Verification. We match the request to the email address on your account, and may ask you to confirm it from that address or by signing in.
• Authorised agents. An agent can make a request for you with your signed permission. We may still ask you to confirm your identity with us directly.
• Response times. As in section 16.

Opt-out preference signals. Because we do not sell or share personal information, a Global Privacy Control signal has nothing to opt you out of on clitrail.com. On customers’ websites, CLItrail records the signal and keeps that browser’s visit away from advertising platforms (section 7).

18This website: cookies and browser storage

The CLItrail website, documentation and legal pages load no third-party scripts, fonts or analytics, and set no cookies.

After you sign in, the dashboard sets one cookie, attr_session. It is strictly necessary to keep you signed in: HttpOnly, SameSite=Strict, and it lasts 7 days.

Google sign-in. The dashboard’s sign-in screen, and the dashboard pages that can ask you for a fresh sign-in (website settings, your account and organisation settings), load Firebase’s sign-in library from clitrail.com itself. That library then:

• loads Google’s sign-in helper from apis.google.com;
• frames Google’s sign-in page for our project;
• opens Google’s sign-in in a pop-up, or in a full-page redirect when pop-ups are blocked.

On Safari and on mobile browsers, it loads the helper and the frame as soon as one of those pages opens. On other browsers, it loads them when you choose to sign in. Google’s own privacy policy applies to these steps.

Email-link sign-in. If you ask for a sign-in link, Google’s Firebase emails it to you on our behalf, and the dashboard keeps the address in your browser’s local storage until you open the link on the same device (cookie notice).

Local and session storage. The documentation, support page and dashboard remember a few display choices in your browser’s local storage. The support page keeps an unsent request in session storage for the current tab.

The cookie notice lists every item, with its purpose and lifetime.

19Children

CLItrail is a service for businesses and is not directed at children. Customers may not use CLItrail on websites or tools directed at children.

20Changes and contact

We will publish any change on this page, with a new date, before it takes effect. Earlier versions are available on request.

Operator

Vulture Labs, Inc., a Delaware corporation

Address

San Francisco, California, USA

Privacy and data requests

founders@pilotprotocol.network

Security reports

founders@pilotprotocol.network — see Security