Cookie and tracking notice

CHiiRO reaches you through two things, and only one of them is a browser.

Conflating the two is the usual error in a notice like this, and it is usually made in the direction that flatters the operator: a site with no cookies is described alongside an app full of analytics identifiers, under one heading, so that "we don't use cookies" appears to cover both. It does not. The app is the surface where third-party identifiers exist, and clause 4 states exactly which ones and what they do.

Every entry in clause 4 was read from the shipping application source — the dependency manifests, both Android manifests, the Android network security configuration, the Firebase configuration and the app's privacy manifest. The website entries in clause 2 were read from this site's source and its build output.

The limit, stated honestly: a static read of the source proves what is linked and initialised. It does not prove every network request a running application makes. The only thing that proves that is a traffic capture from a real device, and one has not been run. If a capture ever contradicts clause 4, clause 4 is wrong and will be corrected rather than defended.

This website sets no cookies of its own, sets no third-party cookies, runs no analytics, loads no tag manager, embeds no tracking pixel, and contains no advertising or social-media tracking code. There is nothing on it to consent to, and no consent banner, because there is nothing that would require one.

It is a static site. It sends you pages; it does not watch you read them.

One thing is stored on your device, and it is not a cookie. If you use the light/dark toggle, your choice is written to your browser's local storage under the key chiiro-theme, with the value light or dark. It exists so the page does not flash the wrong theme the next time you open it. It is written only when you operate the toggle; it is never read by us, never sent anywhere — the content security policy on this site forbids the page from making any outbound request at all — and it is not an identifier. Clearing your browser's site data removes it, and the site works normally without it.

We name it because clause 2.6 says an exhaustive list that quietly omits its one exception is worth less than no list.

Measured against this site's source and its build output on 11 September 2026:

1. Zero occurrences of any analytics or tag-manager library in the source, the styles or the public assets.
2. Zero occurrences of document.cookie.
3. No third-party script tags of any kind. The one script this site ships is its own, and it sets the colour theme.
4. No embedded video player, no map, no social feed, no chat widget, no comment system, no font network. Each of these is a common back door by which a "static" site acquires a third-party cookie without anyone deciding to add one.

The typeface files are self-hosted — served from this site, not requested from a font network. That matters more than it sounds: a webfont loaded from a third-party network sends the visitor's IP address and user-agent to that network on every page view, which has been held in at least one European decision to be a transfer of personal data requiring a lawful basis. This site does not do it, and will not acquire one later for convenience.

Because a banner would be dishonest. A consent banner on a site that sets nothing trains people to click through the banners that do matter, and it implies a tracking capability this site does not have. If the site ever acquires anything that requires consent, the banner comes first and this clause is rewritten — in that order.

Clause 2.1 is a verified statement about this site — the one serving this page. It is deliberately not written as a statement about every address that has ever answered for CHiiRO.

The reason is concrete. A site has been answering at chiiro.co that Rootree does not control, deployed from a repository Rootree does not control, which returns the same application shell for every path — including /privacy-policy and /terms-of-use, the exact addresses the app links to — and which loads a third-party script we have not audited. We do not assert that it sets no cookies, because we do not know.

Publishing a verified statement about page A on page B is the failure this clause exists to prevent. Clause 2.1 travels with this site and does not travel anywhere else.

This notice is revisited — before the change goes live, not after — if the website ever gains any of:

• an analytics or product-measurement tool of any kind, including a self-hosted one;
• a newsletter or contact form that stores anything, or that posts to a third-party form service;
• an embedded video, map, calendar, social post or chat widget;
• a font, script, stylesheet or image loaded from a third-party domain;
• a login, a session, or any personalisation remembered between page loads;
• a content-delivery or edge service that sets its own routing or bot-detection cookie.

The last one is the trap. Hosting platforms sometimes set their own cookies for load balancing or bot protection without the site author adding a line of code. The current host is configured with none of its authentication features enabled, so none is set today — and the live response headers are re-checked before publication and after any hosting change, because it takes one request.

Firebase and Mixpanel are two separate analytics systems recording the same events to two different companies. We state that plainly rather than listing them as though one were a component of the other.

Each line was checked against the dependency manifests rather than assumed.

Firebase Analytics (Google). Stores an installation ID and an app-instance ID in the app's private storage. Sends Google the name of an in-app event and its parameters, your device model, operating-system version, app version, language and coarse region, and — once you are signed in — your CHiiRO account identifier, which we set deliberately so that analytics and support can be joined to an account. It does not send your name, email address, phone number, date of birth, messages or posts. It starts at app launch.

Firebase Authentication and Google Sign-In (Google). Only if you choose to sign in with Google. Stores a sign-in token on your device, and carries the authentication exchange itself; Google tells us your Google account's email address and name, which is the point of the feature. If you sign in with an email address and password, or with LinkedIn, neither is used.

Mixpanel. Stores a distinct-ID and a queue of events not yet sent. Sends Mixpanel the same in-app events Firebase receives, plus device information, plus — once you are signed in — your CHiiRO account identifier. Automatic event collection is switched off: the app configures Mixpanel with session and lifecycle tracking disabled, so it records the events CHiiRO chooses to send it and no others. That was verified in the source, not assumed. It starts at app launch.

OneSignal. Stores a push subscription ID. Sends OneSignal that subscription ID, your device model and operating-system version, your permission state, and — once you are signed in — your CHiiRO account identifier. That collection is real and it starts at app launch, which is why it is disclosed here.

What it is not doing is delivering anything. CHiiRO sends no push notifications — see Disclosures clause 4.4. The subscription is created and nothing is dispatched to it, so the identifier is collected and the purpose it exists for is not being carried out. If and when CHiiRO starts sending notifications, this clause will say so; declining the notification permission, or turning notifications off in your device settings, is the control that would stop them.

All four process data in the United States and other countries.

The one thing worth understanding: these identifiers are per-device and per-install until you sign in. When you sign in, we deliberately attach your CHiiRO account identifier to all three, so they stop being anonymous device identifiers and become identifiers linked to you. We do that so a support request or an analytics question can be answered about a specific account. It is a choice, and this is us telling you we made it.

The app stores the following in its own private storage area on your phone. None of it is a cookie, none of it is readable by other apps, and none of it is sent anywhere except as described in clause 4: your sign-in session and basic account details, so you are not asked to sign in every time; your theme and language choices; your messaging session details, so your conversations load; your résumé display preference; and the identifiers in clause 4.4.

All of it is removed when you uninstall the app or clear the app's data.

1. When you open a link or view a document from inside CHiiRO, the app hands it to your device's own browser in an in-app window. Anything stored by that page — including cookies — belongs to the site you visited and to your browser. It is not ours, we cannot read it, and your browser's settings control it.
2. If you sign in with LinkedIn, the app opens LinkedIn's own sign-in page in a private browsing window, so no LinkedIn session cookie is kept on your device afterwards. That was verified in the source. It is a deliberate choice and a good one.

1. EEA and UK. Storing or reading information on your device for analytics purposes generally requires consent under the ePrivacy rules, independently of whatever lawful basis applies under the GDPR. There is a narrow exemption for what is strictly necessary to provide a service you asked for — notification delivery and the sign-in session plausibly sit inside it; two independent product-analytics systems plausibly do not.
2. Canada. PIPEDA requires meaningful consent, assessed against what a reasonable person would consider appropriate, and a clear up-front explanation is central to it. A notice like this one is part of that; whether it is sufficient on its own for two third-party analytics systems is a legal assessment.
3. Quebec. Law 25 has its own requirement to obtain consent for technology that identifies, locates or profiles a user, and to have it deactivated by default. Whether it applies to Rootree Analytic Inc. is a legal assessment.

Three routes exist and the decision has not been made: build a consent gate before the analytics start, defaulting to off for EEA and UK users; stop shipping the analytics software to those users at all; or rely on this disclosure alone. The third is honest and thin, and it is only defensible as a short bridge to the first — which is why this notice carries a date.

What will not happen is a notice describing a consent gate before the gate ships. Clause 2.4 of the Privacy policy makes the same admission, and the two documents will continue to say the same thing.

• Notifications: Settings → Apps → CHiiRO → Notifications. CHiiRO sends no push notifications today (clause 4.3), so there is nothing for this control to stop. It is the control that would stop them if that changes. It does not remove the OneSignal subscription identifier described in clause 4.3 — that is created when the app launches, and clause 4.4 says how it is reset.
• Contacts: the same screens. Revoking the permission stops any further access to your address book immediately.
• Reset the identifiers: clear the app's data, or uninstall and reinstall. New identifiers are generated.

There is no Delete Account control in the app today. The self-serve flow is built and not shipped, so deleting your account is a request you make by the route in clause 7.5 of the Privacy policy. What deletion removes, and what we can do while the flow is unshipped, are set out in clause 8 of the Privacy policy.

There is no in-app analytics opt-out today — clause 6.