ads.txt file and is possible when DSPs and AdXs do
not follow the ads.txt and sellers.json standards.
Some examples of these misrepresentations include:
•a publisher’s ads.txt file might incorrectly use seller
IDs of other publishers to suggest an authorized relation-
ship with an AdX to boost the perception of its inventory.
(Misrepresentations #1 and #2)
•a publisher’s ads.txt file might incorrectly indicate
that a popular AdX is an authorized (re)seller of its
inventory to boost its reputation with other AdXs. (Mis-
representation #3)
•a publisher’s ads.txt file might have more than
one entry of the same seller type for an AdX or
sellers.json files might associate a seller ID with
multiple publishers or sellers making ads.txt and
sellers.json verification unreliable. (Misrepresenta-
tions #4 and #9)
•a publisher’s ads.txt file might list authorized relation-
ships with (re)sellers that do not have sellers.json
files, making end-to-end verification impossible. (Misrep-
resentation #8)
Dark pooling. Pooling is a common strategy to share
resources in online advertising. Consider, for example, the
case where two or more publishers are owned by the same
parent organization. In such scenarios, the ability to share
advertising infrastructure and AdX accounts allows for more
efficient operation and management. One way to identify
the occurrence of pooling is by noting a single AdX-
issued ‘seller ID’ shared by multiple publisher websites.
Dark pools are pools in which seller IDs are shared by
organizationally-unrelated publishers (possibly of differing
reputation). Note that “dark pooling” is a term of art that
is commonly used in industry. While pooling is not itself a
“dark” practice, pooling seller IDs of unrelated publishers
is considered a “dark” practice because it deceives potential
buyers about the actual source of the ad inventory [34], [35].
The seller ID defined in ads.txt and
sellers.json standards is also defined in the RTB
protocol [36], [37]. Note that the payment after successful
completion of an RTB auction is made to the publisher
(i.e., the seller) associated with the seller ID [38]. Hence,
it should be noted that simply using another domain’s
seller ID in ad requests from a website will result in any
ad-related payments being made to the owner of the seller
ID. Therefore, for revenue sharing, the creation of these
pools needs to be facilitated either through intermediaries
(e.g., SSPs) or by collaboration between publishers.
End-to-end validation of pooled supply chains. Pooling
leads to a break down of any brand or DSP’s ability to
perform end-to-end verification of the ad inventory supply
chain. Specifically, the final step of verification highlighted
in §2.1 cannot be meaningfully completed unless all do-
mains associated with a publisher’s account are publicly
known (and unfortunately, this is not the case). This is
because the end-to-end verification of the ad inventory
supply chain, as specified by the IAB, implicitly relies on
trust that seller IDs are actually associated with specific
organizations and that these associations are verified by
AdXs. We illustrate this with an example.
•Consider a publisher website sportsnews.example
which has a legitimate subsidiary: nbanews.example.
The publisher registers for an account with a popular
AdX (adx) and is issued the seller ID sellerid after
being vetted by adx. It is expected that this website
can now share this seller ID with its subsidiaries. Both
websites will now list adx as a DIRECT seller through
the sellerid account in their ads.txt files.
•The publisher now decides to share adx-issued
seller ID with fakesportsnews.example, an-
other sports news website but of low quality, for
a cut of the revenue generated from ads shown on
fakesportsnews.example. In its ads.txt file,
fakesportsnews.example now adds adx as a
DIRECT seller and also lists sellerid as its seller ID.
Note that fakesportsnews.example would other-
wise be unable to get directly listed on adx and monetize
its ad inventory due to its low quality.
•When an ad request for some inventory is sent from
fakesportsnews.example, all basic supply chain
validation checks are successful because the seller ID
sellerid is in fact registered by adx in their
sellers.json file. Any bidding DSP will therefore
operate under the assumption that the website receiving
their ads has been vetted by adx and is associated with
sportsnews.example.
•Complications only arise if the verifier notices that
sellerid was only registered to the owner of
sportsnews.example and the bid request actu-
ally originated at fakesportsnews.example. How-
ever, invalidating the bid request simply because of
this inconsistency will mean that even legitimate sub-
sidiaries such as nbanews.example cannot pool their
inventory. Instead, additional checks are required to
ascertain whether fakesportsnews.example and
sportsnews.example are related or whether adx
vetted fakesportsnews.example as well. This is-
sue remains unaddressed by current validation mecha-
nisms.
Caveat. The example described assumes collaboration
between publishers — sportsnews.example and
fakesportsnews.example. This might be inadvertent
in some cases — e.g., if sportsnews.example and
fakesportsnews.example are both assigned the same
seller ID through a common intermediary (an SSP, for
example as shown in Figure 2).
In sum, by pooling various unrelated websites under a
single seller ID, low-quality publishers can “launder” their
ad inventory, rendering it indistinguishable from the inven-
tory of high-quality publishers. Moreover, this can occur
when an AdX provides the seller ID to a trusted publisher
(or an SSP), which then inadequately vets the low-quality
publishers whose inventory it pools. Figure 2 illustrates this
scenario of syndication-based pooling by some intermediary
SSP. As we show later, such pooling is common. In fact, we
4