Advertisers Get Your IP Address From the Ad Auction

Your address is handed over rather than found. Opening a page with an advert on it sets off an auction for that space, your address is written into a named field in the message that starts the auction, and the whole thing is settled before the advert appears.

The address is declared, not discovered

IAB Tech Lab’s specification for those auctions is OpenRTB, which the organisation’s own documentation calls “the transport and auction protocol”. Its bid request is the message a seller sends to bidders when a slot needs filling, and it is assembled from objects with named fields.

One of those objects is Device, which version 2.3 of the specification introduces as providing “information pertaining to the device through which the user is interacting”. Two of its fields matter here. ip is defined as the “IPv4 address closest to device”, and ipv6 as “IP address closest to device as IPv6”. They sit beside ua, the “Browser user agent string”, and both ip and the Device object itself are marked recommended rather than optional.

Nothing is retrieved from you. The seller writes the address into the message. IAB Tech Lab’s account of the arrangement has supply-side platforms composing the request, after which “Bidders get an easily readable, static list they can use to evaluate the inventory”. Your address arrives as one line in a seller’s description of the advertising space.

That is why it behaves unlike the other things that recognise you. It is not filed on your machine and it is not inferred from how your browser draws a page, and where each identifier is physically held is what decides which of them you can do anything about.

The request records that the location was worked out

A bid request can also carry a Geo object, which the same specification introduces as encapsulating “various methods for specifying a geographic location”. Its fields run from latitude and longitude through country, region, metro, city and postal code.

The revealing field is type, described in one phrase as the “Source of location data”. A location in a bid request does not arrive as a bare place. It arrives with a note attached saying where the place came from. Version 2.4 lists a companion field, ipservice, for the “Service or provider used to determine geolocation from IP address if applicable (i.e., type = 2)”, so the message can state both that your whereabouts were derived from your address and which vendor derived them.

The specification then tells implementers not to dress the result up. Its rule on coordinates reads: “The lat/lon attributes should only be passed if they conform to the accuracy depicted in the type attribute. For example, the centroid of a geographic region such as postal code should not be passed.” An address does not yield a point on a map, and the document tells implementers not to send one as though it did.

So the protocol does not treat a location as simply a location. It records where the location came from, and it limits what may be sent depending on the answer. The lookup we run for any address reaches the same limit from the other end. Its notes on incomplete results warn that “Mobile networks, VPN servers, IPv6 allocations, and corporate networks can return broad or generic results”, and that a location which looks wrong may mean a stale database or traffic routed through infrastructure elsewhere. There is more than one way for that to happen, and why a result lands in the wrong city sets them out.

What the address identifies is looser than it looks

Underneath the geolocation databases sits the registry record, which is a different kind of document with a different kind of authority. The registry record for an address comes from RDAP, and our page for it is blunt about what returns. You learn which range the address came out of, what the network is called, which organisation it was issued to, and where to complain about it. On what you do not learn, the page is explicit: “It does not identify the person or household using the address.”

It goes on to caution that an abuse contact belongs to the operator and not to the user, and that an address can be any of three awkward things: something several users share, something reassigned over time, or something sitting behind carrier-grade NAT. Each of those costs a targeting system a different kind of precision.

Sharing removes the household. One public address can stand for more than one home, and why a single address can cover many homes is a matter of how providers ran out of addresses rather than anything about you.

Reassignment removes the history. The address you are using this week can belong to somebody else next week, which makes any conclusion drawn from it perishable.

And the protocol does not use the address for counting. Its User object carries an identifier issued by the exchange, and of that identifier the specification says that “this user ID must be stable long enough to serve reasonably as the basis for frequency capping and retargeting”. Counting how many times you have been shown something is assigned to that identifier, not to the address.

On mobile, the specification says the address is hard to get right

The Device section carries a best practice note aimed at the exchanges that fill the field in. It reads: “Proper device IP detection in mobile is not straightforward. Typically it involves starting at the left of the x-forwarded-for header, skipping private carrier networks (e.g., 10.x.x.x or 192.x.x.x), and possibly scanning for known carrier IP ranges.” It closes by urging exchanges to “research and implement this feature carefully when presenting device IP values to bidders”.

The caution is about the field’s reliability rather than its format. On a mobile connection the value written into the request is picked by walking a header that can hold a chain of addresses, and the specification says in plain words that doing it properly is not simple.

Whether an address is personal data has been litigated

In Case C-582/14, Patrick Breyer v Bundesrepublik Deutschland, decided on 19 October 2016, the Court of Justice of the European Union held that “a dynamic IP address registered by an online media services provider when a person accesses a website that the provider makes accessible to the public constitutes personal data”. The condition the Court attached carries as much weight as the holding: it bites where that operator has lawful means of obtaining, from the visitor’s own internet provider, the further data needed to attach a name to the address.

The reasoning is the part worth keeping. The Court pointed at the test in the legislation itself, which asks about the means likely reasonably to be used to identify someone “either by the controller or by any other person”, and took from that wording that “it is not required that all the information enabling the identification of the data subject must be in the hands of one person”.

That judgment interprets Directive 95/46, which the General Data Protection Regulation replaced, and nothing here should be read as a claim about where the question stands now. What it captures is the shape of the argument. An address is weak alone and strong in company, and company is what the rest of the bid request supplies.

What follows for you

You cannot clear it. There is no stored copy on your side to remove, because the copy that matters was written by a seller into a message you never saw.

Changing the visible address changes what the field carries. A different value in ip produces a different derived location, and nothing else in the request moves with it. Your user agent is a separate field and it arrives unaltered.

A flag against the address is a different problem. Reputation data labels addresses for its own purposes, and why a plain home connection gets challenged has little to do with who is bidding for the space beside what you are reading.

Put together, it is a coarse identifier. It can be shared, it can be reassigned, and the location drawn from it is recorded by the protocol as derived rather than measured, in a field of its own. It travels regardless, in a field the specification recommends, because the connection that brought this page to you could not have worked without it.