An anonymised case study of a video platform that sells “GDPR by design”: what its website does to the people who visit it, what its player does to the people who watch, and which risks end up with the customer

All findings are based on requests observed in a standard browser, on the vendor’s own website and on the public website of one of its customers, a public broadcaster. The vendor, the customer and all identifiers have been anonymised; the vendor’s claims are paraphrased.

Management introduction: the risks that land on the customer

The verdict: A European online video platform markets itself to public-sector buyers as sovereign, and privacy-first: GDPR by design, consent management built in, data minimisation, viewer data kept in the EU, and a player that in its cookieless mode needs no consent at all. We tested those claims in the two places a buyer’s own colleagues and own audience meet the vendor: its website, and its player embedded on a customer’s site. On the website a recorded refusal is ignored and thirteen tracking cookies are set. In the player, “cookieless” is true but everything built on it is not: personal data and device characteristics are sent every few seconds, through a US cloud provider, identically after a tracking refusal the player has been told about.

Why this is a report about the customer, not the vendor. A vendor’s compliance failure on its own website is the vendor’s problem. What makes this case worth documenting is that every failure we found is structured so that the consequence lands on the customer, who is the data controller towards its own visitors and viewers, and who selected the vendor on the strength of these claims. Concretely:

●  The customer’s compliance record is wrong. Its processing register, its data protection impact assessment and its privacy statement will say what the vendor said: no US processors, no tracking without consent, viewer data in the EU. None of it holds. At an audit, a data-subject request or a complaint, it is the customer’s name on the finding.

●  The customer’s own website breaks its own promises. We refused consent on a customer’s site. The customer did everything a controller can do: it told the player. The player dropped one identifier and kept reporting IP address, device characteristics and viewing behaviour. The customer’s diligence became the customer’s liability.

●  The customer’s staff are tracked while evaluating the vendor. The people who read the vendor’s privacy page during procurement are session-recorded, resolved to their organisation and, if they request a demo, filed in a CRM in a North American data centre, whether or not they refused cookies.

●  The customer’s figures cannot be trusted. Audience and advertising numbers come from a beacon in the viewer’s browser that any content blocker suppresses and that anyone can forge. The customer reports those numbers to its board, its funders and its advertisers, and settles advertising on them, with no way to tell real from missing from invented.

●  The customer’s viewers are exposed without recourse. The viewer has no contract and no dashboard. Their IP address, device and viewing behaviour are decrypted by a US company on every request, while the broadcaster they trust tells them their data stays in Europe.

Part A of this report covers the website: what happens before and after a visitor refuses cookies. Part B covers the player: what it sends about every viewer, why “cookieless” does not end the consent question, and why measuring in the browser is the wrong design regardless of compliance. A joint conclusion and a set of checks follow. Nothing here required more than a browser and half an hour.

Part A. The website

The vendor’s website is the system the vendor controls completely and that every prospect touches first. It is also where the vendor’s privacy claims are published. If those claims hold anywhere, they should hold here.

A1. Approach

For the website we used a standard desktop browser (Safari) and its built-in developer tools, and nothing else. The sequence:

1. Clear all browsing history and website data.
2. Load the vendor’s homepage. The consent banner appears.
3. Refuse all non-essential cookies in the banner.
4. Reload the page once.
5. Read the Network tab (which requests went out), the browser’s website data overview (which domains left data behind) and the Storage tab (which cookies, databases and storage entries exist).

All observations were made on 11 September 2026 between 19:30 and 19:45 local time. Timestamps in this report are derived from cookie expiry dates minus the documented lifetime of each cookie, and are accurate to the second. One correction was needed: the browser displays expiry in local time while lifetimes are added in UTC, so cookies expiring after the switch to winter time display one hour early. All times below are corrected to local summer time. Raw data is in the appendices, anonymised.

A2. The claim

The vendor’s sovereignty page, which also serves as its privacy pitch, makes the following commitments in our paraphrase:

• GDPR by design. Built privacy-first, with consent management, data minimisation and the right to erasure built in.
• Governance. A designated data protection officer and a standard data processing agreement available to every customer.
• No leakage to US analytics. Viewing data is not exported to US analytics platforms unless the customer configures it.
• Documentation for public tenders. The page addresses public-sector buyers directly and lists the questions the “legal team will ask”, including whether the vendor is GDPR compliant.

A3. Findings

A3.1 Before any choice was made

The page was loaded at 19:34:32. The refusal was clicked at 19:34:34. In the two seconds in between, the site set the Google Ads conversion linker cookie, valid ninety days. It was not waiting for an answer; it fired on page load, as it would for every visitor.

●  Finding: the ePrivacy rules require consent before a non-essential cookie is placed, not after. Whatever the visitor later chooses, the identifier that links this browser to Google’s advertising network already exists. The banner is answered after the fact. This also explains the contact with doubleclick.net in Appendix B.

A3.2 The refusal was recorded

The consent tool (a European product, self-hosted) stores the visitor’s choice in first-party cookies. After we refused, those read: statistics deny, marketing deny, preferences deny, functional allow, banner dismissed, all set at 19:34:34 with a one-year lifetime.

●  Finding: the consent layer itself works. It showed a banner, offered a refusal, and stored it. This matters for what follows: the vendor cannot argue that the refusal was lost. Its own tool says otherwise.

A3.3 What fired after the refusal

We reloaded the page at 19:42:38, eight minutes after the refusal. The Network tab then lists requests that actually went over the network, with a payload size and a response time, so not served from cache:

The browser’s website data overview afterwards lists some twenty third-party domains with cached responses or stored connection data, including two that did not appear in the network log: doubleclick.net, Google’s advertising network, and a HubSpot content domain carrying the “na1” suffix, a second confirmation that the vendor’s CRM runs in HubSpot’s North American data centre.

One nuance. Google’s consent mode sends “cookieless pings” when consent is denied and describes them as non-personal. They still carry the visitor’s IP address and go to Google. For LinkedIn and HubSpot no such mechanism exists: those beacons simply should not fire after a refusal.

●  Finding: after a recorded refusal, the visitor’s IP address, browser fingerprint and page view are reported to Google, LinkedIn and HubSpot. The consent tool has categories for statistics and marketing and the visitor denied both; the tags in those categories fired anyway.

A3.4 What was set after the refusal

The Storage tab lists the cookies on the vendor’s own domain after the reload. Excluding the consent tool’s own cookies and three language cookies, thirteen tracking cookies are present. One was set on page load before the choice (A3.1). The Hotjar session cookie was set at 19:35:16, 42 seconds after the refusal: session recording started the moment the visitor said no. The remaining eleven were set on the reload at 19:42:38, eight minutes after the refusal:

In addition, the browser holds an IndexedDB database named after HubSpot’s call-to-action module, and local storage and session storage entries for two HubSpot domains and the vendor’s own domain.

●  Finding: the refusal changed nothing. The same identifiers that would be set after an “accept” are set after a “deny”, with the same lifetimes. A cookie valid for thirteen months, placed eight minutes after the visitor declined it, is not a configuration slip at the margin; it is the tag configuration working exactly as designed, with the consent tool disconnected from it.

A3.5 Session recording and visitor identification

Two of the tools deserve attention beyond the cookie question, because of what they do rather than where they run.

Hotjar records sessions: every mouse movement, hover, scroll, click and form interaction of an individual visitor, replayable as video. It is the most intrusive form of web analytics in common use. The persistent user cookie, valid one year, links a visitor’s recordings across visits. Hotjar is an EU legal entity, which is why it is marked amber and not red; that does not make session recording without consent acceptable. Session recording is one of the most privacy invasive services imaginable. Note that Hotjar runs on a US owned cloud service.

HubSpot resolves visitors to the organisation they work for, using their IP address, and attaches page views to a contact record once a visitor fills in any form. Combined with the session recordings, the vendor can see which organisation is reading its privacy and sovereignty claims and watch, second by second, how that visitor reads them. For a vendor whose prospects are public bodies and their legal teams, that is a considerable amount of intelligence gathered from people who have explicitly declined to be tracked.

●  Finding: session recording and organisation-level visitor identification are lawful with valid consent and a proper legal basis. They are not what “data minimisation” means, and they were running after a refusal.

A3.6 What the absence of third-party cookies does not prove

The browser data overview shows cookies only on the vendor’s own domain, not on the Google, HubSpot or LinkedIn domains. That is not a sign of restraint. Safari blocks third-party cookies by default and has done so for years. The tracking industry adapted by setting cookies on the first-party domain instead, which is exactly what section A3.4 shows. A vendor that pointed to the absence of third-party cookies as evidence of compliance would be pointing at Apple’s work, not its own.

A3.7 Overview

A4. What was not established

• Which consent categories the vendor assigned to each tag in its tag manager. The outcome is the same whether the tags were miscategorised, exempted or never connected to the consent signal; the distinction would only matter for the vendor’s internal root cause analysis.
• Whether Google’s consent mode was actually implemented. If it was, the Google requests after refusal are the “cookieless pings” Google permits itself; the Google cookies set at 19:42:38 show that at minimum the cookie side of consent mode was not in effect.
• Behaviour in other browsers. Safari blocks third-party cookies; Chrome without extensions does not. The first-party findings in this report would be identical; the third-party picture in Chrome would be worse.
• Whether any of the trackers are declared in the vendor’s cookie policy, and how. We looked at behaviour, not at the policy text.

Part B. The player

The player is the product. It runs on the customer’s website, in front of the customer’s audience, under the customer’s privacy statement. Whatever it sends, it sends in the customer’s name.

B1. Approach

Part A examined what the vendor’s own website does to its visitors. Part B examines the vendor’s product: the video player embedded on its customers’ websites, and the analytics that player sends home. The customer whose site we used is a public broadcaster; we watched its live television stream. We used a standard desktop browser (Safari) and its developer tools. One practical note that turned out to be a finding in itself: the analytics requests were invisible until we disabled our content blocker.

The sequence:

1. Open the broadcaster’s live stream with browsing data intact; capture a playback beacon and an advertising beacon.
2. Clear all browsing data, return to the broadcaster’s site, refuse all cookies in the broadcaster’s banner, open the same stream; capture a playback beacon.
3. Without clearing anything, open the same stream in a new window; capture a playback beacon.
4. Compare the beacons, their identifiers and their response headers.

We did not send any data to the vendor’s endpoint ourselves. The design weaknesses in section B4 follow from what the beacon lacks, which can be read from the request; demonstrating them would mean interfering with a live system, which we do not do.

B2. The claim

Across its sovereignty page, help centre and knowledge base, the vendor makes the following commitments in our paraphrase:

• Viewer data in the EU. Viewing behaviour, playback analytics and audience statistics are stored and processed within EU infrastructure; nothing is exported to US analytics platforms unless the customer configures it.
• GDPR by design. Privacy-first, with consent management, data minimisation and the right to erasure built in.
• A cookieless player that needs no consent. The player has three cookie modes. In the restricted mode no cookies are placed, each session counts as a unique viewer, and statistics are still collected. A knowledge-base article aimed at government organisations tells them that a player of this kind does not require the visitor’s consent.
• Documented data flows. The vendor’s own plugin documentation states that loading the player transmits the visitor’s IP address, user agent, referrer and page URL to the vendor, in order to serve the clip, apply geo and language rules, and record analytics.

The last point matters: the vendor describes the data flows accurately. The dispute is not about what is sent but about what the vendor concludes from it.

B3. Findings: what the player sends

B3.1 The beacon

During playback the player sends a GET request to a stats hostname of the vendor, disguised as an image and answered with a 43-byte GIF: the classic tracking-pixel pattern. It repeats every few seconds for as long as the viewer watches; the beacons we captured were numbers 24, 32 and 34 of their sessions. The query string carries:

Implicitly, without appearing in the URL, every beacon also carries the viewer’s IP address, the full user-agent string (operating system and browser version), the browser language and the address of the page the player is embedded on. The full anonymised requests are in Appendix D.

B3.2 Personal data

Three grounds, each sufficient on its own. The IP address is personal data (Court of Justice, Breyer). Identifiers that tie a device’s requests together within a session are online identifiers in the sense of Recital 30 of the GDPR. And session plus programme plus timestamps plus duration is a behavioural record of an individual viewer of a public broadcaster. That the data is pseudonymous does not change this; pseudonymous data is personal data.

●  Finding: every beacon is personal data several times over, and the vendor’s own documentation lists the implicit fields.

B3.3 Fingerprinting attributes

Precision matters here. This is not active fingerprinting of the canvas or font-enumeration kind. It is the collection of passive device characteristics, screen resolution with pixel ratio, user agent, language and IP address, which together make a device fairly distinctive. The European Data Protection Board treats the collection of device characteristics to recognise a device as subject to the same consent requirement as cookies. The accurate description is that the player collects fingerprinting attributes; whether the vendor uses them to recognise devices we cannot see from the outside.

●  Finding: device characteristics with no playback purpose are read and sent. What they are used for is not established. This is not data minimisation.

B3.4 The test with consent refused

We cleared the browser completely, returned to the broadcaster’s website, refused all cookies in the broadcaster’s own banner, and started the same live stream. The player template name now carried the suffix “noconsent”: the broadcaster passes the refusal to the player, as a diligent customer should. The viewer identifier was new. We then opened the same stream in a new window without clearing anything, and the identifier was new again. In this mode the identifier is per session, not per device. That is consistent with the vendor’s documentation, and it means the word “cookieless” is, in this mode, accurate.

Everything else in the beacon was unchanged, parameter for parameter: session identifier and sequence numbers, timestamp, screen resolution with pixel ratio, programme, time in session, and implicitly IP address, user agent and language, to the same endpoint.

●  Finding: the player is cookieless when told there is no consent, and it says so honestly.

●  Finding: the consent signal reaches the player and changes nothing about what is collected, except the lifetime of one identifier.

B3.5 Why cookieless is not consent-free

The vendor’s conclusion, that no consent is needed because no cookie is set, does not follow, for three independent reasons.

• The ePrivacy rule is about the device, not about cookies. It covers storing information on, or gaining access to information in, the user’s terminal equipment. Reading the screen resolution and pixel ratio through JavaScript and sending them to a server is the textbook example of such access used by the Article 29 Working Party in 2014 and by the European Data Protection Board in 2023. Cookieless does not mean read-less.
• The GDPR applies regardless. IP address, user agent, language and viewing behaviour tied together by a session identifier are personal data and need a legal basis. The audience-measurement exemption that some regulators allow is conditional: first-party, no sharing with third parties, data stays in the EU, no cross-site use. This data goes cross-site to the vendor’s domain and passes through a US cloud provider.
• The vendor knows the flows. Its plugin documentation lists IP address, user agent, referrer and page URL as transmitted on load. Its own website’s privacy statement acknowledges transfers to Google in the United States. The data flows are described accurately and the legal conclusion drawn from them is wrong, and it is sold to public bodies as certainty.

●  Finding: “no consent needed” is a legal position the vendor has chosen, presented to customers as a property of the technology. The customer who relies on it, and passes the refusal to a player that ignores it, is the one exposed.

B3.6 On the wire

A reader may ask whether data carried in a URL is readable by others on the internet. It is not: the beacon travels over TLS, which encrypts everything after the host name. What is true is narrower and more precise. The party that terminates TLS reads the full URL. Web servers and CDNs log the request line including its query string by default, so each viewer’s IP address, programme, timestamp and device characteristics most likely sit in access logs at the edge and at the origin for whatever retention period applies there; carrying personal data in GET parameters rather than a request body has been considered poor practice for two decades for exactly this reason. Networks that inspect TLS on their own devices, as many employers and schools do, can read the query string as well. And the tracking pixel is returned with a ten-year cache lifetime, so each unique beacon URL, with what was watched and when, may remain in the browser’s disk cache long after the session.

B3.7 The route

The response headers show every beacon arriving at an Amazon CloudFront edge in the EU, as a cache miss, and being forwarded to an origin that identifies itself as nginx 1.14.0 on Ubuntu. The party that terminates TLS, and therefore reads every beacon in clear text, is Amazon. The infrastructure side of this is covered in the companion report on sovereignty; here it matters because it is what disqualifies the audience-measurement exemption in B3.5.

●  Finding: viewer data promised to stay “within EU infrastructure” is decrypted by a US legal entity on every request, and handled at the origin by software that has not received security updates for years.

B3.8 Advertising measurement

Before we cleared the browser, the same player also sent an advertising event: a pre-roll quartile report (25% viewed) with the advertisement identifier, the ad-unit code and the host name of the embedding page sent explicitly. The platform measures advertising exposure per viewer over the same unauthenticated channel as playback. That is relevant to section B4, because advertising figures are what the broadcaster settles with its advertisers.

B3.9 Overview

B4. Beyond privacy: why client-side analytics is the wrong design

The findings above are about compliance. This section is about engineering, and it applies even to a vendor that fixed every compliance issue tomorrow. The vendor measures its customers’ audiences by having each viewer’s browser report to a public endpoint. That choice has two consequences that no configuration can remove.

B4.1 It is blind to a growing share of the audience

We could not see the analytics requests until we disabled our content blocker: the vendor’s stats hostname is on at least one widely used blocklist. Every viewer with such a blocker watches the broadcast and never appears in the statistics. Content blockers are installed by a substantial and growing share of desktop users, and tracker blocking is increasingly built into browsers by default rather than added as an extension. The share of the audience that is invisible differs by platform and demographic, which makes it worse: the blind spot is not a uniform discount that can be corrected for, it is a bias. Younger, more technical and more privacy-conscious viewers are systematically under-counted.

●  Consequence: the reach figures the broadcaster reports to its board, its funders and its advertisers exclude an unknown and non-random part of the real audience. The vendor’s own platform-wide statistics have the same hole.

B4.2 It trusts the client

The beacon is a plain GET request to a public hostname with its parameters in the URL. It carries no signature, no token, no nonce, no server-issued session secret. Nothing in it proves that a real player on a real page sent it. Anyone who can read a URL in a browser’s developer tools, which is anyone, can reproduce it with any values, from any machine, at any rate. Without sending a single request ourselves, the following is evident from the request format:

• Inflation. A script can report thousands of viewers for a programme, each with a fresh session identifier, a plausible screen size and a rotating IP address. The programme becomes the most-watched item on the platform.
• Fabrication. The customer, programme title and clip identifier are free parameters. Statistics can be generated for programmes that do not exist, and for customers that do not exist, and they will be ingested like any other.
• Advertising fraud. Section B3.8 shows that pre-roll quartile events travel over the same channel. Advertisement views and completions can be forged at will, which puts the figures the broadcaster settles with its advertisers, and the vendor’s own ad-serving reports, on the same footing as the viewer counts.
• Pollution. Beyond forged but plausible data, the free-text fields accept anything. Enough garbage, or garbage shaped to confuse parsers and dashboards, and real data becomes uninterpretable, or the analytics pipeline fails. Free-text fields that end up rendered in a dashboard are also a classic injection vector; we did not test this and do not need to in order to note the exposure.
• Denial of service. An endpoint that accepts unauthenticated requests from the whole internet and forwards each one to an origin (every beacon we captured was a cache miss) can be flooded. The origin is a single out-of-support web server behind a CDN that does not filter.

None of this requires skill or resources. It requires a browser, a text editor and intent. Competitors, disgruntled parties, bored teenagers and automated crawlers all qualify, and the last group does it by accident every day: headless browsers and scrapers execute the player script and are counted as viewers.

●  Consequence: the customer cannot know whether the numbers in its dashboard are real, and neither can the vendor. This is also a compliance point: the GDPR requires personal data to be processed in a way that ensures its integrity (Article 5(1)(f)), and a collector that accepts anything from anyone does not.

B5. What was not established

• Whether the viewer identifier persists across sessions when consent is given. In the no-consent mode it does not; we did not repeat the new-window test in consented mode. The vendor’s documentation says it does, via a cookie, which with valid consent is unobjectionable.
• What else the “noconsent” player configuration changes. It may switch off advertising or other components; the analytics beacon was unchanged.
• What the vendor does with the device characteristics it collects, and how long beacons and access logs are retained.
• Whether the endpoint applies any server-side validation, rate limiting or anomaly detection. Nothing in the request suggests it, and every beacon was forwarded to the origin, but we did not test it and will not.
• Which blocklists include the stats hostname. At least one widely used one does; we did not survey them.

Conclusion: one pattern, two surfaces: privacy washing.

Privacy washing is the display of the symbols of data protection, a banner, a badge, a policy, a reassuring technical word, without the substance behind them. Its harm is not abstract. It devalues the compliance work of vendors who do it properly, and it transfers risk to customers and viewers who take the symbols at face value. Across the website and the player, this vendor shows the same pattern five times:

1. The symbol works; the substance does not. On the website, the consent banner records a refusal and the tags fire anyway: a banner wired to nothing. In the player, the word “cookieless” is technically true and is presented as the end of the consent question, while the device is read, personal data is sent and the data leaves the EU. In both cases the visible artefact is real and the behaviour behind it is unchanged.

2. The vendor knows the subject. The same organisation explains data minimisation, consent categories and the right to erasure to its prospects, documents its own player’s data flows accurately, and invites public-sector legal teams to ask hard questions. A company that writes those texts employs people who know what a consent signal is. Wiring a tag manager to a consent tool is an afternoon’s work; drawing the right legal conclusion from one’s own documentation is a matter of reading it. Neither was done.

3. The rules broken are the clearest ones. Prior consent for non-essential storage and device access, and honouring a refusal, have been settled across the EU for over a decade, confirmed by the Court of Justice, spelled out by the European Data Protection Board and enforced by national regulators in hundreds of decisions. There is no interpretation under which a thirteen-month analytics cookie may follow a “deny”, or under which reading a device and exporting the result is exempt because no cookie was written.

4. Every consequence lands on the customer. The customer is the controller. Its register, its impact assessment and its privacy statement repeat the vendor’s claims and are wrong. Its website, through the embedded player, tracks the visitors who refused. Its staff were recorded and filed while evaluating the vendor. Its audience and advertising figures come from a channel that is blind to part of the audience and open to forgery. In each case the customer did what a diligent controller does, relied on a vendor that sells compliance, and is the one exposed. That is the precise mechanism by which privacy washing harms its victims: it converts the customer’s diligence into the customer’s liability.

5. The design is the deeper problem. The player’s privacy issues are not accidents of configuration. They are what measuring in the browser produces: a script on the customer’s page, data read from the device, a public unauthenticated endpoint, a routing choice made by the vendor. Fixing the configuration leaves the design in place, and the design will produce the next issue.

What this report is not: an assessment of the vendor’s video quality, features or support, its data processing agreement or its internal governance. What it is: evidence that the vendor’s public privacy claims fail the simplest tests, on the vendor’s own website and in the vendor’s own product, in a standard browser, tested in half an hour; and that the way those claims fail is arranged so that the customer pays.

Checks any customer can run

Four checks for the vendor’s website, four for the player on your own site and none require a specialist. A vendor that refuses to answer one of them has answered it.

1. Clear the browser, visit the vendor’s site, refuse everything, reload. Note the time of the refusal.
2. Open the Network tab and filter out the vendor’s own domain. Every request with a payload size went out after your refusal. Google, Facebook, LinkedIn, HubSpot, TikTok and advertising domains should be absent.
3. List the cookies and compare their timestamps with your refusal. Anything starting with _ga, _gid, _gcl, _fbp, _hj, __hs or hubspotutk is a tracking cookie. Set after your refusal: against your choice. Set before: before you were asked.
4. Ask where the vendor’s own CRM runs and whether it records sessions. Your staff’s contact details and reading behaviour are personal data too.
5. Refuse consent on your own site and watch the player. Filter the Network tab on the vendor’s domains. Every request that still goes out, and everything in its URL, is what your visitors’ refusal does not prevent.
6. Ask for the legal basis, not the cookie mode. “Cookieless” answers a question nobody asked. Ask: what personal data does the player send after a refusal, under which legal basis, to which processors, in which country.
7. Turn on a content blocker and play a video. If the analytics requests disappear, so does every viewer who uses one. Ask how the vendor corrects for it; if it does not, your reach figures are a floor of unknown depth.
8. Look at one beacon and ask what proves it is real. If every parameter is readable and there is no signature or token, anyone can send it. Ask how the vendor distinguishes a viewer from a script, how advertisement views are validated before they are billed, and whether the numbers come from delivery logs or from browser scripts. A vendor that measures from its own servers can answer this in one sentence.

Consent is not a banner but a behaviour, and a viewer count is only as trustworthy as the channel that produced it. The only way to know whether a vendor respects a “no” is to say no and watch what happens; the only way to know whether its numbers are real is to ask where they come from.

Appendix A. Requests observed after refusing cookies and reloading

All cookies refused in the consent banner at 19:34:34, page reloaded at 19:42:38. Only requests that went over the network are listed, with the payload size shown in the browser log; scripts served from memory cache are omitted, although they executed as well. Vendor portal identifiers are masked.

Request	Party	Payload
●  www.google-analytics.com/collect	Google (US)	71 B
●  region1.analytics.google.com/collect	Google (US)	48 B
●  www.google.com/collect	Google (US)	50 B
●  px.ads.linkedin.com/collect	LinkedIn / Microsoft (US)	768 B
●  px.ads.linkedin.com/wa	LinkedIn / Microsoft (US)	660 B
●  track.hubspot.com/__ptq.gif	HubSpot (US)	660 B
●  api.hubspot.com, api.hubapi.com	HubSpot (US)	805 B, 1.57 KB
●  forms.hscollectedforms.net	HubSpot (US)	536 B
●  perf-na1.hsforms.com/counters.gif (twice), forms.hsforms.com/counters.gif	HubSpot (US)	632 B, 633 B, 634 B
●  cta-service-cms2.hubspot.com, static.hsappstatic.net, [portal].hs-sites.com, [portal].fs1.hubspotusercontent	HubSpot (US)	CTA iframes, fonts, images
●  static.hotjar.com, script.hotjar.com	Hotjar (MT / FR)	scripts loaded
●  kit.fontawesome.com, ka-p.fontawesome.com (30 icon fetches)	Fonticons (US)	7.6 KB, 17.8 KB, ~0.5 KB each

Appendix B. Website data left in the browser

Safari’s website data overview after the visit. “Cache” is a cached response; “Alt-Svc” is a stored HTTP alternative-service entry advertised by that server. Neither is a cookie; both prove contact with the domain. Third-party cookies are blocked by Safari by default and would not appear here regardless of the vendor’s configuration.

Domain	Party	Stored data
●  [vendor].com	Vendor	Cache, cookies, databases, local storage, HSTS
●  google-analytics.com	Google (US)	Cache, Alt-Svc
●  google.com, google.nl	Google (US)	Alt-Svc
●  doubleclick.net	Google advertising (US)	Alt-Svc. Not visible in the network log.
●  googletagmanager.com, ajax.googleapis.com	Google (US)	Cache
●  hubspot.com, hs-scripts.com, hs-analytics.net, hs-banner.com, hsadspixel.net, hscollectedforms.net, hsappstatic.net, hs-sites.com, usemessages.com	HubSpot (US)	Cache, Alt-Svc
●  hubspotusercontent-na1.net	HubSpot (US)	Cache. Confirms the North America 1 instance.
●  licdn.com	LinkedIn / Microsoft (US)	Cache, Alt-Svc
●  hotjar.com	Hotjar (MT / FR)	Cache
●  fontawesome.com	Fonticons (US)	Cache
●  piwik.pro	Piwik PRO (PL)	Cache

Appendix C. All cookies on the vendor’s domain after refusal

As listed in Safari’s Web Inspector. Values omitted; property, portal and site identifiers embedded in cookie names are masked. “Set” is derived from expiry minus documented lifetime, corrected for the browser displaying winter-time expiries one hour early.

Cookie	Party	Set, lifetime	Purpose
●  cmplz_statistics / cmplz_marketing / cmplz_preferences	Consent tool (EU)	deny / deny / deny, 19:34:34, 1 year	Records the refusal
●  cmplz_functional / cmplz_banner_status / cmplz_policy_id / cmplz_consented_services	Consent tool (EU)	19:34:34, 1 year	Consent state
●  wp-wpml_current_language, wpml_browser_redirect_test, _icl_visitor_lang_js	Site (EU)	session / 13 months	Language preference
●  _ga	Google Analytics (US)	19:42:38, 13 months	Client identifier
●  _ga_[measurement ID]	Google Analytics 4 (US)	19:42:38, 13 months	Session state
●  _gid	Google Analytics (US)	19:42:38, 24 hours	Client identifier
●  _gat_UA-[property]-1	Google Universal Analytics (US)	19:43:38, 1 minute	Throttle; product discontinued
●  _gcl_au	Google Ads (US)	19:34:32, 90 days	Conversion linker; set on page load
●  hubspotutk	HubSpot (US)	19:42:39, 6 months	Visitor token
●  __hstc	HubSpot (US)	19:42:39, 6 months	Visitor history
●  __hssc / __hssrc	HubSpot (US)	19:42:39, 30 min / session	Session tracking
●  messagesUtk	HubSpot (US)	19:42:39, 6 months	Chat visitor token
●  _hjSession_[site ID]	Hotjar (MT / FR)	19:35:16, 30 min	Session recording; 42 s after refusal
●  _hjSessionUser_[site ID]	Hotjar (MT / FR)	19:42:38, 1 year	Persistent user identifier

Other storage after refusal: IndexedDB database hs-cta-interactions (HubSpot); local storage for [portal].hs-sites.com, app.hubspot.com and the vendor’s domain; session storage for the same three origins.

Appendix D. The captured beacons (anonymised)

Identifiers, customer names, timestamps and CloudFront request IDs are masked. All three playback beacons carry the same parameter set; only the values differ.

D.1 Playback beacon, browsing data intact, before refusal

GET https://stats.[vendor].com/?vu=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX&pm=html5

    &sid=XXXXXXXXXXXX&ts=1789203XXXXXX&pp=[broadcaster]&pt=[player template]

    &pv=v8.x&ev=pg&id=XXXXXXX&ct=[broadcaster]%20TV%20Live&pd=2011-11-15T10:33:37Z

    &vs=n/a&rs=2880×1620%20(x2.00)&fs=0&mt=video&du=0&sot=live&to=5636

    &pet=Session&pid=XXXXXXXXXXXX&wpa=false&bpc=-1&sn=24

Request headers (selection)

Sec-Fetch-Dest: image          <- sent as an image request

Sec-Fetch-Site: cross-site     <- from the broadcaster’s page to the vendor’s domain

Accept-Language: nl-NL,nl;q=0.9

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) … Safari/605.1.15

Response headers

Status: 200

Content-Type: image/gif

Content-Length: 43              <- tracking pixel

Cache-Control: max-age=315360000

Server: nginx/1.14.0 (Ubuntu)   <- 2018 release, out of support

Via: 1.1 XXXXXXXX.cloudfront.net (CloudFront)

x-amz-cf-pop: [EU edge]        <- Amazon edge in the EU

x-cache: Miss from cloudfront   <- forwarded to origin

Remote address: 18.239.83.109:443  <- Amazon range, see the sovereignty report, A.4

D.2 Advertising beacon, same session

GET https://stats.[vendor].com/?pm=html5&sid=ZZZZZZZZZZZZ&ts=1789204XXXXXX&pp=[broadcaster]

    &ev=xpg&id=[ad creative]&et=Creative&cid=XXXXXXX&pid=ZZZZZZZZZZZZ&pet=View

    &at=generic&ap=preroll&pct=25&auc=[ad unit]_web_preroll&lic=web_opout

    &hn=www.[broadcaster].nl&sn=16

D.3 Playback beacon after clearing the browser and refusing consent

GET https://stats.[vendor].com/?vu=YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY&pm=html5

    &sid=YYYYYYYYYYYY&ts=1789204XXXXXX&pp=[broadcaster]

    &pt=[player template]%20noconsent        <- the player is told consent was refused

    &pv=v8.x&ev=pg&id=XXXXXXX&ct=[broadcaster]%20TV%20Live&pd=2011-11-15T10:33:37Z

    &vs=n/a&rs=2880×1620%20(x2.00)&fs=0&mt=video&du=0&sot=live&to=13700

    &pet=Session&pid=YYYYYYYYYYYY&wpa=false&bpc=-1&sn=34

Remote address: 18.239.83.46:443   <- Amazon range

Status: 200, Content-Type: image/gif, Content-Length: 43

Server: nginx/1.14.0 (Ubuntu)

Via: 1.1 XXXXXXXX.cloudfront.net (CloudFront)

x-amz-cf-pop: [EU edge], x-cache: Miss from cloudfront

D.4 Playback beacon, new window, nothing cleared

GET https://stats.[vendor].com/?vu=WWWWWWWW-WWWW-WWWW-WWWW-WWWWWWWWWWWW&pm=html5

    &sid=WWWWWWWWWWWW&ts=1789204XXXXXX&pp=[broadcaster]&pt=[player template]%20noconsent

    &pv=v8.x&ev=pg&id=XXXXXXX&ct=[broadcaster]%20TV%20Live … &rs=2880×1620%20(x2.00)

    … &to=93707&pet=Session&pid=WWWWWWWWWWWW&sn=32

Remote address: 18.239.83.46:443, x-amz-cf-pop: [EU edge], x-cache: Miss from cloudfront

Viewer identifier new again: per session, not per device.