How CookieHawk tests websites
Version 1.2, last reviewed on 22 August 2026. The texts are based on section 3-15 of Norway’s Electronic Communications Act, the GDPR and guidance from the Norwegian Data Protection Authority, with internal quality assurance; they are not a legal opinion. Questions: kontakt@cookiehawk.com.
1. What the test is
The test is an automated technical spot check, not a legal conclusion. An isolated Chromium context (Playwright) with language nb-NO, time zone Europe/Oslo and a 1366 × 900 viewport visits the homepage and up to three public subpages in each state. The traffic’s IP country is determined by the scanner server (EEA). The test can therefore produce up to 12 page loads. It does not log in or fill out forms.
2. Three states
- Before a choice: the page loads without any clicks. All contacts and storage here occur before the visitor has made a decision.
- After “Reject all”: a new, empty browser. The scanner finds the banner, selects rejection in the first layer where available, and continues to subpages.
- After “Accept all”: a new, empty browser with acceptance. Used as a reference for what the website can send.
Each state runs in a separate browser context, so no cookies or storage carry over between states. Activity is attributed to a state based on when the request was actually sent relative to the click.
3. When “Reject all” is considered confirmed
The scanner first tries a visible rejection button in the banner’s first layer. If none exists, it opens settings and tries rejection in the second layer. The absence of a first-layer rejection button is reported as a separate observation, but does not prevent technical confirmation of rejection.
Technical confirmation is recorded when the CMP’s own API (such as Cookiebot, OneTrust, TCF, Usercentrics or Google Consent Mode) reports rejection, when a click on a known CMP button or second-layer button closes the visible banner, or, if the banner was not visible, when a consent-related cookie or storage value changes. A click based solely on text heuristics requires both a closed banner and a state change. If the CMP API reports a different status (such as “granted”), the choice is not confirmed. The strength of confirmation varies and does not by itself show that all purposes and vendors were rejected. Unconfirmed clicks are not used as a basis for observations “after confirmed rejection”.
4. What we record
- Network requests with hostname, method, resource type and timestamp. URLs are stored up to 300 characters; known sensitive parameter names, email addresses, phone numbers, long values and certain token patterns are masked. Other parts of the path and query may remain and may contain personal data. Up to 900 requests are recorded per state.
- Set-Cookie and cookie names, domain, path and declared lifetime, but not cookie values.
- Up to 100 key names from
localStorage/sessionStorageon the last page visited. - Observed consent signals (Consent Mode status, TCF string present/absent, CMP API).
- Likely technical initiator: whether a call came from a Tag Manager container, a plugin, an embedded element or the script itself, based on the browser’s initiator chain.
- When screenshots are enabled: one compressed final screenshot per state, for context.
5. Classification and priority
Services are classified against a versioned database of known tracking, analytics and advertising tools (with category and source). “Technical priority” is very high, high, medium, low or information, and indicates how much follow-up an observation needs. Each observation also has a confidence level: high, medium, low or inconclusive. Priority is a technical sorting mechanism and does not determine the legal assessment. Contact with a third party alone does not show that information was stored on or accessed from the device, or that personal data was processed.
Examples of assessments we make to avoid overstating findings: cookieless Consent Mode signals with denied status (gcs=G100) are classified as information, not a prioritised observation. Functional embeds (maps, video, chat) visible to visitors are assessed by what they actually set, not by category alone. When the scanner finds no banner while observing services often used for consent-based purposes, it creates a separate observation (“no banner found”). The result needs manual review because the banner may depend on geography or timing, or detection may have failed.
6. Known limitations
- The result applies to one point in time, the outbound IP address/geolocation stated in the report (scanner server in the EEA; language and time zone alone do not make the test geographically Norwegian), and the pages visited. A/B tests, login, language, network errors, delayed calls and the scanner’s resource limits may affect the outcome.
- The banner heuristics recognise Norwegian Bokmål, Nynorsk, Swedish and English banner text; other languages may produce “no banner found” even when a banner exists.
- We can observe some client calls to known server endpoints (such as server-side Tag Manager), but not subsequent processing behind an endpoint.
- Our banner holds back known tracking tools that load dynamically; scripts embedded directly in HTML must be marked by the website owner. A banner cannot delete third-party cookies. We therefore verify each website individually.
- Reports are generated automatically and may contain errors. A report is labelled manually reviewed only when the review is documented; otherwise it must state that it has not been manually reviewed. We correct verified errors.
7. Data, deletion and right of reply
Temporary browser profiles and raw artefacts are deleted after analysis. Final reports are retained under the retention schedule (in Norwegian) and shared confidentially with the requester. Affected website owners and named suppliers can request corrections or submit a reply via kontakt@cookiehawk.com; we respond within 5 working days.
8. The homepage figures
Market figures are published only with a frozen dataset, scanner version, date, definitions and documented calculation. The homepage figures come from calibration run v7 (scanner cmp-scan 0.1.0, run on 21 August 2026 from 07:51 to 08:14 Norwegian time, dagbladet.no rescanned that day), frozen on 21 August 2026 as 60 JSON files with sha256 checksums and a per-website table (data/KALIBRERING-V7-FRYST.md). The figures are calculated programmatically from the files using these definitions:
- 59 tested: 60 Norwegian websites (banking, media, e-commerce, associations, property, clinics) were attempted; one (an IDN domain with a certificate error) did not complete the “before a choice” state and is excluded from all counts.
- 50 with activity before a choice: at least one observation in the “before a choice” state with very high, high or medium technical priority (types
pre_consent_tracker/pre_consent_cookies; ambiguous cookies and cookieless Consent Mode pings do not count). - 31 with activity after confirmed rejection: rejection was technically confirmed and at least one observation in that state had very high, high or medium priority. Rejection was clicked on 47 websites and confirmed on 44.
- 10 of 52 banners without first-layer rejection: 52 websites had a recognised consent banner; on 10 the scanner found no rejection option in the first layer.
- 8 without prioritised observations: no observation with very high, high or medium priority (low/information may occur).
The sample is not representative of all Norwegian websites. The dataset (with masked URLs) and calculation script are available for review on request.