Data Processing Addendum

01Parties and acceptance

This Data Processing Addendum (“addendum”) is between Vulture Labs, Inc., a Delaware corporation, of San Francisco, California, USA (“Vulture Labs”, “we”, “us”), which provides the CLItrail service, and the organisation that uses CLItrail under the CLItrail Terms of Service (“you”).

This addendum forms part of the Terms. It applies automatically to every organisation, without a separate signature, from 24 September 2026 or from the organisation’s first use of CLItrail, whichever is later. If you need a copy signed by both parties, write to founders@pilotprotocol.network. A signed copy has the same text as this page.

The person who accepts the Terms for your organisation also accepts this addendum for it, and confirms that they may bind it.

02Definitions

• Customer Personal Data: the personal data we process on your behalf when we provide CLItrail to you. It is the data about Visitors and Installers that the website tag, the installer hook and the collection API send to CLItrail for your websites, and everything we derive from it: visits, install events, attribution results, deliveries to your destinations, log records and log-stream records. Annex I lists it in full.
• Account Data: the sign-in details, memberships, invitations, billing records, support requests and activity log of the people who use the CLItrail dashboard. We process Account Data as a controller under the privacy policy. It is not Customer Personal Data.
• Visitors: people who visit your website where the CLItrail tag runs.
• Installers: people who install or run your command-line tool with the CLItrail installer hook in it.
• Destination: a recipient you set up in CLItrail to receive install events: Google Analytics 4, Google Ads, Meta, TikTok, X Ads or your own webhook. A log stream is a copy of your organisation’s log records sent to storage you choose (Enterprise plan).
• Subprocessor: a third party we engage that processes Customer Personal Data. Destinations and log streams are not subprocessors (section 09).
• Personal Data Breach: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.
• Data Protection Law: every law on the protection of personal data that applies to the processing of Customer Personal Data, including Regulation (EU) 2016/679 (GDPR), the UK GDPR and the UK Data Protection Act 2018, the Swiss Federal Act on Data Protection of 25 September 2020 (FADP), and the California Consumer Privacy Act as amended by the California Privacy Rights Act (Cal. Civ. Code §1798.100 et seq.) with its regulations (CCPA).
• SCCs: the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

Other terms, such as controller, processor, data subject, processing, business, service provider, sell and share, have the meaning Data Protection Law gives them.

03Roles and scope

• You are the controller of Customer Personal Data, and we are your processor. If you use CLItrail for a client, as an agency does, your client is the controller, you are its processor and we are your subprocessor. You then confirm that your client has authorised your instructions to us, including the subprocessors in Annex III, and we deal only with you.
• Account Data is ours. For Account Data we are the controller, and the privacy policy applies instead of this addendum.
• What we process, why and for how long is described in Annex I. The security measures are in Annex II and the subprocessors in Annex III.

04Your instructions

We process Customer Personal Data only on your documented instructions. Your instructions are:

1. the Terms and this addendum;
2. the settings you choose in CLItrail: your websites and their domains; the identifiers the tag reads (the providers setting); install paths; reconstruction on or off; the attribution policy; your destinations, whether each is in test mode or live, whether it includes reconstructed installs, and the consent values you set on it; your retention period for data and for logs; your log streams; and the exports and deletions you make;
3. any other written instruction that an owner or admin of your organisation sends to founders@pilotprotocol.network and that we accept in writing.

Running the service for you also includes the following processing, which your instructions cover:

• Logs. CLItrail records every collection request it receives for your websites and every request it sends on your behalf. This recording cannot be switched off (Terms §11).
• Our operator copy. A copy of every log record from every organisation, with service health figures, goes to our own storage, a Cloudflare® R2 bucket. We use it only to keep the service running, to find and fix faults, and to detect and respond to abuse and security incidents. Deleting a website or an organisation does not remove records already in the operator copy.
• Abuse protection. Rate limits and plan limits, which count requests using keyed hashes.
• Recovery copies. Our hosting provider keeps point-in-time recovery data for 30 days.

We do not use Customer Personal Data for any other purpose. In particular we do not use it to build profiles of people, for our own advertising or analytics, to develop other products, or for benchmarking, and we do not combine it with personal data from other customers or from any other source. Matching runs within one website at a time: we never match one customer’s visitors or installers against another customer’s data.

If we believe an instruction infringes Data Protection Law, we will tell you without delay, and we may pause the processing concerned until you confirm or change the instruction. If a law we are subject to requires us to process Customer Personal Data other than as instructed, we will tell you before we do so, unless that law forbids it.

05Your responsibilities

You are responsible for the lawfulness of the processing you instruct. In particular you:

• give Visitors and Installers the notices the law and each destination’s terms require, and describe CLItrail, the installer hook and reconstruction in them;
• obtain consent where the law requires it: before the tag reads cookies, writes to browser storage or sends identifiers (keep the tag inactive with enabled: false until then), and before the installer hook reads browser storage and system settings where the law requires consent for that;
• meet each destination’s own terms before you switch it live. For X Ads, that includes giving your users instructions on how to opt out of X’s interest-based advertising through the mechanism X describes at help.x.com/en/safety-and-security/privacy-controls-for-tailored-ads;
• set the Google Ads consent values truthfully;
• do not send us special categories of personal data, data about children, or names, email addresses, phone numbers or precise locations, through custom context, page addresses or any other field (Terms §08);
• keep the credentials you paste into CLItrail valid and authorised, and revoke them at the platform when you stop using them.

06Confidentiality and our people

Only people who need access to run, support or secure CLItrail can access Customer Personal Data, and only as far as the task needs. Each of them is bound by a duty of confidentiality, by contract or by law. We look at Customer Personal Data only to provide the service, to handle a support or rights request you ask us to handle, to investigate a fault or a security incident, or to comply with the law.

07Security

We implement and maintain the technical and organisational measures in Annex II, which the security page summarises. We may change them over time, but never in a way that lowers the protection of Customer Personal Data.

08Subprocessors

• Authorisation. You give us general written authorisation to engage the subprocessors listed on the Subprocessors page, which is Annex III of this addendum.
• Their obligations. Each subprocessor is bound by a written contract with data protection obligations that protect Customer Personal Data at least as well as this addendum. We remain responsible to you for their work.
• Notice of changes. Before we add or replace a subprocessor, we tell you at least 30 days before it starts processing Customer Personal Data, through the notice channels in section 20. The notice names the subprocessor and says where it is, what it will do, which data it will handle and which transfer safeguard applies.
• Your right to object. You can object on reasonable data protection grounds within those 30 days by writing to founders@pilotprotocol.network. We will discuss your objection in good faith and look for a way to meet it, for example by not using the new subprocessor for your data. If we cannot resolve it, you may end the Terms for the organisation concerned: cancel the plan, then delete the organisation once the subscription has ended (your last organisation is deleted with your account).
• Urgent replacement. If we must replace a subprocessor at short notice to keep Customer Personal Data secure or the service running, we will tell you as soon as we can, and your right to object applies from then.

09Recipients you choose

Destinations and log streams are not our subprocessors. When you switch a destination from test mode to live, or create a log stream, you instruct us to send Customer Personal Data to that recipient. The recipient then processes it under its own terms with you, not under this addendum, and you accept those terms separately.

• Nothing leaves CLItrail for an analytics or advertising platform until an organisation on a paid plan adds a destination and switches it live.
• Visits made with Global Privacy Control are never used for Google Ads, Meta, TikTok or X Ads.
• The Subprocessors page lists each destination, what it receives and the role its own terms give it.
• Deleting data in CLItrail does not recall data already delivered. It stays with the recipient under that recipient’s retention.

10Requests from Visitors and Installers

• Requests that reach us. If a Visitor or an Installer asks us to access, correct, delete or restrict their data, or objects to its use, we pass the request to you without undue delay. We do not answer it ourselves, except to tell the person that we have passed it on, unless you instruct us to.
• Tools you can use yourself. You can export a website’s install events as CSV (paid plans), export logs as CSV or NDJSON, shorten retention periods, delete a website at any time, and delete an organisation once its subscription has ended (your last organisation is deleted with your account).
• Help with individual records. CLItrail does not know who a Visitor or Installer is. On your written instruction we find the records of one person by website and installation ID (the file in ~/.local/state/clitrail/ on their computer) or by the identifiers you give us, and export or delete them.
• Complaints. We tell you promptly about any complaint we receive about data CLItrail collected or sent for you, including complaints from a destination platform (Terms §9.5).
• California. Section 15 applies to requests under the CCPA.

11Personal data breaches

• Notice. We tell you without undue delay after we become aware of a Personal Data Breach, through the channels in section 20.
• Content. The notice describes, as far as we know at the time: the nature of the breach, including the categories and approximate number of people and records concerned; its likely consequences; the measures we have taken or propose; and who to contact for more information. Where we cannot give everything at once, we send it in stages without further undue delay.
• Response. We take reasonable steps to contain and investigate the breach and reduce its effects, and we keep you informed.
• Your credentials. If credentials you gave us for a destination or log stream may have been exposed (for example a Google service account key, a Meta or TikTok access token, X app keys and access tokens, S3 access keys, or a webhook or log-stream signing secret), we tell you in the same way, so that you can revoke and replace them at the platform and give any notice your agreement with that platform requires. X’s developer terms, for example, require prompt notice to X of a suspected security breach.
• Not an admission. Notifying you of a breach is not an admission of fault.
• Unsuccessful attempts that do not compromise Customer Personal Data, such as blocked requests, scans or failed sign-ins, are not Personal Data Breaches.

12Help with assessments and authorities

We give you the information you reasonably need for data protection impact assessments and prior consultations with a supervisory authority about CLItrail: this addendum, the privacy policy, the documentation on what is collected, security and secrets and retention and deletion, the security page, and written answers to reasonable questions.

13Information and audits

• Information. On request we give you the information needed to show that we meet this addendum: the documents in section 12, and written answers to a reasonable security questionnaire once every 12 months, or more often after a Personal Data Breach or where a supervisory authority requires it.
• Audits. If that information does not show that we meet this addendum, you, or an independent auditor you appoint who is bound by confidentiality and is not our competitor, may audit our compliance. Give us at least 30 days’ written notice and a proposed scope. Audits take place once in any 12 months unless a Personal Data Breach or a supervisory authority requires another, during business hours, and remotely unless an on-site visit is needed. You bear your own costs. An audit may not give access to other customers’ data. Our subprocessors are audited under their own contracts, and we pass on the reports they make available to us where their terms allow.
• CCPA steps. The same rights let you take reasonable and appropriate steps to check that we use Customer Personal Data in line with your CCPA obligations, and, on notice, to stop and remediate any unauthorised use.

14International transfers

• Where the data is. Vulture Labs, Inc. is in the United States. CLItrail runs on Cloudflare’s network. Its database and secret store are Cloudflare Durable Objects™, which Cloudflare places in a data centre near where they were first used; we have not restricted them to a jurisdiction.
• Transfer safeguards. Where you transfer Customer Personal Data to us from the EEA, the UK or Switzerland and Data Protection Law requires a safeguard for that transfer:
  • EEA: the SCCs apply as set out in Schedule 1: Module 2 when you are a controller, Module 3 when you are a processor.
  • UK: the SCCs apply as amended by the UK Addendum in Schedule 2.
  • Switzerland: the SCCs apply with the changes in Schedule 3.
• Onward transfers. Each subprocessor receives Customer Personal Data under a safeguard recognised by Data Protection Law, listed in Annex III.
• Precedence. If this addendum or the Terms conflict with the SCCs, the SCCs prevail.
• No Data Privacy Framework claim. Vulture Labs does not rely on the EU-U.S. Data Privacy Framework for these transfers.

15US state privacy laws

Where the CCPA or another US state privacy law requires terms in a contract with a service provider or processor, this section applies, and we act as your service provider or processor.

Business purposes. You disclose Customer Personal Data to us only for these limited and specified business purposes, and we process it only for them:

1. receiving visits and install reports from your website tag and installer hook, and matching installs of your software to visits to your websites, to give you attribution analytics;
2. sending install events to the destinations you set up and switch live, on your instruction;
3. showing you dashboards, logs and exports, and streaming your logs to storage you choose;
4. keeping the service secure and protecting it against abuse, and finding and fixing errors, including through the logs and our operator copy (section 04);
5. storing it for the retention periods you set, and deleting it.

Restrictions. We do not:

• sell or share Customer Personal Data;
• retain, use or disclose it for any purpose other than the business purposes above, including any commercial purpose, except as the CCPA otherwise permits;
• retain, use or disclose it outside our direct business relationship with you;
• combine it with personal information we receive from, or on behalf of, anyone else, or collect from our own interactions with consumers, except as the CCPA regulations permit for a business purpose.

Our commitments. We comply with the CCPA as it applies to us and give Customer Personal Data the same level of privacy protection the CCPA requires of you. We tell you if we determine that we can no longer meet our obligations under it. You can take the steps described in section 13. We help you respond to consumer requests as described in section 10, and you tell us of any consumer request we must act on. Each subprocessor is bound by a contract that meets these requirements, and we tell you when we engage one (section 08). We understand these restrictions and will comply with them.

Deliveries to advertising platforms. When you switch on a Google Ads, Meta, TikTok or X Ads destination, you disclose Customer Personal Data to that platform, which may use it for its own advertising purposes under its terms. That disclosure is yours. We make it only on your instruction, and we do not provide cross-context behavioural advertising ourselves. You are responsible for any notice, opt-out of sale or sharing, and opt-out preference signal that this disclosure requires. CLItrail keeps visits made with Global Privacy Control away from these platforms.

16Requests from public authorities

If a public authority asks us for Customer Personal Data:

• we tell you promptly, unless the law forbids it, and we refer the authority to you where we can;
• we review whether the request is lawful and challenge it where there are reasonable grounds to consider it unlawful;
• we disclose only the minimum the request lawfully requires;
• we keep a record of the request and our response, and share it with you where the law allows.

17Deletion and return

• While you use CLItrail. You can export data and delete websites at any time, and delete an organisation once its subscription has ended (section 10). Automatic retention deletes older data on the schedule in Annex I.
• When a paid plan ends. The organisation moves to Free. Ending the plan deletes no visits or install events: they stay for the website’s retention period until you delete them. Two things are deleted: reconstruction signals, at the next maintenance pass (within about a minute), and log records older than the Free plan’s 7-day log retention, at the next hourly clean-up. Destinations and log streams are paused. On Free the install-event export is not available, so export before the paid month ends (Terms §13.3).
• When you delete a website or your organisation. Its data is removed from the live database and the secret store at once. Deleting an organisation also removes its log records from the live database; deleting a website leaves its log records to expire with your log retention period (at most 90 days). Then:
  • recovery copies at our hosting provider can no longer be restored after 30 days;
  • records already in our operator copy are not removed by the deletion (section 04);
  • our hosting provider’s platform logs are deleted within 7 days;
  • copies in your own log-stream storage, and data already delivered to your destinations, are under your control or the recipient’s.
• Return. Export anything you need before you delete it. If we end the service, we give you 30 days’ notice, during which you can sign in and export.
• After we close an organisation or end the service. We keep the organisation’s Customer Personal Data for 30 days. During that time an owner can ask us at founders@pilotprotocol.network for an export of its install events and logs, unless a law, court or authority prevents it. After the 30 days we delete the data as described above (Terms §13.2).
• What can be exported. The data you can export, and the formats, are listed in full in Terms §13.3.
• No charges. We charge nothing for exports or for moving your data to another provider.
• Confirmation. On request we confirm the deletion in writing.
• Legal holds. If a law requires us to keep any Customer Personal Data longer, we keep only that data, protect it under this addendum, and use it only for that legal purpose.

18Liability, precedence and duration

• Liability. Each party’s liability under this addendum is subject to the limitations in the Terms, except liability that the law does not allow to be limited and except as the SCCs require.
• Precedence. For the processing of Customer Personal Data, the SCCs (with the UK Addendum and the Swiss changes where they apply) prevail over this addendum, and this addendum prevails over the rest of the Terms.
• Duration. This addendum applies for as long as we process Customer Personal Data for you. Sections that by their nature should continue, such as sections 11, 16 and 17, continue after that.
• Law and courts. This addendum is governed by the law and decided by the courts named in the Terms, except for the SCCs, which follow Schedules 1 to 3.

19Changes to this addendum

We may change this addendum to follow changes in Data Protection Law, in guidance from authorities, in our subprocessors (section 08) or in the service. Each version is dated and kept in the version history below.

• We send you every change to this addendum through the channels in section 20. Publishing a new version on this page is never the only notice.
• A change that does not reduce the protection of Customer Personal Data is sent to you when we publish it, and takes effect then.
• A change that reduces that protection is sent to you at least 30 days before it takes effect, through the channels in section 20. If you object in writing within that time, the previous version continues to apply to your organisation until the end of its current billing month, and either of us may end the Terms for that organisation then.
• A change required by law or by a supervisory authority takes effect when the law or the authority requires.
• New versions of the SCCs or the UK Addendum apply as those documents provide.

Version history

20How we send notices

Notices to you. Notices under this addendum (subprocessor changes, Personal Data Breaches, exposed credentials, changes to this addendum, and requests from authorities) are written and sent by us:

1. by email from founders@pilotprotocol.network to every owner of the organisation concerned, at the email address of the account the owner signs in with; and
2. for subprocessor changes, also as a dated entry in the change log on the Subprocessors page; for changes to this addendum, also in the version history above.

Keep your owners’ accounts current. To have notices also sent to another address, such as your privacy team, write to founders@pilotprotocol.network. Apart from sign-in link emails sent through Firebase, the CLItrail service sends no automated email.

Notices to us. Send notices, objections and instructions under this addendum to founders@pilotprotocol.network.

21Contact

Processor

Vulture Labs, Inc., a Delaware corporation

Address

San Francisco, California, USA

Contact for this addendum

founders@pilotprotocol.network

Schedule 1: EU Standard Contractual Clauses

1. Incorporation. The SCCs (Commission Implementing Decision (EU) 2021/914) are incorporated into this addendum by reference and completed as follows. Accepting the Terms counts as signing them, including their annexes.
2. Modules. Module Two (controller to processor) applies where you are a controller. Module Three (processor to processor) applies where you are a processor. You are the data exporter and Vulture Labs is the data importer.
3. Clause 7 (docking clause). Applies.
4. Clause 8.1 (instructions). Your documented instructions are those in section 04.
5. Clause 8.5 (duration and deletion). Deletion and return follow section 17. We give the certification of deletion on request.
6. Clause 8.6 (breach). Notification follows section 11.
7. Clause 8.9 (documentation and audits). Audits follow section 13, which does not limit your rights under Clause 8.9.
8. Clause 9(a) (subprocessors). Option 2, general written authorisation, applies. The time period is 30 days. The agreed list is Annex III, and changes are notified as described in section 08.
9. Clause 11(a) (redress). The optional wording on an independent dispute resolution body does not apply.
10. Clause 13 (supervision). The competent supervisory authority is set out in Annex I.C.
11. Clause 17 (governing law). Option 1 applies. The SCCs are governed by the law of Ireland.
12. Clause 18(b) (forum). The courts of Ireland.
13. Annexes. Annex I.A, I.B and I.C, Annex II and Annex III of the SCCs are completed by the annexes of this addendum.
14. Relationship. Nothing in this addendum or the Terms varies the SCCs or limits a data subject’s rights under them. Where they conflict, the SCCs prevail.

Schedule 2: UK Addendum

For transfers of Customer Personal Data that are restricted transfers under the UK GDPR, the SCCs apply as amended by the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner (“UK Addendum”), which is incorporated by reference and completed as follows:

• Table 1 (Parties). The parties, their details and key contacts are those in Annex I.A. The start date is the date this addendum first applies to your organisation.
• Table 2 (Selected SCCs, modules and clauses). The version of the Approved EU SCCs incorporated by Schedule 1, including the Appendix Information, with Modules Two and Three and the options chosen there.
• Table 3 (Appendix Information). The list of parties is Annex I.A, the description of the transfer is Annex I.B, the technical and organisational measures are Annex II, and the list of subprocessors is Annex III.
• Table 4 (Ending the UK Addendum when the Approved Addendum changes). Neither party.
• Part 2 (Mandatory Clauses). “Part 2: Mandatory Clauses of the Approved Addendum, being the template Addendum B.1.0 issued by the ICO and laid before Parliament in accordance with s119A of the Data Protection Act 2018 on 2 February 2022, as it is revised under Section 18 of those Mandatory Clauses.”

As the UK Addendum provides, for these transfers the competent supervisory authority is the Information Commissioner, and the SCCs are governed by the laws of England and Wales, with disputes decided by the courts of England and Wales.

Schedule 3: Switzerland

For transfers of Customer Personal Data that are subject to the Swiss FADP, the SCCs apply as set out in Schedule 1, with these adaptations, which follow the guidance of the Swiss Federal Data Protection and Information Commissioner (FDPIC) of 27 August 2021, last amended 12 February 2025:

1. Supervisory authority. For transfers governed by the FADP, the competent supervisory authority in Annex I.C is the FDPIC. Where a transfer is governed by both the FADP and the GDPR, the FDPIC supervises it under the FADP and the authority named under Clause 13 supervises it under the GDPR.
2. Governing law and forum. For claims about transfers governed by the FADP, the SCCs are governed by the law chosen in Schedule 1 (the law of Ireland, which grants third-party beneficiary rights), and Clause 18(b) refers to the courts chosen there.
3. Data subjects in Switzerland. The term “member state” in the SCCs must not be interpreted in a way that excludes data subjects in Switzerland from suing for their rights in their place of habitual residence (Switzerland), in accordance with Clause 18(c).
4. References to the GDPR. References to the GDPR are to be understood as references to the FADP insofar as the transfers are subject to the FADP.

Annex I: Description of the processing

A. List of parties

Data exporter

Name

The organisation that uses CLItrail, as named in its CLItrail account

Address

As held in your billing details, or as you tell us

Contact

The owners of the organisation, at their sign-in email addresses

Activities relevant to the transfer

Using CLItrail to learn which visits to its websites lead to installs of its command-line software, and to send install events to the destinations it chooses

Role

Controller (Module Two), or processor acting for a client (Module Three)

Signature and date

Given by accepting the Terms, on the date this addendum first applies to the organisation

Data importer

Name

Vulture Labs, Inc., a Delaware corporation, provider of CLItrail

Address

San Francisco, California, USA

Contact person

The founders of Vulture Labs, Inc., founders@pilotprotocol.network

Activities relevant to the transfer

Providing the CLItrail service described in Annex I.B

Role

Processor (Module Two), or subprocessor (Module Three)

Signature and date

Given by publishing and applying this addendum, effective 24 September 2026

B. Description of the transfer

Categories of data subjects

• Visitors: people who visit the data exporter’s websites where the CLItrail tag runs.
• Installers: people who install or run the data exporter’s command-line software with the CLItrail installer hook in it.

Categories of personal data

On the Free plan CLItrail performs no matching. Visits are stored as on other plans, without journey links or reconstruction signals, and with their receipt kept only as a SHA-256 hash, but no install is ever matched against them. Installs are stored with their installation ID, event ID, event type and time, install path, system, architecture, browser families and default browser, and with no attribution result. Receipts that an installer sends are never looked up, and handoff tokens are never stored. As on every plan, the log keeps each receipt and handoff token only as a keyed hash with its last six characters.

Sensitive data. None. The Terms forbid sending special categories of personal data, and data about children, through CLItrail.

Frequency of the transfer. Continuous: whenever the tag or the hook sends data, and whenever a delivery or a log-stream batch runs.

Nature of the processing. Collection over HTTPS; storage; hashing; matching installs to visits by receipt or handoff token; reconstruction (probable matching from network and other coarse signals, on paid plans when switched on); aggregation for dashboards; display; export; transmission to destinations and log streams on the exporter’s instruction; logging; deletion. The tag also stores a visit receipt and up to four values (clitrail_source, google_session_attributes, clitrail_ttclid, clitrail_twclid) in the Visitor’s browser, and the hook stores the random installation ID in a file on the Installer’s computer.

Purposes. The business purposes in section 15: attribution analytics for the exporter, delivery to its destinations, dashboards, logs and exports, security, abuse protection and debugging, and storage for the retention periods it sets.

Retention

Deletion of a website or an organisation, and the end of the processing, follow section 17.

Transfers to subprocessors. As listed in Annex III, for the subject matter, nature and duration stated there.

C. Competent supervisory authority

• Where the data exporter is established in an EU Member State: the supervisory authority responsible for the data exporter’s compliance with the GDPR for the transfer.
• Where the data exporter is not established in the EU, falls under the GDPR through its Article 3(2) and has appointed a representative under Article 27(1): the supervisory authority of the Member State where that representative is established.
• Where the data exporter is not established in the EU, falls under the GDPR through its Article 3(2) and is not required to appoint a representative (Article 27(2)): the Data Protection Commission of Ireland, as the authority of one of the Member States where the Visitors and Installers whose data is transferred are located.
• UK transfers: the Information Commissioner (Schedule 2).
• Swiss transfers: the FDPIC (Schedule 3).

Annex II: Technical and organisational measures

These are the measures CLItrail applies to Customer Personal Data. The documentation pages What is collected, Security and secrets, Retention and deletion and Logs describe them in more detail.

1. Collecting less

• The tag keeps page addresses and referrers only as origin and path, reads identifiers only for the providers the customer keeps enabled, sets no cookies, and collects nothing when a website starts it with enabled: false.
• The hook reads only files of 80 to 4,096 bytes inside browser website-storage folders, looking for CLItrail receipts for that one website, and discards everything else. It never reads browsing history, cookies, passwords, bookmarks or Safari’s protected storage. It sends no file names, paths, user or host names, environment variables or command output.
• The hook exits before reading anything when DO_NOT_TRACK=1 or CLITRAIL_DISABLE=1 is set, or in a detected CI environment unless the customer sets CLITRAIL_ALLOW_CI=1.
• CLItrail collects no names, email addresses or other contact details of Visitors and Installers. The installation ID is a random value.
• On the Free plan, nothing is matched.
• Visits made with Global Privacy Control are never used for Google Ads, Meta, TikTok or X Ads. Meta and TikTok receive a SHA-256 hash of the installation ID, never the ID.

2. Hashing instead of storing

The rate-limit hash is keyed with the master-key secret itself. Every other keyed hash uses HMAC-SHA256 with a key derived by HKDF-SHA256 from the master key. None can be reversed without the key.

3. Credentials: encrypted and kept apart

• Encryption. Every credential a customer gives CLItrail (GA4 API secrets, Google service account keys, Meta and TikTok access tokens, X Ads consumer keys and secrets and access tokens and secrets, S3 access keys, webhook and log-stream signing secrets) is encrypted with AES-256-GCM under a key derived by HKDF-SHA256 from the master key, and bound as authenticated data to its own reference and record. Moved to another record, it fails to decrypt.
• A separate secret store. The encrypted values live in their own store, a separate SQLite-backed Durable Object class (CLItrailVault) with its own namespace, apart from the main database. The main database keeps only an opaque reference, the last four characters (for values of 12 characters or more), an 8-character fingerprint and when it changed. The store serves no HTTP, accepts only encrypted values, and answers only the service, over Cloudflare’s internal RPC, with a token derived from the master keys.
• Keys apart from both. The master keys are platform secrets, never stored in either database. The service does not start in production without them. Keys can be rotated without downtime.
• Write-only. Once saved, a credential is never shown again. Forms never prefill it.
• Real deletion. Deleting or replacing a credential first overwrites its encrypted value with zeros, then removes it.
• Used briefly. A credential is decrypted only when one destination or stream needs it. Google access tokens made from a service account key stay in memory until they expire and are never stored.
• Scrubbing. Error messages from platforms are cleaned of known secret values and common credential shapes before they are stored or shown. Logs replace access tokens, API secrets, signatures and Authorization headers with [redacted].

4. Encryption at rest and in transit

• Cloudflare encrypts Durable Object data, including metadata, at rest with AES-256, and R2 objects at rest with AES-256.
• The service is published at an HTTPS address, and its HTTPS responses carry Strict-Transport-Security (max-age one year). It refuses any request that carries a credential, or would reveal a generated one, unless the request arrives over HTTPS.
• Log-stream batches to S3 are signed with AWS Signature Version 4. Webhook deliveries and log-stream webhooks are signed with Standard Webhooks headers.

5. Access control

• Sign-in. Customers sign in with Google, or with a one-time sign-in link sent to their email address, through Firebase Authentication. Email-link accounts must have a verified address. The server checks every sign-in token itself (signature against Google’s published keys, audience, issuer and times) and asks Firebase whether the account is disabled or its sessions revoked. CLItrail keeps no password.
• Sessions. A random session token in an HttpOnly, SameSite=Strict cookie (Secure over HTTPS), stored only as a hash, lasting 7 days. Users can list and end their sessions.
• Roles. Every dashboard and API request is checked against the user’s role in the organisation (owner, admin, member or viewer). People outside an organisation cannot see that it exists.
• Confirmation. Deleting an account, an organisation that has websites, or a website requires a fresh sign-in (Google or email link) by the same account.
• Limits. Dashboard writes: 30 a minute per client; reads: 600 a minute per session. Dashboard writes must come from the service’s own origin.
• Operator access. Administrative routes need an operator token, compared in constant time and never stored in a database.
• Support. The message and diagnostics of a support request are visible only to the person who sent it and to the CLItrail operator. The organisation’s activity log records that a request was sent, with its topic.

6. Logging and monitoring

• Every collection request (including rejected, rate-limited and malformed ones), every request CLItrail sends, every account and organisation change, and every internal error produces a log record. Recording cannot be switched off. If a record cannot be written, the service still answers and writes a fallback line to the platform log.
• An activity log records security and configuration changes: who, what and when, never a secret value.
• A health record every 5 minutes reports queue depths, delivery successes and failures, sign-in failures and stream lag. Alert records are written when storage passes 80 %, when a log stream fails three times in a row, and when a monthly quota passes 80 % or 100 %.
• Each organisation can read only its own records.

7. Availability and recovery

• The service runs on Cloudflare Workers® and Durable Objects. Cloudflare keeps point-in-time recovery data for each Durable Object’s database for 30 days.
• Collection keeps answering even when a log record cannot be written. Deliveries retry as each platform’s rules allow. Log streams deliver in order and at least once, from a cursor, with a bounded backlog and alerts.
• Collection is rate limited: bodies of at most 16 KB; 240 requests a minute per client; 6,000 visits and 1,200 install reports a minute per website; 30 install reports a minute and 500 a day per website and client.
• CLItrail makes no uptime commitment.

8. Retention and deletion

• Retention periods are set per website and per organisation, and older data is deleted automatically by the service’s maintenance pass, which applies retention about once an hour (Annex I.B).
• Deleting a website, an organisation or an account removes its data from the live database and secret store at once (section 17).
• Exports of install events (CSV) and logs (CSV or NDJSON) are available to customers. Cells a spreadsheet could read as a formula are prefixed so they are never evaluated.

9. Web application

• Pages are served with a Content Security Policy that allows only the service’s own scripts and styles (plus, on the dashboard, the Google origins sign-in needs), frame-ancestors 'none', X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, a restrictive Permissions-Policy and Cross-Origin-Opener-Policy.
• The Firebase sign-in code is served from CLItrail itself. Pages load no third-party code, apart from Google’s sign-in helper on the dashboard.
• Before installs can reach Google Ads, Meta, TikTok or X Ads, the customer must prove control of the website’s domain with a DNS record and confirm that it meets the platform’s notice and consent requirements. CLItrail records when and by which account that confirmation was given.

10. Organisational measures

• Access to Customer Personal Data is limited to people who need it, bound by confidentiality (section 06).
• Subprocessors are bound by written data protection terms (section 08).
• Personal Data Breaches and exposed credentials are handled and notified as in section 11.
• Security reports are received at founders@pilotprotocol.network under the disclosure policy on the security page.
• We review these measures whenever we change how CLItrail collects, stores, sends or protects data.

11. Measures of subprocessors

Cloudflare applies the measures in its own data processing addendum to the hosting, storage and network it provides (Annex III).

Annex III: Subprocessors

The current list is on the Subprocessors page, which forms this annex. On 24 September 2026 it is: