Free DecryptAds service maps which ad networks and data brokers are permitted on a website or app
Public adtech disclosure files reveal more than most site owners realise, and reading them is a skill anyone can pick up in an afternoon.
Security journalist Brian Krebs reported on 14 August on DecryptAds, a free service that collects and cross-references publicly published advertising-technology files to show which companies are permitted to serve ads on, or gather data from, a given website or app. The information has always been semi-public, but it is scattered across many domains and difficult to interpret without tooling, and much of it has in practice stayed inside the large advertising platforms.
The service works from three kinds of disclosure file. A site's ads.txt lists the adtech companies and data brokers authorised to sell its ad inventory. app-ads.txt does the same for mobile and smart-TV apps. sellers.json and buyers.json files, published by the intermediaries themselves, describe who is buying, selling or reselling that inventory. DecryptAds scrapes these files and links them, so a user can enter a domain and see the chain of partners behind it.
Krebs cites several examples from the tool. ESPN.com shows 143 ad partners and 19 registered data-broker domains, around half of which collect visitor geolocation. A Russian-based adtech firm, Between Digital, appears on military-news properties including Army Times, Navy Times, Defense News and Federal Times, and on roughly 55,000 partner sites overall. The Opera browser, majority-owned by China's Kunlun Tech since 2016, lists 27 registered data brokers.
Zach Edwards, chief research officer at DecryptAds and also affiliated with the security company Infoblox, is one of three founders. The service flags partners based in jurisdictions such as China, Russia, the UAE and Cyprus as higher risk, a categorisation that matters most for sites with sensitive audiences.
Why it matters
Adtech supply chains are one of the least-inspected parts of the web, yet they decide which third parties can run code and read signals on a page. The standards that make this analysis possible, ads.txt and sellers.json, were designed for fraud prevention, and this tool repurposes them for privacy and security review. Mining transparency files intended for one purpose to answer a different question is becoming a recurring technique in security research. Site owners should expect more direct questions about who sits in their ad chain and where those companies are based.
Adtech supply chains are one of the least-inspected parts of the web, yet they decide which third parties can run code and read signals on a page.
Publisher ads.txt
Plain-text file on the site listing exchange domains and account IDs allowed to sell its ad inventory
Exchange sellers.json
JSON file published by each exchange naming the entities behind those account IDs
Reseller chain
Intermediaries reselling to other intermediaries, each hop another recipient of bid data
Correlated view
DecryptAds joins the files so one domain lookup shows every partner and broker in the chain
What you can learn from this
- ads.txt is an allowlist published by the site itself. The Authorized Digital Sellers standard from the IAB Tech Lab asks each publisher to host a plain-text file at /ads.txt listing the exchange domain, the publisher's account ID on that exchange and whether the relationship is DIRECT or RESELLER. Buyers check the file before bidding so they can reject inventory that impersonates the site. Because it is public and machine-readable, anyone can fetch it and see the same list, which is exactly what DecryptAds does at scale.
- sellers.json is the same idea from the other side. Each exchange or reseller publishes a JSON file naming the entities it sells on behalf of, with a seller ID, a type such as publisher or intermediary, and usually a company name and domain. Joining a site's ads.txt entries against the matching sellers.json records reveals the actual companies behind opaque account numbers. Intermediaries that resell to other intermediaries form chains, and each hop is another party with access to bid-request data.
- A bid request leaks more than an ad slot. Programmatic advertising works by broadcasting a description of the impression, including page URL, device details, approximate location and identifiers, to many potential buyers in an auction. Every recipient receives that data whether or not it wins. This is why the number of ad partners on a page is a privacy measure in itself, and why geolocation collection was the detail that stood out in the ESPN example.
- Jurisdiction is a risk attribute, not a verdict. The country where a data recipient is incorporated determines which legal processes can compel it to hand over data and which sanctions or export rules apply. A partner in a sensitive jurisdiction on a hobby blog is a footnote, while the same partner on a defence-news site is a supply-chain question. Risk scoring should combine who is receiving data with who the audience is and what could be inferred about them.
- Third-party JavaScript is the mechanism behind the disclosure. Ad partners are typically loaded through script tags or header-bidding wrappers that execute in the page with the same privileges as the site's own code. That code can read cookies, fingerprint the browser and call further domains of its own choosing. Transparency files tell you who is allowed in; the browser's network log tells you who actually shows up, and the two lists rarely match exactly.
We teach this
How to use this in practice
- Read your own site's ads.txt and follow the sellers.json chain. Run
curl https://yourdomain/ads.txtand count the lines; for each exchange domain listed, fetchhttps://<exchange>/sellers.jsonand look up your seller ID. Done looks like a spreadsheet with one row per partner, the relationship type, and the company name resolved from sellers.json, plus a note beside each entry that nobody on your side recognises. Repeat the check for app-ads.txt if you publish a mobile app, since that list is often longer and less curated. - Capture what actually loads on a page. Open a site in a browser with the developer tools Network tab visible, filter to third-party domains, and export the session as a HAR file. Compare it against the ads.txt list to find domains that load but are not declared, and declared partners that never appear. Run the capture twice, once on the homepage and once on an article page, because ad loads differ by template. Done means a two-column diff you could hand to whoever manages advertising for the site.
- Draw the bid-request data flow. Sketch the boxes: browser, publisher page, header-bidding wrapper, supply-side platform, exchange, demand-side platforms, and the data brokers attached to each. Mark on each arrow which fields travel with it, such as URL, IP-derived location, device ID and consent string. Done is a one-page diagram a colleague can use to explain why one page view reaches dozens of companies.
- Test the consent controls. Load a site in a fresh private window, decline non-essential cookies, then reload and re-check the Network tab to see which ad domains still fire. Repeat the exercise with a request-blocking extension enabled and note the difference. Record the date, browser and extension versions so the test can be repeated next quarter. Done looks like a short list of partners that continue to load after refusal, which is the list worth escalating to whoever owns the consent banner.
Sources
- Who's Tracking You? Use This New Service to Find Out — Krebs on Security
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report