browser-update.org

Context

browser-update.org is the site of a service that shows notifications about an outdated browser (a widget for embedding on third-party sites). The controller named in the policy is Thomas Hümmer Webentwicklung, Augsburg, Germany; the contact is jossele@gmx.de. The supervisory authority is the Bavarian State Office for Data Protection Supervision. The site is served through Cloudflare (cf-ray, server: cloudflare).

The recording: 347 requests, 30 nodes, 23 data recipients, a recording length of about 591 seconds, taken on 16 August 2026. The session covers several pages (home, stat.html, contact.html, update-browser.html, blog.html) and contains two passes over the page with an ad slot — at the beginning (around +74 s) and at the end of the recording (around +570 s). Of the 347 requests, 105 fall on the own domain.

The processing is described by a privacy policy (Datenschutzerklärung) in German. A copy of it in another format and an export of the consent-management panel with a list of vendors are attached to the materials; in addition, an automated technical report from the gdpru.eu/har-check tool on the same file is attached, used for cross-verification.

Who receives data directly

Google (AdSense, Ad Manager, Analytics, Funding Choices, Ad Traffic Quality), demand.supply, Criteo, OpenX, ID5, Lotame, Yahoo, RTB House.

Declared versus actual

A consent platform exists — but it is late. This is the main difference of this case from sites where there is no consent mechanism at all. Here a consent-management platform is present: Google Funding Choices. The problem is the order of events. On the page with an ad slot, the first thing requested, at +74429 ms, is the demand.supply ad-stack script. Then the ad slots are initialised and the Google Publisher Tag from AdSense is loaded. At +75011 ms Google Analytics 4 already sends a /g/collect request with the client identifier and a page_view event. And only at +75381 ms — almost a second later — is the Funding Choices banner interface requested.

That is, by the time the user is shown the consent prompt, the advertising circuit and analytics have already been deployed and the first data has already been sent. Consent must, by law, precede the placement of analytics and advertising cookies (Directive 2002/58/EC, Art. 5(3); CJEU practice); here it follows the transmission.

The consent string appears only later. On the first visit the demand.supply and Google Publisher Tag requests carry no consent string in the IAB TCF format. A consent string of 578 characters with the marker gdpr=1 appears in the requests only in the second pass (from +534 s), when the full auction with Criteo, OpenX, ID5, Lotame, Yahoo and RTB House unfolds. The Google consent-mode marker gcs=G100 is likewise present only in the second session; in the first it is absent.

The policy names only analytics. The document is honest in one respect: Google Analytics is named directly, with the provider Google Inc., USA, and transfer to servers in the USA indicated. But the entire advertising circuit is absent from the policy. There is neither AdSense and Ad Manager, nor the demand.supply platform, nor Funding Choices itself, nor a single RTB vendor. Meanwhile the consent-management panel, whose export is attached, declares up to 308 vendors for the purpose ‘Store and/or access information on a device’ alone and lists dozens of well-known advertising companies. The gap between one named recipient and hundreds of actual ones is extreme.

The statement about non-transfer to third parties diverges from practice. The policy states directly that collected data is not passed to third parties without the data subject’s explicit consent, and that the processing of cookies and analytics relies on legitimate interest under Art. 6(1)(f). In fact, on visiting a page with an ad slot, data is addressed to dozens of advertising recipients, the client identifier goes to analytics before the banner, and the URL of the viewed page is transmitted to the demand.supply platform in the request parameters in base64 encoding.

Security headers are almost absent. The own domain has no content-security header on any of the 105 responses, no strict transport, the frame-embedding ban appears on only three responses, and there is no content-type-sniffing ban and no referrer policy. Part of the navigation, moreover, goes over plain http rather than https — the addresses http://browser-update.org/update-browser.html are visible in the analytics requests themselves.

Consent: what is proven and what is not

Proven: a consent platform is present on the site. The requests to Google Funding Choices (fundingchoicesmessages.google.com) are read from the recording; the banner interface is requested at +75381 ms.

Proven: the ad stack and analytics start before the banner. The demand.supply script is requested at +74429 ms, the Google Publisher Tag at +74774 ms, the first Google Analytics 4 request with the client identifier at +75011 ms. All of them precede the request for the consent interface. The order is read from the timings and initiators of the recording.

Proven: on the first visit there is no TCF consent string in the advertising requests. The gdpr_consent parameter appears in the requests only from the second pass (from +534 s). In the first pass the demand.supply and Google Publisher Tag requests do not contain it.

Proven: the client identifier is included in the analytics requests. The cid field stands in the /g/collect requests next to the page URL and event. In the two passes of the recording the identifiers differ.

Not proven and not asserted: the content of the user’s choice in the banner. Whether the consent or refusal button was pressed is not unambiguously established from the network recording; only the order is recorded — data goes out before the banner appears, and the consent string and the gcs=G100 mode appear later. The conclusion about the violation rests on this order, not on a reconstruction of clicks.

Not proven and not asserted: the state of cookies on the device. Cookie headers and response bodies were removed from the published file during sanitisation.

Separately: the browser was sending the DNT: 1 header during capture. This had no effect on the composition and addressing of the requests.

Boundaries of observation

The recording covers several pages of the site and two passes over the page with an ad slot. The observation records the browser’s behaviour, not the services’ internal workings: server-side processing, contractual relationships with recipients and settings on their side are not verified by a browser recording. The legal assessment is made by the competent authority — in this case the Bavarian State Office for Data Protection Supervision.

The file is published sanitised of personal data: cookie headers in requests and response bodies were removed. The conclusion that the consent platform is late rests on the network level — the composition, addresses, timings and initiators of the requests are read from the recording in full, and it is visible that the ad stack and analytics send data earlier than the consent interface is requested. The full client identifiers and consent strings are not reproduced in the analysis.

The identification of services rests on domains, address patterns and cross-verification with the consent-panel export: Google AdSense and Ad Manager — by googlesyndication.com, doubleclick.net and safeframe; analytics — by google-analytics.com and the property G-1VW8K23XF3; the consent platform — by fundingchoicesmessages.google.com; demand.supply — by the domain and the address pattern of the ad slots; the RTB vendors — by criteo, openxcdn, id5-sync, crwdcntrl.net, analytics.yahoo.com, creativecdn.com; the serving provider — by the cf-ray and server: cloudflare headers. The attached automated tool report was used only as an additional cross-check; all key conclusions were re-verified against the recording itself, and on the point of security headers the own check refined the report.

Conclusion

The site of the browser-update notification service deploys, on the page with an ad slot, a full advertising circuit: Google AdSense and Ad Manager, the demand.supply platform and, through the consent-management panel, dozens of RTB vendors with a vendor count of up to 308. Of all this the privacy policy names only Google Analytics and separately states that data is not passed to third parties without consent.

A consent-management platform is present on the site — Google Funding Choices — but it appears only after the ad stack and analytics have been initialised and have sent the first data: the client identifier goes to Google Analytics about a second before the banner, and on the first visit the advertising-service requests carry no consent string. The consent string and the Google consent mode appear only on a repeat visit. The own domain has almost no security headers, and part of the navigation goes over an unprotected protocol.

Remediation: do not start the ad stack, the Google Publisher Tag and analytics before consent is obtained — bring their loading under the actual control of the consent platform, so that no requests to advertising and analytics recipients go out before the user’s choice; name all recipients of web data in the policy, with the fields transmitted and the purposes, including the advertising circuit and the vendor list of the consent panel; bring the statement about non-transfer to third parties into line with the actual practice; disclose the legal basis for cross-border transfer with respect to the advertising recipients; move the entire site to https and set a content-security-policy, strict transport, a frame-embedding ban, a content-type-sniffing ban and a referrer policy.