Cookie & Tracking Policy
IN FORCE. See 00-README. Read with the Privacy Policy. For Turkish visitors, the TR overlay is in force and applies alongside this Policy (owner resolution 7, 2026-08-13).
Legal basis. Every provision below rests on one of three things: a measured fact about the platform (cited to file and line), a rule of law (cited to the instrument and article in the Legal Basis Register), or a commercial choice CIQRA has made where the law leaves it open. Prepared and adopted by CIQRA OÜ.
Controller (CIQRA websites, e.g. ciqra.com and dashboards): CIQRA OÜ, registry code 16465907, Veskiposti tn 2, Tallinn 10138, Estonia · privacy@ciqra.com In force from: 2026-08-09 · Version: 1.0 · Adopted by: CIQRA OÜ
1. What this covers
This Policy explains how cookies and similar technologies (local storage, pixels, SDKs, device identifiers, and server-side event tracking) are used on CIQRA's own websites and dashboards. On a Merchant's Storefront, the Merchant is the controller for its own cookies/tracking and must publish its own cookie notice; CIQRA provides the consent-management tooling and the default configuration described here.
CIQRA's determination on the controller split: CIQRA treats the Merchant as controller for Storefront tracking and itself as provider of the consent-gating mechanism. This allocation has not been tested against a supervisory authority's view, and the Fashion ID line of case law (§5) means CIQRA's provision of an integration is not automatically outside controllership for the collection stage.
2. What cookies and similar technologies are
Cookies are small files stored on your device. We also use equivalent technologies (HTML local/session storage, pixels/beacons, and server-side tracking that forwards events from our server to a third party). Under EU/EEA law (ePrivacy + GDPR), storing or reading non-essential information on your device, and equivalent server-side tracking that shares your personal data with third parties, requires your consent.
3. Consent model
3.1 Essential (strictly necessary) technologies run without consent — they are required to deliver the service you requested (security, load balancing, session, CSRF, consent state, cart, checkout, fraud prevention).
3.2 All non-essential technologies run only after you opt in via our consent banner. You can accept all, reject all, or choose by category, and you can change or withdraw consent at any time via the "Cookie settings" link. Rejecting non-essential cookies does not affect access to essential functionality.
Measured (2026-08-09): the platform implements three consent categories — necessary, analytics, marketing (ciqra-saas/src/modules/Ciqra.Modules.SiteSecurity/Consent/ConsentCategory.cs:55-57) — with a consent banner (ConsentBannerScript.cs), per-category grant records and a consent hash (ConsentHashing.cs:19-21).
3.2a ⚠️ The limit this consent model leaves for a US visitor — stated rather than covered by the word "global"
Determination of 2026-08-18 · review horizon 6 months (review by 2027-02-18). The model described in §3.1–§3.2 is built to the EU/ePrivacy shape: prior opt-in, by category, withdrawable. That is the stricter posture for a visitor in the EEA, and it is measured. It is not the shape the US comprehensive state privacy statutes use, and this Policy does not claim otherwise: those regimes turn on an opt-out of sale, share and targeted advertising rather than on prior consent, they attach to a business meeting a scope threshold rather than to every operator, and several of them require a recognised opt-out preference signal to be treated as a valid request in its own right — which the platform does not read today (§7, built under
02-09-PLAN.md).⚠️ So a US visitor who never touches the banner is in a different position from an EEA visitor who never touches it, and nothing in §3 said so until this note. Whether CIQRA is in scope for any given state statute is an open question with a named artefact behind it, and the establishment measurement it depends on cannot currently be produced from the platform's own data. Written up in full, with what would settle it and who owns it: US market obligations register §1.2 and §2.2, and Privacy Policy §13.1.
3.3 Server-side tracking does not bypass consent — measured. Where CIQRA or a Merchant uses server-side event forwarding / conversion APIs, that sharing is gated on the same consent. Each server-side destination adapter declares the consent it requires and is not dispatched without it (measured 2026-08-09: Ciqra.Modules.Marketing/Adapters/Ga4MeasurementProtocolAdapter.cs:23 RequiredConsent => ConsentRequirement.Analytics; GoogleAdsEnhancedConversionsAdapter.cs:37 => ConsentRequirement.Advertising; the same RequiredConsent declaration is present on the Meta, Pinterest, Snapchat and server-GTM adapters). Consent state is additionally carried in the payload to the destination (Ga4PayloadBuilder.cs:24-27, GoogleAdsEnhancedConversionsAdapter.cs:80-83).
4. Categories we use
| Category | Purpose | Consent? | Examples / providers |
|---|---|---|---|
| Strictly necessary | Security, session, cart, checkout, load balancing, consent storage, fraud prevention | No (essential) | CIQRA session, CSRF token, Cloudflare, Stripe (checkout/anti-fraud). ⛔ Bot-protection / CAPTCHA is NOT in this row — see §4.2 |
| Bot protection (CAPTCHA) | Distinguishing a human from an automated agent on a protected form | Consent — except where §4.2 establishes an exemption for that specific placement | Google reCAPTCHA v3 (default), Cloudflare Turnstile or hCaptcha, whichever the Merchant configures |
| Functional / preferences | Remember language, theme, region, recently viewed | Consent | CIQRA preference cookies |
| Analytics / performance | Understand usage to improve the Services | Consent | Google Analytics 4 / Google Tag Manager (incl. server-side GA4); Cloudflare Web Analytics ("Insights") — 🔴 injected at the edge, not by the application (§4.2) |
| Advertising / marketing | Measure campaigns, retargeting, conversion tracking (incl. server-side/CAPI) | Consent | Meta Pixel + Conversions API; Google Ads; TikTok; Pinterest; Snapchat |
4.2 Bot protection (CAPTCHA) — CIQRA's ruling on the "strictly necessary" exemption
PA-0371. The question is whether loading a CAPTCHA falls inside the second exception in ePrivacy Art. 5(3) — "strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service" (register 1.4). CIQRA's ruling: for reCAPTCHA v3 as deployed, it does not. The reasoning is set out so that it can be checked rather than taken on trust.
① Art. 5(3) applies at all. The provision governs "the storing of information, or the gaining of access to information already stored, in the terminal equipment". It is written about information, not about cookies, so it reaches a script that reads browser and device state whether or not a cookie is set. Nothing about a CAPTCHA takes it outside the rule; the only question is which way out applies.
② The way out is consent or exemption — not "security", and not legitimate interest. Art. 5(3) offers exactly two exceptions (transmission, and strict necessity for the requested service). It contains no legitimate-interest gateway. GDPR Art. 6 governs what happens to the data after it is collected; it cannot authorise the access to terminal equipment in the first place. An entry reading "basis: security" names a purpose, not a basis — that error was in this set until 2026-08-10 and is corrected in Subprocessor List row 11.
③ The exemption is measured from the USER's side. WP29 Opinion 04/2012 (register 1.6) applies the test from the perspective of the person whose device is accessed: exempt only where the service would not work as that person expects. A visitor who requested a page has not requested a risk score about themselves; the anti-spam benefit accrues to the operator.
④ The one anti-bot exemption a supervisory authority has actually written down is tied to AUTHENTICATION. CNIL délibération n° 2020-091, Art. 5 (register 1.7) exempts "les traceurs destinés à l'authentification auprès d'un service, y compris ceux visant à assurer la sécurité du mécanisme d'authentification, par exemple en limitant les tentatives d'accès robotisées ou inattendues". That is a login exemption. It is not a general anti-spam exemption and it does not reach a contact form.
⑤ Applied to the four placements the platform actually offers (CaptchaConfigVm:
ProtectLogin, ProtectRegister, ProtectContact, ProtectCheckout):
| Placement | Exemption available? | CIQRA's position |
|---|---|---|
| Login | Arguably yes — squarely the CNIL wording: securing an authentication mechanism against robotic attempts | Exempt only if the tracker is confined to the login step and does nothing else |
| Register | Arguably yes, on the same reasoning — account creation is the authentication mechanism being protected | Same confinement condition |
| Contact form | No | Not authentication. Anti-spam on a contact form protects the operator's inbox |
| Checkout | No, as an Art. 5(3) exemption | Payment-fraud controls are a stronger case on the merits, but they are not authentication and not in any authority's exempt list. Where a card scheme or PSD2 SCA mandates a control, that control is argued on its own footing, not on this one |
⑥ And reCAPTCHA v3 specifically weakens even the login case. Three properties, each independent of the placement: it is invisible and continuous, so the access is not confined to the moment of the requested action; it returns a behavioural score rather than a human/bot verdict, which is more processing than the function requires; and the vendor may use what it collects for its own purposes. "Strictly necessary" is a necessity test, and a control that collects more than the function needs fails it at the margin.
🔒 What CIQRA therefore states. Bot protection is treated as requiring consent in this Policy, except on login/registration where the CNIL wording is relied on and the deployment is confined to that step. Three routes preserve the Merchant's protection without relying on an exemption CIQRA does not have: (a) a provider that stores and reads nothing on the device — a vendor claim that must be measured, not accepted, before it is written down anywhere; (b) loading the CAPTCHA only after consent, and only on the page carrying the protected form — which requires the form to remain usable without consent, otherwise the consent is not freely given (GDPR Art. 7(4)); or (c) server-side anti-abuse (rate limiting, honeypots) which touches no terminal equipment and is outside Art. 5(3) altogether.
⑦ A "we measured zero cookies" reading does not exit Art. 5(3). Measured on a live storefront
(2026-08-10): 0 first-party cookies, 0 localStorage entries, window.ciqraConsent undefined — and
recaptcha/api.js loading on the same page. That combination is not a defence. Art. 5(3) is written about
information, not cookies (① above): a script that reads browser and device characteristics to compute a
score is gaining access to information in the terminal equipment whether or not it writes anything back. A
zero-cookie count also measures one moment — reCAPTCHA v3 writes its own state when the score is executed,
which is at interaction, not at page load. 🔑 The correct reading of that measurement is the opposite of
comfortable: no consent surface exists, and third-party scripts are already running.
⑧ A second subject, and it cannot be reached by any consent gate CIQRA writes.
Cloudflare Web Analytics ("Insights") runs on storefront pages. It is injected at the edge: the origin
HTML contains zero occurrences of cloudflareinsights while the browser's document.scripts contains it
(measured 2026-08-10 on /tr and /tr/iletisim). It is analytics, and analytics is not strictly
necessary (register 1.6), so it needs consent.
🔴 The structural point matters more than the script. A consent mechanism that lives in the
application cannot gate something injected above the application. Even a perfect in-app consent
implementation would leave this beacon running. Turning it off is a Cloudflare panel setting, not a code
change — so the fix belongs to whoever administers the zone, and the consent design must say which
third-party surfaces it does and does not control.
⚠️ How this was found is part of the record: an HTML census reported it absent, and that census was
right about HTML and wrong about the page. A census can only find what its surface can carry.
⑩ One of the three channels has since closed — recorded so the remaining two are not overstated.
The siteverify call used to send the visitor's IP address to Google server-side, outside anything a
browser could show or a consent banner could gate. Re-measured 2026-08-10: the request body carries
secret and response only, and the remoteIp parameter has been removed from the call chain rather
than left unread (CaptchaVerifiers.cs:14-36). 🔑 A parameter that is merely ignored is a switch someone
reconnects later; a parameter that is gone is a guarantee the compiler keeps. What remains under §4.2 is the
script tag and the challenge — two channels, not three.
⑨ The provider decision is fixed, so only one exit remains. CIQRA has decided to keep reCAPTCHA v3 (owner decision, 2026-08-08). This Policy does not reopen that decision; it records its consequence. With the provider fixed, route (a) below — change to a captcha that touches nothing on the device — is closed, and route (c) does not cover the placements that need a captcha. 🔒 Therefore consent is the operative route, and the login/registration exemption in ④ is the only part of the surface that may run without it, and only while confined to that step.
⑪ A refused consent must not cost the visitor the form — and that is a rule, not a preference. The obvious first step, suppressing the provider script until consent is given, has a consequence that has to be designed for rather than discovered: a visitor who refuses then submits a form with no captcha token, and a server that requires one rejects the submission. 🔴 That outcome is not merely poor service, it invalidates the consent it was meant to collect. Consent is valid only if freely given (Art. 4(11)), and Art. 7(4) directs that utmost account be taken of whether access is made conditional on consent to processing that is not necessary. If refusing costs the visitor the ability to contact the store, the "yes" of everyone who accepted is not free either — so the design would end with no valid consent and a broken form, which is worse than today in both directions at once.
🔒 CIQRA's position, therefore: on a surface where the captcha is not exempt under ④, the form must remain usable when consent is refused, with abuse handled by means that touch no terminal equipment — rate limiting, honeypots, server-side heuristics. The captcha requirement itself becomes conditional on consent; it cannot be a gate the visitor has no lawful way through. 🔑 The test is the same one that separates a return from a withdrawal elsewhere in this set: ask whether the other side can say no. A consent that cannot be refused without loss is not a consent, in the same way that a return the merchant can decline is not a right of withdrawal.
⚠️ This clause states a rule and a position; it does not claim a mechanism. No consent gate is wired to bot protection today — see §4.1 and PA-0371.
4.1 The itemised cookie table — mechanism measured, contents not
A live, itemised cookie table — each cookie's name, provider, purpose, first/third-party type, and duration — is shown in the "Cookie settings" panel.
The mechanism exists (measured 2026-08-09): ConsentCookieEntry carries exactly the promised fields — Name, Provider, Purpose, Duration, SortOrder (Consent/ConsentCookieEntry.cs:24,27,30,33,36); a reconciler keeps platform-owned rows current (ConsentInventoryReconciler.cs); and for rows the platform itself declares, the code — not the merchant — owns the name, category and duration (ConsentCookieEntry.cs:41-43, on the reasoning that a wrongly-categorised marketing cookie is the legally dangerous error). Categories are seeded by migration (20260801165134_SeedConsentCategories).
🔴 CIQRA's determination: this Policy deliberately does not print cookie durations, because it promises a live table instead. That promise is only kept if the table is populated in production. Whether it is populated could not be measured from source — it is runtime tenant data, and this reconciliation had no production access. The open question is not "should durations be written into this document" but "is the promised table full". 🔴 Answered, and badly, on 2026-08-10:
consent_settingsholds 0 rows, i.e. the consent surface is not rendered at all. A panel that is never printed cannot show a table, whatever the inventory behind it contains. ⚠️ Precision matters here:consent_settingsandsite_security_consent_cookiesare different tables, and the second is still unmeasured — so this note records that the promise is not kept today, not that the inventory is empty. Both readings must be taken before this Policy's live-table promise can be relied on. PA-0371.Three platform-set cookie lifetimes are known from source and should appear in that table once populated: consent state 365 days (
ConsentStorefrontEndpoints.cs:34), language preference 365 days (LanguageResolutionMiddleware.cs:34), guest chat identifier 180 days (ChatEndpointSupport.cs:65).
5. Third-party tracking specifics
-
Google Consent Mode v2 — measured as implemented. Consent state is passed via
ad_storage,ad_user_data,ad_personalizationandanalytics_storage, mapped from the marketing and analytics categories, and the default state isdeniedbefore any choice is made (measured 2026-08-09:ciqra-saas/src/Ciqra.Api/wwwroot/theme/storefront.js:2305-2308, defaults at:2319). -
Google Analytics 4 / Google Tag Manager — analytics; loads with storage only with analytics consent; IP/data handling per Google's controls and Consent Mode state.
-
Meta Pixel & Conversions API (CAPI) — advertising measurement. Both the browser pixel and the server-side CAPI forwarding run only with advertising consent (§3.3, measured). Client and server events are deduplicated via a shared event ID.
CIQRA's determination: CAPI forwarding may share hashed identifiers (email/phone) plus IP and event data with Meta in the US. The transfer is disclosed in the Subprocessor List §5 and relies on SCCs plus consent, and CIQRA's determination is that the combination is the required basis: consent under GDPR Art. 6(1)(a) for the advertising purpose, plus an Art. 46(2)(c) SCC transfer mechanism for the US leg (Legal Basis Register rows 1.1–1.2). Where either is missing for a destination, the event is not forwarded.
-
TikTok / Pinterest / Snapchat / other ad platforms — advertising; consent-gated (browser + any server-side events).
-
Controller allocation & joint controllership. On a Merchant's Storefront, the Merchant is the controller for its own analytics/ad-tech and is responsible for its consent banner, its DPAs with Google/Meta, and its lawful basis; CIQRA provides the integration and consent gating.
CIQRA's determination: for certain ad-platform collection (notably Meta Pixel), the ad platform and the site operator may be joint controllers for the collection/transmission stage under Fashion ID (C-40/17). CIQRA has not concluded whether, as the party supplying and configuring the integration, it falls inside or outside that joint controllership. This is unresolved, and it is the single most consequential open question in this document — it determines whether CIQRA needs an Art. 26 joint-controller arrangement with ad platforms, or only a processor position toward Merchants.
Transfers to these providers outside the EEA rely on the safeguards in the Privacy Policy §7 (SCCs / adequacy).
6. Managing cookies
- Use our "Cookie settings" control to change categories at any time.
- Most browsers let you block/delete cookies; blocking essential cookies may break the Services.
7. Global Privacy Control / Do Not Track — ✅ GPC implemented 2026-08-19
What the browser sends and what the store does with it. If your browser sends the Global Privacy Control signal (Sec-GPC: 1), the store records a do-not-sell-or-share decision for you and remembers it, so you do not have to send it again to stay opted out. This happens on every store on the platform, whether or not that merchant shows a cookie banner: the banner is a merchant's choice about whether to ask you, and it cannot cancel an answer you gave without being asked.
⚠️ What it switches off, and what it leaves running — stated because "honoured" on its own would be read as more than it is. The decision withholds the categories a store declares to be a sale or share — the advertising and cross-context categories — and while it stands, an advertising destination is not contacted for you. It does not switch off the store's own first-party measurement of how many people used the site, which counts visits without identifying anyone and is therefore neither a sale nor a share. If you want that stopped too, decline the analytics category in the cookie settings; that is a separate control and it is yours.
Measured 2026-08-19, replacing the 2026-08-09 finding of absence. The signal is read in exactly one place, following the W3C Global Privacy Control specification: only the exact value 1 counts, and any other value is processed as though the header had not been sent — so a stray or malformed value can neither create an opt-out you did not ask for nor cancel one you did. The decision is stored through the same path a banner click uses, so a store keeps one record of what you allowed rather than two that can disagree. Each store answers for itself at its own address, and publishes a machine-readable statement of this posture at /.well-known/gpc.json.
CIQRA's determination of 2026-08-19 · review horizon 3 months (review by 2026-11-18). This section previously recorded a launch-blocking inconsistency: the 00-README and the Privacy Policy described GPC honouring as part of CIQRA's CCPA/CPRA posture while the header was read nowhere in the platform. That inconsistency is closed by building the facility, not by softening the sentence. A build check (
GPCREADERintools/legal-gate/legalgate.py) fails if the reader is removed while the US market obligations register §2.5 still records the commitment, so this section cannot outlive the code beneath it. ⚠️ The limit, kept rather than dropped: the horizon is three months, not six, because the retrieved legal backing is one state's instrument; and Do Not Track is still not implemented — DNT is a different, largely abandoned signal, it is not read, and nothing in this section should be taken to say otherwise.
8. Changes
We may update this Policy; the "last updated" date reflects the latest version, and material changes are notified via the banner.
Provision register (this document)
| Provision | Basis | Where |
|---|---|---|
| Merchant-as-controller split | (B) allocation untested against authority view | §1 |
| server-side tracking gated on consent | (A) measured — RequiredConsent per adapter | §3.3 |
| Consent Mode v2 | (A) measured — signals + denied default | §5 |
| GA4/GTM consent load | (A) measured via §3.3 / §5 | §5 |
| Meta CAPI | (B) hashed-identifier transfer adequacy unassessed | §5 |
| joint controllership (Fashion ID) | (B) unresolved; flagged as the key open question | §5 |
| EEA transfers | (B) folded into §5 and Privacy Policy §7 | §5 |
| GPC honoured where required | ✅ (A) measured PRESENT (2026-08-19) — read, persisted, enforced; guarded by GPCREADER. Was measured ABSENT on 2026-08-09; closed by building it | §7 |
| Do Not Track | 🔴 (A) measured ABSENT — DNT is a separate signal and is not read. Kept as its own row so §7's ✅ cannot be read as covering it | §7 |
| (not previously flagged) | (A) measured — consent categories + banner | §3.2 |
| (not previously flagged) | (B) live cookie table promised; population unverified | §4.1 |
Composition: 6 measured facts · 5 declared positions · 0 withdrawn claims. ✅ Recounted 2026-08-19: the withdrawn GPC claim became a measured present fact when the facility was built, and Do Not Track — previously folded into that row — is now its own measured absent fact rather than a position. Both moved out of the "declared" column because somebody measured them, which is the only honest way for that number to fall.
End of Cookie Policy . See: Privacy Policy · Subprocessor List.