webXray [1Libert, Timothy (2015): "Exposing the Invisible Web: An Analysis of Third-Party HTTP Requests on 1 Million Websites", International Journal of Communication 9. (Link)] is a third-party request and privacy-policy measurement tool by Timothy Libert, and it was one of the three hand-curated lists the pre-2022 literature used to put a company name next to a third-party domain — the other two being Disconnect and WhoTracks.me, which two corpus papers merge with it explicitly [2Sánchez-Rola, Iskander; Dell'Amico, Matteo; Balzarotti, Davide; Vervier, Pierre-Antoine; Bilge, Leyla (2021): "Journey to the Center of the Cookie Ecosystem: Unraveling Actors' Roles and Relationships", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] [3Dambra, Savino; Sanchez-Rola, Iskander; Bilge, Leyla; Balzarotti, Davide (2022): "When Sally Met Trackers: Web Tracking From the Users' Perspective", in: Proceedings of the USENIX Security Symposium. (Link)]. Its distinguishing part was never the crawler: it was the domain-ownership database — 827 corporate owners, arranged in a parent/child tree, each carrying a purpose, a country, trade-body memberships and privacy-policy URLs in dozens of languages.

Two things a new measurement needs to know before citing it:

• The tool is gone from where every paper points, but it is not lost and it did not end up proprietary. github.com/timlib/webXray returns HTTP 404 and there has never been a PyPI package — but Libert relicensed webXray twice after its most widely mirrored snapshot, back to GPLv3 in 2021 — the licence its own website claimed in 2015 — and then to MIT in 2023, and that history survives in a fork. The author now runs a commercial product under the same name at webxray.ai.
• The database survives and it is frozen at 2021-03-04. How stale that makes it has now been measured, and the honest answer is “less than this page used to imply, and by an amount this page cannot fully separate from how it was measured”. Drawn at random from its own coverage — 60 domains, adjudicated against primary sources on 2026-09-05 — webXray names today's owner for 69.9% of the entries that could be settled (95% CI 55.5–83.1%), and for 93.9% of the third-party surface weighted by how often a crawl meets the domain, though that second figure is concentrated enough that gstatic.com alone carries 39% of it. The older table of 28 hand-picked disagreements on this page reads far worse — 1 of the 24 domains webXray covers there — but the two numbers are not comparable, for two reasons at once, and the section below spells both out. What is not in doubt is coverage: webXray names an owner for 2.1% of the registrable third-party domains in the frame, against Tracker Radar's 17.2% and Disconnect's 7.0%. Tracker Radar and Disconnect are the live alternatives, and they are not equivalent to each other either.

This page is therefore two pages in one: what webXray was and why you cannot install it, and — the part you actually need — how domain-to-company ownership resolution works now, measured. If your question is “which crawler should I run”, go to Crawler; if it is “how do I decide which company a request went to”, you are in the right place, and the short answer is in Choosing a resolution source now with the pipeline around it in Assembling the pipeline. Everything between those and here is the evidence for them.

The last public version (webXray 3.x, “forensic edition”) is not the PhantomJS tool the 2016 OpenWPM paper criticised [5Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)]. It drives consumer Chrome over the DevTools protocol directly — websocket-client, no Selenium and no Puppeteer — and has a client/server split for distributed crawling.¹⁾

Availability, every line checked on 2026-08-17:

domain_owners.json is a flat JSON array of owner records with an explicit tree. It is worth understanding in detail, because it is the most ambitious schema any of the three databases uses, and because most of that ambition is unfilled.

Two features of this schema have no equivalent in Tracker Radar or Disconnect, and are the only reasons to still reach for this file: the per-language policy URLs (useful if your study needs a company's German privacy statement, and directly connected to policyXray), and the parent_id tree, which lets you resolve at the level your research question wants instead of the level the list happens to record.

That tree is not cosmetic. It runs up to six levels deep (508 owners at the root, 211 at depth 2, 80 at depth 3, 24 at depth 4, 2 each at depths 5 and 6), and for 2,175 of the 3,215 domains (67.7%) the immediate owner differs from the root of its tree. doubleclick.net is owned by “DoubleClick”, whose parent chain ends at “Alphabet”. Tracker Radar says “Google LLC” and Disconnect says “Google”. None of the three is wrong; they are answers to three different questions, and §“Two lists disagree” below measures what happens when you forget that.

The three lists are not three attempts at the same artefact. They differ in size by more than an order of magnitude, in what a record means, and in what they are licensed for. A fourth live option, Ghostery's trackerdb, is not measured here: its ownership data is spread across per-company .eno files with a separate patterns layer rather than a single domain→owner map, so putting it in the same table would have meant writing a parser whose choices nobody could check against the other three. That is an omission, not a judgement — if you are choosing among the live lists, this page gives you numbers for two of the three.

Size is the wrong comparison, because a domain you never meet costs you nothing. The right one is: of the third-party domains a crawl actually encounters, weighted by how often it encounters them, what share can this list attribute to a company?

The measurement below takes Tracker Radar's domain_summary.json as the universe of third-party domains and its prevalence field as the weight, folds each key to a registrable domain with the ICANN section of the current Public Suffix List, and asks each list for an owner. This universe is Tracker Radar's own view of the web, which flatters Tracker Radar and nobody else — read its column as “the list scored on its home ground” and the other two as measured against a denominator they had no part in choosing.

The 2.1% and the 58.6% in the same row are the whole story of this file. webXray covers almost none of the web by domain count and well over half of it by weight, because it is a head list: the few hundred domains it knows are the ones on every page. Sliced by rank, the tail falls off a cliff:

Libert said this himself in 2018, and the sentence is worth having to hand when a reviewer asks about coverage: “because webxray's database of domain ownership primarily contains major ad networks rather than small clients, and policyxray only searches for identified parties, variability in the long-tail of trackers may not have an outsized effect on overall findings related to disclosure. Nonetheless, it is important to point out that the number of parties being searched for is fewer than the total number of parties present.” [4Libert, Timothy (2018): "An Automated Approach to Auditing Disclosure of Third-Party Data Collection in Website Privacy Policies", in: Proceedings of the ACM Web Conference. (DOI)]

Three traps here, and the first one will silently ruin any coverage figure you compute:

• The Public Suffix List has two sections, and using the wrong one manufactures a coverage hole. googleapis.com is a PRIVATE PSL rule (6,941 ICANN rules against 3,290 private ones in the snapshot used here). Fold with the private section and fonts.googleapis.com, ajax.googleapis.com and maps.googleapis.com each survive as their own “registrable domain”; look each up by exact key and every one comes back unowned — even though all three lists name googleapis.com → Google. fonts.googleapis.com alone carries prevalence 0.369, so this single mistake moves webXray's weighted coverage from 58.6% to 54.5% and Tracker Radar's from 84.3% to 79.3%. Fold on the ICANN section, or walk parent labels at lookup time, or both. The four combinations are printed side by side by the script and the spread between them is larger than the difference between the lists.
• A large fraction of domain_summary.json's 47,836 rows are keyed by hostname, and how large depends on the fold. An ICANN-section fold merges 15,651 of them; the ICANN+PRIVATE fold merges only 2,339, because googleapis.com, s3.amazonaws.com and cloudfront.net are themselves private-section suffixes. (A label-count heuristic — “three or more labels” — gives 16,396 and answers neither question; do not use it.) All three ownership lists key on the registrable domain, so comparing coverage without folding at all charges webXray and Disconnect for subdomains they were never meant to hold.
• 19 rows are not hostnames at all — 18 bracketed IPv6 literals and the literal string “null”, the last with a prevalence of 0.024 and a full behaviour profile attached. Drop them explicitly and say you did; do not let a null domain become a data point.

With the fold and the lookup done properly, 29,896 of the 32,369 domains (92.4%) have no owner in either webXray or Disconnect, but only 14.4% of the prevalence weight does. The most requested domain no list can name is tiktokw.us at prevalence 0.041 — Tracker Radar attributes it to ByteDance, the other two have nothing. That is what a real coverage hole looks like: recent, mid-tail, and concentrated in domains that appeared after the list was last curated.

For every domain that two lists both cover, owner_dbs.py compares the owner strings after normalising punctuation and folding away legal-form suffixes (Inc, LLC, GmbH, S.A.S, …) but no synonyms — so the “agree” columns are a lower bound on real agreement and the last column an upper bound on real disagreement. The fold is deliberately timid: it leaves 782 of webXray's 827 owner names untouched, and of the 45 it does change only 16 lose a legal suffix — the other 29 change on punctuation alone (AT&T, JD.com, “Here, There & Everywhere”). If you want the agreement figures to go up, a synonym table is what you would have to add, and there is no principled one.

Between a third and a half of jointly covered domains get different company names. Before concluding that some list is broken, note what happens if you resolve webXray up its ownership tree first — the obvious fix, since webXray says “DoubleClick” where the others say “Google”:

Resolving to the root makes agreement worse, and the reason is instructive. webXray's roots are holding companies and, worse, historical ones: google.com resolves to “Alphabet” (against “Google LLC” and “Google”), adnxs.com to “AT&T”, yahoo.com to “Verizon”, tapad.com to “Telenor”, turn.com to “Singtel”. Every one of those was true when the file was last curated and none is true now. So the disagreements decompose into two independent axes, and a paper has to state its position on both:

• Granularity. Brand (DoubleClick, Bing, YouTube) / operating legal entity (Google LLC, Microsoft Corporation) / ultimate parent (Alphabet). webXray can give you any of the three; Tracker Radar gives the legal entity; Disconnect gives a compact grouping name. “Sites contacting Google” is a different number under each, and the difference is not small: bing.com, linkedin.com and adnxs.com all become Microsoft at the entity level.
• Vintage. Which snapshot, and when was ownership last checked. Ad tech consolidates continuously — the same problem [9Selmo, Carlos; Carisimo, Esteban; Bustamante, Fabián E.; Alvarez-Hamelin, J. Ignacio (2025): "Learning AS-to-Organization Mappings with Borges", in: Proceedings of the 2025 ACM Internet Measurement Conference, pp. 120-133. (DOI)] names at the network layer as “an Internet shaped by constant mergers, rebrandings, and regional variation”.

The three files have three different shapes, and the shape is where the granularity choice becomes code. webXray is an array of owners each holding a domains list and a parent_id; Tracker Radar's domain_map.json is already keyed by domain; Disconnect's entities.json is keyed by entity, so it has to be inverted before you can look a domain up at all. Reading all three at once takes about twenty lines and immediately shows what you are choosing between:

owner_lookup.py

import json
 
WX = json.load(open('cache/webxray.json'))
TR = json.load(open('cache/tr_domain_map.json'))
DC = json.load(open('cache/disconnect_entities.json'))['entities']
 
# webXray: an array of owners, each with a `domains` list and a `parent_id`.
wx_by_id = {o['id']: o for o in WX}
wx = {d.lower(): o for o in WX for d in o['domains']}
 
def wx_chain(domain):
    o = wx.get(domain)
    if o is None:
        return None
    chain = [o['name']]
    seen = {o['id']}
    while o['parent_id'] is not None and o['parent_id'] not in seen:
        o = wx_by_id[o['parent_id']]
        seen.add(o['id'])
        chain.append(o['name'])
    return chain                      # brand first, ultimate parent last
 
# Tracker Radar: already keyed by domain.
tr = {d.lower(): v['entityName'] for d, v in TR.items()}
 
# Disconnect: keyed by ENTITY, so it has to be inverted. `properties` is the
# ownership claim; `resources` is what the tracker actually served from.
dc = {}
for name, v in DC.items():
    for d in v.get('resources', []):
        dc.setdefault(d.lower(), name)
for name, v in DC.items():
    for d in v.get('properties', []):
        dc[d.lower()] = name
 
for d in ['doubleclick.net', 'adnxs.com', 'facebook.net', 'fonts.googleapis.com']:
    print(f'{d:24} webXray={wx_chain(d)}  TR={tr.get(d)!r}  Disconnect={dc.get(d)!r}')

Its real output on the 2026-08-17 snapshots:

doubleclick.net          webXray=['DoubleClick', 'Google', 'Alphabet']  TR='Google LLC'  Disconnect='Google'
adnxs.com                webXray=['Xandr', 'AT&T']  TR='Microsoft Corporation'  Disconnect='Microsoft'
facebook.net             webXray=['Facebook']  TR='Facebook, Inc.'  Disconnect='Meta'
fonts.googleapis.com     webXray=None  TR=None  Disconnect=None

Four rows, four different lessons. doubleclick.net is the granularity axis, with nothing wrong anywhere. adnxs.com is the vintage axis, with webXray's whole chain superseded. facebook.net shows the two live lists disagreeing because one carries a five-year-old legal name. And fonts.googleapis.com comes back empty from all three — which is a bug in this snippet, not a coverage hole: every list names googleapis.com → Google, and the snippet looks up the exact key it was given. That is the PSL private-section trap above, reproduced in twenty lines. Fix it by trying each parent label:

def resolve(host, mapping):
    labels = host.split('.')
    for i in range(len(labels) - 1):          # stop at two labels
        candidate = '.'.join(labels[i:])
        if candidate in mapping:
            return mapping[candidate], candidate
    return None, None

with which fonts.googleapis.com resolves to Google in all three. Two further details worth copying: the seen set in wx_chain is not decoration — walk a hand-curated parent chain without a cycle guard and one bad edge hangs your pipeline; and Disconnect's resources are loaded before its properties so the ownership claim wins where the two disagree.

30 of the highest-prevalence disagreements were adjudicated one by one against primary sources (by Sonnet sub-agents working to a published brief, single-rated — see the methodology section; the 2026-09-05 random sample, not this table, is the one with a measured inter-rater figure) against primary sources — company newsrooms, SEC filings, or the domain's own legal documents — on 2026-08-17. Every row and source is in scripts/owner_adjudication.py and on the provenance page.

Two of the 30 could not be settled from a primary source and are excluded from the table, leaving 28.

Named examples, useful as regression tests for your own pipeline: adnxs.com (Xandr, AT&T → Microsoft, closed 2022-06-06); facebook.com (Facebook, Inc. → Meta Platforms, 2021-10-28 — Tracker Radar still says “Facebook, Inc.”); outbrain.com and teads.tv (Outbrain acquired Teads 2025-02-03 and then took its name, inverting the pair); postrelease.com (Nativo → Life360, completed 2026-01-05, which only Disconnect has); crwdcntrl.net (Lotame → Publicis, announced 2025-03-06). Three rows are errors rather than staleness: Tracker Radar attributes jsdelivr.net to “Prospect One”, jsDelivr's infrastructure contractor, where jsDelivr's own data-processing agreement names Volentio JSD Limited; Tracker Radar attributes stackadapt.com to “Collective Roll”, which is StackAdapt's own pre-2014 founding name and not a separate owner; and webXray's root for 1rx.io is “Marimedia”, which no primary source corroborates.

The table above is what you see when you look where the lists disagree. It is not an accuracy rate, and every version of this page has said so. This section is the measurement that was missing until 2026-09-05: 60 registrable domains drawn at random from each list's own coverage, stratified by prevalence quartile, each adjudicated against a primary source under the same sourcing bar as the 30 above — though, as it turns out, not under the same scoring convention; see the box below. 180 draws over 175 distinct domains (five were drawn for more than one list); each domain was adjudicated once and scored against all three lists, giving 525 verdicts. Only a list's own draws enter that list's rate, and of each list's 60 the ones that could be settled and make an ownership claim are 49, 47 and 42 — 138 rows carry every accuracy figure below.

The sampler is scripts/owner_sample.py (seed 20260905, allocation 24/12/12/12 over quartiles, snapshots hashed), the estimator scripts/owner_random_sample.py (stratified, bootstrap intervals). The design, the denominators and the limits are on the provenance page; both scripts and every unedited output, including the full 175-row adjudication table, are on its code appendix.

Two numbers per verdict, because there are two different questions:

• domain-level — of the domains this list names an owner for, what share does it name correctly? Every entry weighs the same.
• encounter-weighted — when a crawl resolves a third-party request through this list, what share of resolutions are right? Weighted by Tracker Radar prevalence — Tracker Radar's own per-domain figure for the share of the sites it crawls that request the domain, so gstatic.com at 0.40 is met on 40% of them. This is the number a paper's attribution error depends on. It is dominated by a handful of very common domains — gstatic.com alone carries 39.4% of webXray's — which is why its intervals are three times wider than the domain-level ones.

Counting granularity (right company, wrong level of the corporate tree) as acceptable rather than wrong — which is the right choice if your unit of analysis is “which company”, not “which legal entity” — the domain-level figures become webXray 80.2% (67.7–90.8), Tracker Radar 76.5% (63.5–88.0), Disconnect 98.8% (96.2–100.0). Full per-verdict tables, including stale and error separately, are in section B of the estimator's output on the appendix page.

Four further readings, each of which needs the sample and could not come from the disagreement table:

• error — a name that was never the owner — is rare in all three lists. Zero of webXray's 49 settled entries and zero of Disconnect's 42; the only one in Tracker Radar's 47 is elfsight.com, attributed to “Vladimir Fedotov”, who is Elfsight's co-founder and not the owning entity (elfsight.com/terms-of-service/ names Elfsight, SL). A zero cell's bootstrap interval is [0,0] and asserts nothing; the usable statement is the rule-of-three bound — below 6.1% for webXray and 7.1% for Disconnect at 95% confidence. Almost all list error is staleness, not invention.
• Tracker Radar is the list whose encounter-weighted accuracy is worst (68.6%), despite being the broadest — and the reason is partly that the three rates are not strictly on one axis. A brand name survives an acquisition and a legal-entity name does not: for crwdcntrl.net, “Lotame” scores current and “Lotame Solutions, Inc.” scores stale, on one fact about one company. A list that carries legal names is therefore penalised by this measure for being more precise. It regenerates monthly but carries legal-entity names, and legal names lag renames: zoominfo.com is still “Zoom Information, Inc.”, mountain.com “Mountain Digital, Inc.” for MNTN, 20min.ch “Tamedia AG” where the group renamed to TX Group, tvtime.com “Whipclip”. The interval is very wide (29.3–97.0%) because a handful of head domains carry the weight — but the point estimate being the lowest of the three, on the list most papers use, is worth knowing.
• The encounter-weighted column is concentrated enough that one domain moves it. gstatic.com alone carries 39.4% of webXray's encounter-weighted estimate, and webXray's top three drawn domains carry 53.1%; had gstatic.com been stale, webXray's 93.9% would read 54.4%. The equivalent heaviest rows are omtrdc.net for Tracker Radar (24.9%, and 68.6% would read 43.7%) and id5-sync.com for Disconnect (16.7%, 83.1% → 66.4%). That is not a defect in the estimator — it is what “weighted by how often you meet the domain” means when prevalence spans five orders of magnitude — but it is why the encounter-weighted intervals are three times the domain-level ones, and why the encounter-weighted column should be read as an ordering rather than as a number. The concentration figures and the flip test are printed by the estimator itself, in section C2 of its output.
• A third of the sample could not be settled at all, and the share rises toward the tail: 11, 13 and 18 of each 60 drawn rows. Those are domains that serve nothing, have no legal document and no newsroom, and only third-party aggregators to go on. Every rate above is therefore conditional on the entry being adjudicable, which is a real limit, not a footnote. And the shares are not equal — 18%, 22% and 30% of each list's draws — so if unadjudicable entries are worse than adjudicable ones, the list flattered most is Disconnect, the one this page recommends. The worst case, every unresolved entry being stale, gives 58.3% / 58.3% / 65.0%: it narrows the ordering's margin without reversing it.

One entry-shape figure comes out of the same work and needs no sample at all, because it can be counted over every pair in every file (scripts/owner_selfname_census.py): entities whose name is just a domain rather than a company — Disconnect's owner for cdnbasket.net is the string “cdnbasket.net”. That is 0.8% of the 3,215 domains webXray names an owner for, 0.7% of Tracker Radar's 38,368 and 3.2% of Disconnect's 7,850. An entry like that resolves to itself and tells a measurement nothing it did not already have; if your pipeline counts “domains with a known owner”, these should not be in it.

Every coverage and agreement figure on this page — everything above the random-sample section — comes from owner_dbs.py; every accuracy figure comes from owner_sample.py and owner_random_sample.py. All three are published in full, with their unedited output, on the provenance page and its appendix — 1,049 lines between them, and reading them is an audit task rather than a way to learn the topic. Each of the three prints the SHA-256 prefix of the exact bytes it computed from, so a figure quoted from any of them is pinned to a snapshot rather than to “the list”; owner_dbs.py fetches the lists live and prints the residue of every fold as well. Re-run it before citing any number here: two of the three lists move weekly.

Two rules in it are easy to get wrong and both change the answer. Do not use Tracker Radar's own entity_map.json or domain_map.json as the universe — that scores Tracker Radar at 100% by construction, where domain_summary.json is a crawl result and is defensible. And weight a registrable domain by the largest prevalence among its hostnames, never the sum, because one site can request both fonts.googleapis.com and ajax.googleapis.com and summing double-counts it.

Dated, because a list of what the literature did is not advice about what to do:

Figures below are from the seven venues on corpus (CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf, IEEE S&P, 2010–2026), not from the web-measurement literature as a whole.

15 papers name webXray anywhere in their full text — 0.3% of the 5,859-paper corpus, and 1.3% of the 1,120 papers that ran a crawl. The extraction's tool field fires on only 7 of them, because most of the rest cite it in a related-work sentence or a reference list; both signals are reported rather than merged. Every verdict below was read off a quoted sentence.

Three findings from that table matter more than the counts.

The tool and the database came apart, and then the database was superseded. The last corpus paper to use either was published in 2022. Ownership use of Tracker Radar begins in 2021 and rises through the corpus edge — [21Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)] is a 2026 example, using the Entity Map to avoid treating gmail.com and google.com as separate authentication systems:

The starred years are the provisional corpus edge — CCS 2026 and IMC 2026 have not been held, and IEEE S&P and TheWebConf 2026 are under-selected by construction — so do not read 2026 as a complete year. The counts are small enough that the crossover is a signal about direction, not a market share. Combined with the licence and 404 findings above, the corpus supports “webXray's ownership list is historical and Tracker Radar's is current practice”; it does not support any claim about which is more accurate, which is what the random-sample section is for.

Nobody says which snapshot they used. Of the 8 papers that used the crawler or the list, 2 say anything at all about which version, and 1 names a commit. That one, [15Matte, Célestin; Bielova, Nataliia; Santos, Cristiana Teixeira (2020): "Do Cookie Banners Respect my Choice? Measuring Legal Compliance of Banners from IAB Europe's Transparency and Consent Framework", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)], pins both lists it uses in a reproducibility table — “Disconnect list commit eb817fb1 (2019-12-10)” and “WebXRay commit 04c3c8e8 (2019-06-18)” — beside the Chromium build, the kernel, the user agent, the vantage point and the Tranco list id. Copy that table. The file has no version field and no release tags, so a commit or an archive URL is the only thing that makes the figure reproducible; owner_dbs.py prints a content hash for the same reason.

No list removes the manual work. [11Steffens, Marius; Musch, Marius; Johns, Martin; Stock, Ben (2021): "Who’s Hosting the Block Party? Studying Third-Party Blockage of CSP and SRI", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] is the most honest account of the real cost. They needed same-entity relations for the Tranco top 10,000, found that the curated lists “frequently miss connections among two hostnames, e.g., twitch.tv and twitchcdn.net”, mined their own crawl for candidates, and hand-vetted 2,175 candidate site pairs down to 1,146 confirmed same-entity pairs in about eight person-hours. webXray's list then contributed 133 further relations their own method had missed, and their conclusion was that “it alone does not suffice for our purposes”. Two lessons: budget the person-hours, and treat the lists as additive rather than as alternatives. [2Sánchez-Rola, Iskander; Dell'Amico, Matteo; Balzarotti, Davide; Vervier, Pierre-Antoine; Bilge, Leyla (2021): "Journey to the Center of the Cookie Ecosystem: Unraveling Actors' Roles and Relationships", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] took the same route from the other end — it merged Disconnect, WhoTracks.me and webXray by priority (“Disconnect first, WhoTracks.me second, and webxray third”, explicitly “preferring those that have been updated most recently”), added an automated WHOIS-and-graph pass “to increase the coverage”, found exactly one conflict against the 3,913 domains in any of the three lists, and filed a bug report that fixed an error in the Disconnect list.

How widespread is ownership resolution at all? A full-text sweep for the named resources gives 136 papers (2.3% of the corpus; 12.1% of those that crawled) that mention at least one. Each row is an upper bound — a match, not a verified use — except the two that were hand-verified in full:

[22Utz, Christine; Amft, Sabrina; Degeling, Martin; Holz, Thorsten; Fahl, Sascha; Schaub, Florian (2023): "Privacy Rarely Considered: Exploring Considerations in the Adoption of Third-Party Services by Websites", Proceedings on Privacy Enhancing Technologies 2023(1):5-28. (DOI)] is worth reading before you pick one: it compared five third-party categorisations, including WhoTracks.me and Tracker Radar, and reports that “categorizations differ in granularity and focus” while overlapping substantially — the granularity axis again, stated from inside the literature.

The step most often missing from a paper is not the lookup, it is what surrounds it. To turn a request log into “N% of sites contact Google”:

1. Extract the request host, and keep the visited site's host beside it.
2. Fold both to a registrable domain using the ICANN section of a dated PSL. Not the private section — see the trap above.
3. Resolve the request domain to an owner, walking parent labels rather than looking up the exact key, and record which key matched.
4. Resolve the visited site to an owner too, and drop the request if they are the same owner. This is the step that is almost always silently skipped, and it is what the ownership list is for: [20Wu, Xiaoyuan; Hu, Lydia; Zeng, Eric; Habib, Hana; Bauer, Lujo (2025): "Transparency or Information Overload? Evaluating Users’ Comprehension and Perceptions of the iOS App Privacy Report", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] describes webXray's list as “allowing distinction between first- and third-party domains”. Without it, google.com embedding gstatic.com counts as third-party tracking, and any site whose CDN is on a sibling domain is over-counted. eTLD+1 comparison alone does not do it — that is exactly why [11Steffens, Marius; Musch, Marius; Johns, Martin; Stock, Ben (2021): "Who’s Hosting the Block Party? Studying Third-Party Blockage of CSP and SRI", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] needed eight person-hours of hand-vetting.
5. Aggregate per site, not per request, and state the unit: “sites with at least one request to an owner” is not “requests”, is not “domains”, and is not “owners”.
6. Report the unattributed remainder twice: as a share of domains and as a share of sites or requests. Those differ by more than an order of magnitude here.

Every one of those six steps is a place where two papers measuring “the same thing” diverge, and only the third is about which list you picked.

If a result depends on attributing domains to companies, report all of:

• which list, which file, and which commit or content hash. “We used Tracker Radar” is not reproducible: name build-data/generated/entity_map.json at a commit, or publish the hash. For Disconnect, say whether you read properties, resources or the union.
• the date the snapshot was taken, separately from the crawl date. Ownership changes between the two.
• the granularity you resolved to — brand, operating legal entity, or ultimate parent — and, if you walked a hierarchy, how deep and how you handled cycles and missing parents.
• the fallback order, if you merged sources, and the conflict rule. [2Sánchez-Rola, Iskander; Dell'Amico, Matteo; Balzarotti, Davide; Vervier, Pierre-Antoine; Bilge, Leyla (2021): "Journey to the Center of the Cookie Ecosystem: Unraveling Actors' Roles and Relationships", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] and [12Yang, Zhiju; Yue, Chuan (2020): "A Comparative Measurement Study of Web Tracking on Mobile and Desktop Environments", in: Proceedings on Privacy Enhancing Technologies. (DOI)] both used strict priority orders and both said so; that is the standard to meet.
• how many domains you could not attribute, as a count and as a share of requests or sites, not just of domains. The two differ enormously: a list can cover 2.1% of domains and 58.6% of prevalence weight. Say which denominator your unattributed share uses.
• your privacy-proxy filter, if WHOIS was involved, and the list of proxy strings you removed.
• the eTLD+1 rule and the PSL version, since every one of these lists keys on the registrable domain and the PSL changes. Do not ship a frozen copy [8McQuistin, Stephen; Snyder, Peter; Perkins, Colin; Haddadi, Hamed; Tyson, Gareth (2023): "A First Look at the Privacy Harms of the Public Suffix List", in: Proceedings of the ACM Internet Measurement Conference. (DOI)].
• the manual verification you did, its sample size, and the disagreements you found. A prevalence-by-company figure with no manual check is a figure about a list, not about the web.

If the claim is “N% of sites contact Google”, the reader cannot evaluate it without the granularity and the snapshot: it silently includes or excludes YouTube, DoubleClick, Bing-adjacent Microsoft properties and whatever Alphabet has bought or sold since the file was written.

• The corpus audit script is scripts/report_webxray.mjs; the live-database comparison is scripts/owner_dbs.py; the hand adjudication of the 30 disagreements is scripts/owner_adjudication.py; the random sample is scripts/owner_sample.py (draw) and scripts/owner_random_sample.py (estimate), with owner_merge_rows.py, owner_verify_sources.py, owner_verify_rendered.mjs, owner_corrections.py, owner_verdict_fixes.py, owner_citation_audit.py and owner_selfname_census.py between them; the inter-rater re-adjudication is owner_irr_sample.py (draw and batches), owner_irr_corrections.py (citation failures) and owner_irr_kappa.py (agreement), guarded by check_irr_figures.py. Every query, every unedited output, the fold residues, the sources rejected, the corrections applied and the figures deliberately not published are on the provenance page and its code appendix. Corpus-wide selection and extraction caveats are on corpus.
• The webXray population is a full-text sweep, not the extraction's tool field, because the tool field finds 7 papers where the sweep finds 15 and the difference is exactly the citation-only cases this page needs to separate. All 15 carry a hand verdict with a quoted sentence; the residue between sweep and hand map is zero, and the script fails loudly if that changes.
• The 26 literal per-paper figures and quotes on this page were checked against each paper's paper.cols.txt rendering: 26 of 26 located. The 16 extraction evidence quotes behind the tool and classification tuples were checked the same way: 4 exact, 11 partial, 1 below threshold; the below-threshold quote is present in the source and mangled by a column splice, not unsupported.
• One figure was not published: [11Steffens, Marius; Musch, Marius; Johns, Martin; Stock, Ben (2021): "Who’s Hosting the Block Party? Studying Third-Party Blockage of CSP and SRI", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] contains the sentence “webXray's list does account for 1,096 of our 1,146 found connections meaning that it alone does not suffice for our purposes”, whose two halves contradict each other. The published PDF reads the same way, so no coverage percentage is taken from it; the unambiguous parts of that paragraph are quoted above instead.
• The coverage and agreement comparison uses a single snapshot per list, taken on 2026-08-17; the random sample uses a second set taken on 2026-09-05, and two of the six files had moved between them. Both sets of SHA-256 prefixes, and what the difference does to the frame, are on the provenance page. Two of the three lists change weekly. Re-run the script rather than quoting these numbers in 2027.
• The coverage denominator is Tracker Radar's own crawl output. There is no neutral census of third-party domains, so this favours Tracker Radar; the page says so wherever a coverage figure appears rather than pretending otherwise.
• The 30 adjudicated rows are the highest-prevalence disagreements, deliberately not a random sample, so they characterise the shape of disagreement and not any list's accuracy. Two rows (the acquisition date behind 360yield.com, and fwmrm.net's post-2026-spinoff status) could not be settled from a primary source and are recorded as unresolved rather than guessed.
• The random sample that does carry accuracy rates is a separate draw made on 2026-09-05: 60 domains per list from that list's own coverage, stratified into prevalence quartiles with allocation 24/12/12/12, seed 20260905. Its limits, in the order they matter: every rate is conditional on the entry being adjudicable, and 11–18 of each 60 were not; the frame is Tracker Radar's domain_summary.json, so it is Tracker Radar's view of the third-party surface and no list is scored on domains that crawl never saw; the encounter-weighted column is a ratio estimator concentrated in a handful of head domains — gstatic.com alone carries 39.4% of webXray's estimate, and its top three carry 53.1% — which is why its intervals reach 68 percentage points wide; and the brief asked for prevalence deciles where quartiles were used, because 60 draws over ten strata support no stratum-level statement. 29 of the 525 verdicts were changed after the adjudicators returned them — 26 by retiring a verdict the brief should never have offered (see the next bullet), 2 because they scored webXray's ownership-tree root rather than its entry, and 1 demotion to unresolved. The direction is overwhelmingly favourable to the lists and you should discount it accordingly: of the 28 re-scores, 14

landed on current, 2 on granularity, 1 on stale and 9 on unknown (which removes the row from every rate), and both of the root-scoring fixes made the verdict less severe. That is what retiring a verdict which had been firing on correct company names does. Separately, 10 of the 175 rows had their cited source or quote replaced after a machine re-fetch could not find the quoted sentence on the cited page; 9 of those 10 left the verdicts untouched. Every change is listed with its reason on the provenance page, and after all of them 0 rows are left citing a source a machine could not confirm.

• Inter-rater agreement was measured on 2026-09-11, not assumed: a random 20% of the sample (35 of 175 domains, seed 20260911) was re-adjudicated by a different model against the identical brief, giving pooled Cohen kappa +0.400 over 65 named verdicts at 58.5% raw agreement, and +0.680 on the rows both raters managed to settle. Roughly two-thirds of the disagreement is sourcing effort rather than reading. webXray's own cell is 12 rows and establishes nothing on its own. A self-named verdict (“the list's owner is just the domain”) was in the adjudication vocabulary and was retired mid-run: it fired on “TrustArc” and “Klaviyo”, which are the companies. The second rater, which had never seen that decision, reached for the same verdict 6 times in 105 cells — evidence that the defect was in the brief rather than in one adjudicator. Whether an entity name is a domain is a property of the file, counted over every pair rather than sampled, and it is reported that way above.
• The Wayback checks that failed on 2026-08-17 (web.archive.org was returning 502/503 all day) were redone on 2026-09-05. Both answers are bounds, not dates, because the Archive has no capture inside either window: github.com/timlib/webXray has its last archived HTTP 200 on 2023-03-31 and its first archived 404 on 2023-11-15, with nothing in between — consistent with peterjoles/webXray's last push on 2023-03-12, i.e. the fork was taken and then upstream went. github.com/timlib/webXray_Domain_Owner_List has a much wider window: last 200 2022-10-06, first 404 2025-01-18. webxray.org ran a live demo search engine over “scans of 100,000 sites” — with a company drop-down drawn from domain_owners.json — from 2022-01-23 to its last capture on 2024-03-28; on 2024-05-24 the site returned 401 Authorization Required, and from 2024-07-24 to at least 2026-02-05 every capture is a 301 to webxray.ai. The Archive has no capture of the present placeholder, so when the domain came back off webxray.ai can only be bounded to between 2026-02-05 and 2026-08-17. Before webXray, the same domain was something else entirely: from 2010-11-08 to at least 2011-09-27 it served a page titled “Web Xray - Free Website Data Mashup Tool” carrying a “beta 0.5” badge — a public directory of scraped sites with Google AdSense units. (Two separate elements, the <title> and a badge beside the logo, not one sentence. The domain's first archived capture, 2010-10-08, is a DreamHost parking page.)¹⁵⁾
• The seven-venue corpus omits EuroS&P, ACSAC, RAID, AsiaCCS, CHI and SOUPS, so “15 papers name webXray” is a statement about those seven venues. webXray's own author published most of its results outside those seven venues — his homepage lists The BMJ, JAMA, Communications of the ACM and New Media and Society¹⁶⁾ — so the corpus cannot see the work the tool's reputation mostly rests on, and “15 papers” is not a measure of how much webXray was used.

• Crawler — generic automation libraries and the other specialised crawlers.
• Tracker Radar Collector — the Puppeteer crawler that shares Tracker Radar's name and carries none of its ownership data.
• OpenWPM — the instrument webXray was compared against in 2016, and the one still maintained.
• Requests — filter lists, which answer “is this a tracker?” rather than “whose is it?”, and how the two get conflated.
• Cookies — where cookie attribution needs an owner name, and what the same granularity choice does to it.
• IP classification — the network-layer version of this problem, including AS-to-organisation mapping.
• Traffic files — capturing the requests you are about to attribute.

[1]

Libert, Timothy (2015): "Exposing the Invisible Web: An Analysis of Third-Party HTTP Requests on 1 Million Websites", International Journal of Communication 9. (Link)

[2]

Sánchez-Rola, Iskander; Dell'Amico, Matteo; Balzarotti, Davide; Vervier, Pierre-Antoine; Bilge, Leyla (2021): "Journey to the Center of the Cookie Ecosystem: Unraveling Actors' Roles and Relationships", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[3]

Dambra, Savino; Sanchez-Rola, Iskander; Bilge, Leyla; Balzarotti, Davide (2022): "When Sally Met Trackers: Web Tracking From the Users' Perspective", in: Proceedings of the USENIX Security Symposium. (Link)

[4]

Libert, Timothy (2018): "An Automated Approach to Auditing Disclosure of Third-Party Data Collection in Website Privacy Policies", in: Proceedings of the ACM Web Conference. (DOI)

[5]

Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[6]

Cui, Hao; Trimananda, Rahmadi; Markopoulou, Athina; Jordan, Scott (2023): "PoliGraph: Automated Privacy Policy Analysis using Knowledge Graphs", in: Proceedings of the USENIX Security Symposium. (Link)

[7]

Kashaf, Aqsa; Sekar, Vyas; Agarwal, Yuvraj (2020): "Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident?", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[8]

McQuistin, Stephen; Snyder, Peter; Perkins, Colin; Haddadi, Hamed; Tyson, Gareth (2023): "A First Look at the Privacy Harms of the Public Suffix List", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[9]

Selmo, Carlos; Carisimo, Esteban; Bustamante, Fabián E.; Alvarez-Hamelin, J. Ignacio (2025): "Learning AS-to-Organization Mappings with Borges", in: Proceedings of the 2025 ACM Internet Measurement Conference, pp. 120-133. (DOI)

[10]

Karaj, Arjaldo; Macbeth, Sam; Berson, Rémi; Pujol, Josep M. (2018): "WhoTracks.Me: Shedding light on the opaque world of online tracking". arXiv:1804.08959v2, revised 2019-04-25 (Link)

[11]

Steffens, Marius; Musch, Marius; Johns, Martin; Stock, Ben (2021): "Who’s Hosting the Block Party? Studying Third-Party Blockage of CSP and SRI", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[12]

Yang, Zhiju; Yue, Chuan (2020): "A Comparative Measurement Study of Web Tracking on Mobile and Desktop Environments", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[13]

Gouda, Deepak; Dainotti, Alberto; Testart, Cecilia (2025): "Prefix2Org: Mapping BGP Prefixes to Organizations", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[14]

Sørensen, Jannick Kirk; Kosta, Sokol (2019): "Before and After GDPR: The Changes in Third Party Presence at Public and Private European Websites", in: Proceedings of the ACM Web Conference. (DOI)

[15]

Matte, Célestin; Bielova, Nataliia; Santos, Cristiana Teixeira (2020): "Do Cookie Banners Respect my Choice? Measuring Legal Compliance of Banners from IAB Europe's Transparency and Consent Framework", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[16]

Musa, Maaz Bin; Nithyanand, Rishab (2022): "ATOM: Ad-network Tomography", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[17]

Cassel, Darion; Lin, Su-Chin; Buraggina, Alessio; Wang, William; Zhang, Andrew; Bauer, Lujo; Hsiao, Hsu-Chun; Jia, Limin; Libert, Timothy (2022): "OmniCrawl: Comprehensive Measurement of Web Tracking With Real Desktop and Mobile Browsers", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[18]

Kats, Daniel; Silva, David Luz; Roturier, Johann (2022): "Who Knows I Like Jelly Beans? An Investigation Into Search Privacy", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[19]

Jakaria, Md; Huang, Danny Yuxing; Das, Anupam (2024): "Connecting the Dots: Tracing Data Endpoints in IoT Devices", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[20]

Wu, Xiaoyuan; Hu, Lydia; Zeng, Eric; Habib, Hana; Bauer, Lujo (2025): "Transparency or Information Overload? Evaluating Users’ Comprehension and Perceptions of the iOS App Privacy Report", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[21]

Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)

[22]

Utz, Christine; Amft, Sabrina; Degeling, Martin; Holz, Thorsten; Fahl, Sascha; Schaub, Florian (2023): "Privacy Rarely Considered: Exploring Considerations in the Adoption of Third-Party Services by Websites", Proceedings on Privacy Enhancing Technologies 2023(1):5-28. (DOI)