English
Deutsch
PolskiTCF Feature 3: When Google May Use the IP Address to Identify a Device
Contents
Google began switching on IP-based measurement and personalisation in the EEA, the UK and Switzerland on 3 August 2026. AdSense publishers had been told on 17 June. The notice was short, and the sentence carrying the weight named a field that most consent dialogues have never surfaced as anything a person could act on.
The field is TCF Feature 3. Understanding what changed means first understanding what a Feature is, because in the Transparency and Consent Framework it is not the same kind of object as a Purpose.
Four classes, two of them decisions
TCF v2.2 splits what a vendor declares into four groups, and they behave differently.
Purposes 11 consent or legitimate interest, per vendor
Special purposes 2 legitimate interest only, no user choice
Features 3 disclosure only, no separate user choice
Special features 2 explicit opt-in, off until ticked
Feature 3 "Identify devices based on information
transmitted automatically"
applies wherever the vendor has a valid basis for a purpose
the feature was declared under
never granted on its own, never refused on its own
must appear in the disclosure the CMP presentsThe distinction between a Feature and a Special Feature is the whole story. Precise geolocation is a Special Feature: it is off until someone ticks it, and a vendor without that tick may not use it. Feature 3 is an ordinary Feature. It is described in the interface, and it takes effect as a consequence of the purposes a vendor already has a basis for.
Why it looks like nothing was decided
Because nothing was, at least not directly. A person accepting a banner grants purposes. The features attached to those purposes come with them, and no toggle exists to separate them. That is by design: features describe how data is handled in service of a purpose rather than constituting a purpose of their own.
The practical result is that a change in what a vendor does under Feature 3 does not produce a new consent event, a new string value or a new count anywhere in reporting. The TC String records purposes and special-feature opt-ins. It does not record features, because there is nothing per-user to record.
What Google actually turned on
The processing concerns IP addresses that already arrive through existing site and app integrations. This is worth stating plainly, because the announcement was widely read as new collection. It is not: the addresses were already in the request. What changed is that they may now be used for device identification and for personalisation, subject to consent existing for at least one linked purpose.
Google describes three techniques as guarding the processing: computation on the device, trusted execution environments, and secure multi-party computation. Those are meaningful engineering commitments and they are also, from the outside, unverifiable. Nothing in the network trace distinguishes an IP address processed inside an enclave from one processed outside it.
What this means for a consent interface
The obligation that does land on publishers is disclosure. Google added Feature 3 to its TCF registration, and a consent interface that lists Google’s declared purposes and features has to list this one too. A CMP kept current handles that automatically; a CMP whose vendor data was last refreshed a year ago does not, and the gap is invisible from the front end.
Three checks are worth running once. Check whether the CMP’s vendor list has been refreshed since June 2026 and whether the disclosure text shown for Google now names device identification from automatically transmitted information. Then check whether the banner actually asks about the purposes under which the feature is declared, since that determines when it applies at all.
The part that stays unchanged
An IP address remains personal data, and none of this alters that. The GDPR obligations that attach to processing it are the same ones as before, and a technique that keeps the address inside an enclave changes the risk profile rather than the legal category.
What has changed is narrower and more concrete: a capability that was dormant is now active, it activates through a mechanism with no user-facing switch, and the only trace of it in a normal setup is a line of disclosure text that almost nobody reads. For anyone documenting a processing inventory, that line is now load-bearing.
Questions and answers
Can Feature 3 be prevented for Google without refusing every purpose?
Not through the feature itself, because it has no switch in the framework. The only lever is the purposes under which Google has declared the feature: if there is no valid basis for any of those purposes, Feature 3 does not apply.
For visitors this means refusing those specific purposes, which an interface only allows if it offers purposes individually and per vendor. Publishers additionally have publisher restrictions in the TCF, which can exclude a purpose entirely for a single vendor or limit it to consent. They too operate on purposes, not on features.
Both routes come at a price. Excluding a purpose under which the feature is declared removes everything Google does under that purpose, not only device identification via the IP address. A restriction for the feature alone is not provided for in the framework, and that is the flip side of a design in which features carry no choice of their own.
How does Feature 3 differ from the special feature for actively scanning device characteristics?
In how the information comes about. The second special feature covers actively scanning device characteristics for identification, meaning values a script deliberately reads out, and therefore requires an explicit opt-in. Feature 3 covers information that is transmitted automatically with every request anyway, such as the IP address, and therefore only has to be disclosed.
Related articles
