A security report casts real-time online ad auctions in a new light: ads on Starlink devices could be used to collect data and, in the worst case, even deliver malware. What is proven, what is merely suspected and what companies should check now is presented here separately, according to the evidence.
Online advertising seems harmless. A banner appears, a video starts, an app shows an ad. Behind it runs a marketplace where, in fractions of a second, details about devices and locations go out to many companies. This process, real-time bidding, has been known for years and has long been criticized by data protection advocates. A current case involving Starlink devices puts it back in the headlines.
The following first describes the technology, then the case with its proven and unconfirmed parts. After that come the long-standing criticism from data protection advocates, the particular risks for business travelers and field staff, and a catalog of safeguards for devices, networks and your own website. The aim is context and options for action, not alarm. The case has not yet been fully resolved, and this text does not replace legal advice.
Real-time bidding explained simply: an auction with every page view
Real-time bidding (RTB) is an automated bidding process for ad slots. As soon as a website or app loads and contains a free ad slot, that slot is auctioned off. The process takes only fractions of a second, usually well under one second. Whoever wins the bid has their ad shown before the page has even finished loading.
Several roles are involved in the real-time auction:
- Publisher: the operator of the website or app offering the ad slot.
- SSP (supply-side platform): the publisher's technology provider that puts the slot up for sale.
- Ad exchange: the marketplace that distributes requests to many interested parties.
- DSP (demand-side platform): the advertisers' bidding software that places bids automatically.
- Advertisers: companies that want to show their ad.
The process starts with a bid request. The SSP packs details about the page view into it and sends it to the exchange. The exchange forwards the request to many bidders. Each bidder decides whether and how much to bid, comparing the details with its own profiles. The highest bid wins. The figure shows the process in simplified form.

One point is crucial here, and it often gets lost in industry explanations: the bid request goes to all participating bidders, not just the eventual winner. Those who lose have still received the data. On top of that comes so-called cookie matching, where ad companies sync their identifiers with each other so that a user can be recognized across different sites. A vivid description of this, including an example with an abandoned shopping cart, can be found in podcast episode 43 on real-time bidding (in German). The episode is opinionated and serves here as further reading, not as evidence for individual facts.
The large advertising platforms and their role as data collectors are also covered in the article about the data giant and real-time advertising. The technology is not limited to one provider but is a market standard.
What data is sent along in real-time bidding
What a bid request contains depends on the provider, the device and the page. The following bid request data is typical. The table also shows what can be inferred from it.
| Data field | Example | What can be inferred |
|---|---|---|
| IP address | Address of the connection | Approximate location, network operator, recognition of the same connection |
| Location | Region, city or exact coordinates | Whereabouts, with app data also movement patterns |
| ASN (network identifier) | Number of the network | Provider and type of connection, for small networks also the organization |
| Device type and operating system | Smartphone, notebook, version | Device model, update status, device class |
| Screen resolution and browser | Size, language setting | Fingerprint for recognition without cookies |
| Advertising ID | Random device identifier | Linking apps, visits and locations over time |
| Page or app context | Address, app name, category | Interests, profession, health or political views |
| Consent signal (TC string) | Encoded consent | Which purposes and partners were supposedly permitted |
There is a difference between browsers and apps. In the browser, cookies and the cookie matching mentioned above play a major role. In apps, by contrast, the advertising ID and often precise location data are available. Where no cookie may be set, device characteristics such as resolution, browser and language help with recognition, as described in the article on browser fingerprinting (in German).
The central question is therefore what is disclosed without any interaction at all:
What do devices reveal through real-time bidding, even if nobody clicks on an ad?
The Irish Council for Civil Liberties (ICCL) provides a figure on the scale. In its report from May 2022, the organization states that the industry exposes a person's online behavior and location in Europe 376 times a day on average, and 747 times in the US. The figure is an estimate from 2022 which, according to the ICCL report, is based on industry data, and should be seen as an indication of the scale, not an exact measurement.
In real-time bidding, all bidders see the data, not just the winner.
This leads to a structural problem. Once data enters the auction cycle, it is hardly possible to control where it ends up and what recipients do with it. A single request may seem harmless. Only the sum of many requests, collected over weeks and linked to an advertising ID, produces a detailed picture.
The Starlink case: who, where, how much
The current debate was triggered by a chain of reports. In mid-October 2026, the Citizen Lab at the University of Toronto published its report on "AdFection", a method in which advertising infrastructure is used for spyware attacks. This was followed by an analysis from the security firm TrendAI titled "Invasive Ads". The news coverage in this article is based on the report by heise online (in German), which reproduces TrendAI figures and a Reuters report. The TrendAI report itself and the Reuters report were not reviewed for this article. The following information is therefore as stated by heise, TrendAI and Reuters.
Based on these reports, the following picture emerges:
- TrendAI does not name the actor, calling it "Shadow-Earth-79". According to Reuters, citing six unnamed sources, this refers to the Israeli company Discover-Tech. TrendAI reportedly did not contradict this identification when asked by Reuters.
- In the 90-day observation period, Shadow-Earth-79 accounted for 12.9 percent of the advertising on Starlink devices. That is second place behind Steelhouse with over 38 percent, although this ranking applies to the 90 days. Steelhouse has since merged into the company MNTN.
- The factor is striking: the share in the Starlink segment was almost five times as high as Shadow-Earth-79's overall share. For Steelhouse, it is 2.2 times.
- Over the longer period from June 2024 to June 2026, Shadow-Earth-79 was the market leader in Starlink-related advertising in 105 countries. These include Germany, where almost every third ad slot on Starlink devices went to it.

According to TrendAI, the targeting is remarkable. It is said to aim not only at Starlink users in general but, in several countries, especially at government services whose devices go online via Starlink. In addition, the actor is said to be active in countries where Western advertisers do not normally operate, including sanctioned territories and regions with travel warnings.
The suspicion is that the actor is less interested in selling products than in harvesting data. In ad auctions, intermediaries receive information such as location, IP address, network identifier, device type and screen resolution. Combined with advertising ID, click tracking and location history, this can be used to build behavioral profiles. Tailored advertising could also deliver malware. As heise reports, this is a suspicion and not proof.
Exactly how the link to Starlink comes about remains vague in the reports. They speak of "Starlink-connected devices". Whether the ad slots were detected on devices behind Starlink connections or in specific networks cannot be clearly determined from the reports.
What is reported and what is open: spyware allegation and attribution
The case consists of parts with very different levels of evidence. A clean separation helps to neither play it down nor dramatize it. The Starlink figures come from secondary sources, while the Citizen Lab report is available as a primary source.

In its report No. 195 of October 15, 2026, the Citizen Lab describes technical evidence. According to it, at least 45 devices of the broadcaster Al Jazeera were targeted in 2024 and 2025 by attacks attributed with high confidence to Candiru's spyware. Discover-Tech's Controlium platform allegedly allows customers to select devices by advertising IDs, browser IDs or IP addresses and to serve them malicious code. Around four billion bid records from March to June 2026 were analyzed. They show ads in almost 200,000 apps and websites, including networks of governments, the military, media and critical infrastructure.
At the same time, the Citizen Lab itself points out a limitation: the fact that an ad was served to a device does not prove an infection. Impressions alone do not amount to an attack.
An ad alone does not prove an infection.
Several points are unconfirmed or disputed:
- Spyware allegation: It comes from the Citizen Lab. According to heise, TrendAI does not repeat it. The data it collected was not sufficient for that.
- Attribution: Equating Shadow-Earth-79 with Discover-Tech comes from Reuters sources, not from the TrendAI report itself.
- Intent: That the aim is data harvesting is a suspicion. TrendAI considers the scripts examined to be consistent with tools for surveillance and data collection, which is something different from proof.
- Statement: According to heise, Discover-Tech was invited to comment. No response is mentioned.
An industry reaction is also reported: according to the Citizen Lab report, Google, IAB Europe and Beeswax have removed Discover-Tech from their systems. However, the Starlink-related advertising as such is not proof of an attack. It is an indication of a conspicuous pattern. For data protection officers, the case is therefore above all a practical example of what the auction structure fundamentally makes possible, and not a verdict on a single company.
Why data protection advocates have criticized real-time bidding for years
Criticism of the real-time auction predates the Starlink case. The core issue: personal data goes to an unmanageable number of recipients whom users do not know and with whom they have no relationship. Consent under Article 6 GDPR would have to be informed and freely given. With hundreds of possible recipients in a banner, that is hard to imagine. In addition, once data has been passed on, deletion is practically impossible to enforce.
Access to the end device is also subject to rules. Anyone who stores or reads information on a device generally needs consent to do so, as regulated in Germany by the Telecommunications Digital Services Data Protection Act (TDDDG). This applies to cookies as well as to reading device characteristics.
On March 7, 2024, the Court of Justice of the European Union ruled in case C-604/22 concerning IAB Europe. According to the expert commentary published on it, the TC string, the encoded consent of users, can be personal data, and IAB Europe can be jointly responsible with its members for collecting it. According to the commentary, this does not automatically apply to all downstream processing in the bidding process. For details, the wording of the judgment is authoritative; the summaries are secondary sources.
As an assessment, it can be said that data brokers or other parties could act as silent eavesdroppers. Anyone who receives bid requests can store the information, and the sender has no technical control over this. This is not proven for every individual case, but it remains a structural risk. The Starlink case serves here as practical evidence of this structural risk, not as a legal ruling.
For background on the connection between consent and tracking, see the article on tracking. Whether consent-based purposes are also adhered to technically is a separate question, which comes up again below in the section on your own websites.
Risks for business travelers, field staff and public authorities
Why are Starlink devices in particular an issue? According to the reports, several characteristics play a role. Satellite connections often have only a few users per network. They are used in remote regions. They are also deployed by public authorities, aid organizations and in conflict zones. Anyone buying ads there in a targeted way reaches a small, potentially interesting group with little wastage. The assessment that government services are the focus comes from TrendAI and is an assumption.
Quite a lot can be inferred from bid request data. The IP address and network identifier roughly reveal the location and, for small networks, the organization. An advertising ID links individual visits into a history. With precise location from an app, a movement profile emerges. These inferences also apply beyond Starlink.
Practical situations, without dramatization:
- Field staff using a mobile hotspot: all devices share one IP address, but device characteristics still tell them apart.
- Hotel Wi-Fi on business trips: the network reveals the location, even without GPS.
- Construction sites or branch offices with a satellite connection: a small network can be attributed to an organization.
- Travel to countries with travel warnings: according to TrendAI, conspicuous advertising behavior was observed there.
A simple risk classification helps. The risk is low for office work on the normal company network with standard devices. It is elevated for frequent travel, access to confidential information or deployment in conflict regions. It is high for people who may be considered targets, for example in the media or government sphere. Measures of varying strictness follow from this.
Safeguards on devices and in the network
There is no complete protection against data being passed on in the ad auction. But there are measures that reduce the data disclosed and the attack surface. The overview shows priorities by effort.

Quick to implement
- Disable the advertising ID: On Android, the advertising ID can be deleted in the settings. On the iPhone, tracking can be refused per app. How this can be controlled centrally depends on the mobile device management (MDM) and the manufacturer. Specific policies must be checked against the respective manufacturer's documentation before use and are not given here as a blanket recommendation.
- Restrict location sharing: Allow access only while the app is in use and turn off precise location where it is not needed.
- Install updates promptly: Against so-called zero-click attacks, which work without any user interaction, up-to-date operating systems and browsers help most. For particularly vulnerable people, Apple, for example, offers a Lockdown Mode. Details can be found in the manufacturer's documentation.
Medium effort
- Ad blockers on company devices: Browser extensions or a DNS filter on the company network block many ad requests before the auction even starts. The limitations: apps often use their own channels, encrypted DNS queries (DoH) can bypass the filter, and the blocklists need maintenance.
- Browsers with tracking protection: Modern browsers block third-party cookies and known trackers. This is not complete protection either, but it noticeably reduces the data flow.
Extensive
- Inventory apps with ad SDKs: It must be checked which apps run on company devices, which ad components they contain and whether they are needed. Apps that are not needed should be removed.
- Do not regard satellite connections as protection: Changing IP addresses and device identifiers do not prevent recognition if other characteristics stay the same.
For your own website, there are also the Web Security Checks. They do not replace a device policy, but they help to find weak spots. For business travelers, a simple principle also applies: the fewer apps with ads, the fewer bidders see the device.
Real-time bidding on your own website: check consent and ad partners
The case concerns not only users but also operators of websites and ad slots. Anyone who serves ads themselves is part of the chain and passes their visitors' data on to the exchange. Marketing managers should therefore be familiar with the data protection issues surrounding RTB in the company. The consent management in the ad setup must do exactly what the banner promises.
A checklist for your own website:
- Know your partners: Which SSPs, exchanges and header bidding partners run on the site? The list should be in writing and up to date.
- Test the banner: Does consent really trigger only the selected services? Are third-party services loaded before consent is given? This can be observed in the Network tab of the browser's developer tools. Criticism of loading before consent is also a topic in the podcast episode (in German).
- Read the TC string and vendor lists: Which partners appear in the vendor lists, and does that match the contracts?
- Contracts and auditability: Only give ad slots to partners with whom a contract exists and whose processing is traceable.
- Consider an alternative: Contextual advertising, which targets the environment of a page rather than people, works without personal data.
- Follow up after the case: Has Discover-Tech been removed from the vendor lists? You can ask your ad service provider in writing.
Two background articles (in German) are helpful: the guide to consent tools on websites and the question of how far Google Consent Mode really goes. If you want to measure success, the article on conversion tracking without data protection problems offers alternatives, and on the risks for advertisers there is an article about Google Ads.
Which ad services load on your own website?
The GDPR website check shows which third parties receive data as soon as the page is opened.
Conclusion: what data protection officers, admins and marketing should do now
The tasks are divided among three roles. Data protection officers clarify whether and for whom there is an elevated risk, and determine which device policies apply. They document the decision and point out its limits. Admins implement the technical requirements: advertising ID and location on company devices, network filters, updates. Marketing and web managers review their own chain of ad partners and the behavior of the consent banner.
The Starlink case has not yet been fully resolved. Figures and attribution come from reports whose primary sources were not reviewed. The spyware allegation comes from the Citizen Lab and is not repeated by TrendAI. Statements from those named are still pending. This article does not replace legal advice.
In the end, the case does not describe an exception but makes the way the system works visible. As long as real-time bidding distributes data to all bidders, protection depends on the behavior of individual participants. In the author's view, this is the actual design flaw, which can only be fixed by less data in the auction, not by more trust in the participants.




My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
