At AdGuard, we develop a whole range of privacy tools: an ad blocker, a VPN, a DNS service, an email service, and soon — a crypto wallet. These products do a lot of complex things under the hood — but they need to stay simple and friendly on the outside.

Our users come from all over the world. Many of them don’t speak English natively, many aren’t tech-savvy. And yet we want all of them to feel supported while using our tools.

In this post, I want to show you how we at AdGuard approach UX design and copy:

• What our writing and design are built on
• How we handle different levels of user experience
• How feedback and real-world constraints shape the final result
• And how you can help us make it better

Let’s begin with the foundation.

What we build on: Our principles

At AdGuard, we like to say that we’re on the light side of the Internet. This idea runs through everything we do.

• We care about transparency and openness
• We actively show it — help users, explain things, or just get out of their way when needed
• We give the control to the user. We believe the product should adapt to the user — not the other way around

Here’s what it looks like in practice.

Transparency → Clean UI, clear copy

We try to keep interfaces as clean as possible, with just enough visual and textual information to help you complete the task.

One button to enable protection

Active care → Help that’s always there

In our apps, you’ll often find small hints, tooltips, and summaries. Where needed, we add short explanations or links to longer articles — so you can dive deeper when you want to.

What users see when adding a custom filter

User control → Deep functionality, optional complexity

Most of our apps are layered. If you want to just turn on protection and move on, that’s great. If you want to dig deeper, you’ll find detailed settings, expert modes, and customizations. Your control is not necessary, but if you seek it, we’ll do our best to provide it to you.

Additional settings are shown when you choose to customize further

Our audience: How we approach different needs

Not everyone uses AdGuard the same way.

Some want to set it and forget it. Others enjoy tweaking settings and learning more about how privacy works. We try to support both.

Here’s how we approach it.

Layered experience

You can think of our apps as layered systems:

• Simple on the surface — for those who want quick protection
• Customizable in the middle — for those who are curious to learn and tweak things a bit
• Deeply configurable — for power users who want full control without hand-holding

This approach helps us keep the UI clean, while still offering depth for those who need it.

One example is our User rules feature — a tool that allows users to create custom filtering rules.

Our previous approach was designed for advanced users only. There was a blank input field and a link to the documentation.

Old User rules unterface

Now, in AdGuard Mini for Mac, we’re trying something new: a guided interface that walks you through the process.

Creating a user rule in AdGuard Mini for Mac

We explain what the rule does, where it applies, and how it works. We hope this makes it easier to get started, even if you’ve never written a rule before.

Let us know what you think: is it clear? Easy to follow? Missing something? Your feedback helps us decide whether to bring this approach to other platforms too.

Vocabulary

To meet users where they are, we adjust the vocabulary based on how familiar they might be with the topic and what they’re trying to achieve.

• AdGuard protects you from ads and trackers — for those who just want peace of mind online. This works well when the user’s goal is simple: “I want the ads gone,” or “I want to feel safer.”
• AdGuard blocks known analytics and phishing domains — for users who already understand the basics of online threats and want more transparency: “I know different types of tracking and risks exist, and I want to manage them more consciously.”
• AdGuard lets you apply advanced cosmetic rules and scriptlets from custom lists — for experienced users who want full control, less explanations and more just tools: “I know what I’m doing; just let me configure it.”

Feedback: Where we learn what works

We’re constantly learning from you — and trying to reflect that in the product.

Sometimes the insights come from anonymous usage data. For example, we noticed that some users were ignoring the “card” about HTTPS filtering on the main screen. Without HTTPS filtering, however, most ads cannot be blocked. So we changed the wording on that “card” — and the result was immediate: the number of users who enabled the feature increased by about one and a half times.

New wording (right) drives more taps than the old one (left)

Sometimes feedback comes from support requests. One user once asked where they could find their VPN license key. The thing is, AdGuard VPN doesn’t use license keys — the subscription is simply tied to the email address used for purchase. So we added a short explanation to the confirmation email that users receive after buying a license. After that, questions about VPN license keys practically disappeared.

Post-purchase email for AdGuard VPN users

Constraints

We can’t implement every idea we come up with — and that’s not a bad thing. Constraints shape our work and help us better understand how and what to communicate to users. Here are a few examples of these constraints — and how we deal with them.

Legal text

We’d love for all our texts to be friendly and concise, but in some cases we need to be legally precise to avoid any ambiguity. That’s why you may come across legal wording in our products — but whenever possible, we also provide a shorter, clearer summary to help you understand it quickly.

Excerpt from AdGuard’s Privacy policy

Localization

We build products for a global audience, and they are translated into 20+ languages. Even though we try to cover as many languages as possible, there will always be users who interact with our apps in a language that isn’t their native one. That means when we write in English, we have to keep in mind that not only native speakers will read it:

• Vocabulary and syntax shouldn’t be too complex
• We avoid local jokes, idioms, and wordplay that only native speakers would understand

Another constraint is how translation works in practice. We have several in-house translators and a group of dedicated volunteers who help us a lot (you can join too — read how). But in some cases, we have to rely on machine translation — and it’s much harder to provide context there.

This leads to a few additional rules:

• Limit the amount of information in one message — English words are often shorter than their equivalents in other languages
• Whenever possible, write in full sentences and avoid ending strings with prepositions — this can make translation more difficult

Let’s take another look at the User rules section.

When we were designing it, our initial idea was to make it feel like natural English: “Block request to ads.com.”

But in many languages, that structure wouldn’t work:

• Slavic languages use grammatical cases
• Turkic languages use postpositions, not prepositions
• Asian languages often require more context

So we rewrote it as “Block requests to this domain.” It’s longer, but clearer for most of the users — and translators.

UI element for creating new rules in different languages

What’s next — and how you can help

Here’s a funny paradox: we’re a privacy company, so we collect as little data as possible. But that makes it harder to know which parts of our apps are most useful and which are confusing. We’re working on privacy-friendly ways to learn more about how you use AdGuard — so we can make things simpler, clearer, and more useful.

One small thing you can do to help: turn on the setting called Send anonymized app usage data. You’ll find it in AdGuard Ad Blocker, AdGuard VPN, and AdGuard Mail.

This option doesn’t send anything personal. We don’t collect identifiers, track you, or share your data with anyone. But it does help us see which screens people interact with — and which features need improvement.

Our next step is to rely more on insights like these when making product decisions. They help us see what really matters to users — and guide us in making AdGuard apps even clearer, more intuitive, and more helpful for you.

If you see something confusing — or something that worked well for you on our apps and websites — please let us know by clicking the button below.

We use every opportunity to make our apps clearer, more helpful, and closer to what you actually need!

What doesn’t feel like part of the deal, though, is a dating platform sharing your sensitive information, photos, and location data with some AI company you’ve never even heard of, and doing it without your consent. That crosses a line and constitutes a breach of trust. But that’s exactly what OkCupid, a dating app owned by Match Group (which also owns Tinder, Hinge, and Plenty of Fish), did.

And what’s worse, when it was found out, the punishment it received was little more than a slap on the wrist.

When user data is seen as the company’s property

In a proposed settlement that OkCupid and its parent company, Match Group, reached with the US Federal Trade Commission (FTC) in March this year, the government alleged that the app was “deceiving” users by sharing their personal information — including photos and location data — with an unrelated third party. This was done without users’ knowledge or consent, and in violation of OkCupid’s own privacy promises.

At the time of the violation — back in 2014 — OkCupid’s privacy policy stated that it could share user data either with “service providers,” business partners, or affiliated companies, or otherwise only after explicitly informing users and giving them a chance to opt out. But that’s not what happened. The FTC found that OkCupid shared the information of potentially millions of users, including up to 3 million user photos, with an AI company called Clarifai. That company was none of those things — not a service provider, not a partner, not an affiliate — and OkCupid never asked users for consent, nor gave them any chance to opt out. In practice, that left millions of people completely unaware that their data was being repurposed behind the scenes.

How and why did that happen? The explanation is fairly mundane. OkCupid’s founders had a vested interest in Clarifai, which later used those 3 million photos and other user data to develop facial recognition and image-processing tools. Namely, they had invested in the company and treated OkCupid as a convenient source of data. As Ars Technica reported, Clarifai’s CEO acknowledged that the data helped them build a system that could “identify the age, sex and race of detected faces,” meaning users’ photos were turned into training material for the tool they never agreed to support. The FTC noted that, for years, OkCupid tried to deny having any relationship with the AI firm.

On paper, this might have been framed as acceptable under vaguely worded policies. But in practice, OkCupid was treating user data as if it simply belonged to them. That runs against the spirit of the privacy promises they made. Because what the policy suggested and what the users reasonably believed was that their data would only be used in the ways explicitly described. And training AI models was never part of that.

To see how problematic that behavior is, consider a simple thought experiment: imagine the founders hadn’t invested in an AI company, but in something like a car insurance broker or a health insurance firm, and then casually gave that completely unrelated business access to sensitive user data collected through OkCupid. The data could then be used, for example, to infer people’s lifestyles, sexual orientation, or health risks and then influence their insurance rates or eligibility — in other words lead to negative real-world consequences for users based on the data they never knowingly shared for that purpose.

Slap on the wrist

You might think such egregious mishandling of user data would come with serious penalties. But that wasn’t the case. As part of the settlement, OkCupid was essentially just barred from misrepresenting its data collection practices and privacy controls going forward. No steep fines — in fact, no fines at all — and no real long-term consequences beyond the obligation to comply. In theory, people affected could still try to sue in civil court, but that’s a long shot, especially since Match did not admit any wrongdoing.

Source

This type of punishment is hard to take seriously. In effect, that's not a penalty, it’s a mere restatement of the rules. What this basically amounts to is being told not to do something they weren’t supposed to be doing in the first place. That makes the whole thing feel less like enforcement and more like a pinky promise. And that’s a hard sell, coming from a company that already showed it was willing to stretch or rather ignore its own promises when it suited it.

Sharing user data without consent: the rule, not the exception

OkCupid’s case is only the most recent example of this kind of possessive attitude toward user data. But while some argue — Match Group among them — that times have changed and such permissive practices are long behind us, that couldn’t be further from the truth. Cases of companies mishandling user data often by quietly sharing or outright selling it without clear consent have been piling up in recent years.

Take Grindr. In recent years, the app faced major penalties across Europe after it was found to be sharing highly sensitive data, including sexual orientation, precise location, and advertising identifiers, with hundreds of advertising partners without valid consent, leading to a $6.1 million fine in Norway and ongoing mass legal action in the UK over the alleged sharing of HIV-related data with advertising firms.

Or another dating app, Raw, where in 2025 a security lapse exposed users’ exact, street-level locations along with personal details like sexual preferences and birth dates.This kind of exposure doesn’t just create online risks — it can translate into real-world vulnerability. Adding a more dystopian edge, the incident came at a time when the company was exploring making a wearable device meant to monitor partners’ physiological signals, raising obvious concerns about surveillance layered on top of already shaky data practices.

And it’s not just dating apps. In 2024–2025, General Motors and its OnStar unit were found to have quietly collected detailed driving behavior. This included data on braking, speed, and location, which was later sold to data brokers, and then used by insurers to raise premiums, in some cases dramatically. Again, there were real-world financial consequences for users. The FTC ultimately banned the practice for five years following an investigation into it.
Similar patterns have shown up elsewhere too — from networking platforms like LinkedIn to data brokers and even security software. In all of these cases — and there more waiting to be discovered — user data was quietly repurposed, shared, or sold without people ever really knowing. If anything, they show that the idea that privacy promises are little more than hot air hasn’t really gone away.

What this actually means for users

It’s easy to treat these cases as abstract violations or regulatory issues, but the consequences are anything but abstract. When this kind of data is shared, leaked, or repurposed, it can expose deeply personal information: from sexual orientation and health status to precise location history, and often to parties users never even knew existed.

That can lead to anything from targeted manipulation and profiling to real-world risks, like harassment, discrimination, or financial penalties, as seen with insurance data. And once that data is out there, there’s no real way to take it back or control how it’s used next. And as more systems start relying on collecting this kind of data, the stakes only get higher.

This is becoming especially clear with newer practices like age verification, which is seeing growing adoption around the world and often requires users to hand over highly sensitive information, such as facial scans or government IDs.

The higher the stakes, the bigger the problem

So, while the risks and concerns aren’t new, the situation is getting progressively more precarious. Take firms like British age verification leader Yoti which was recently found to be collecting and retaining biometric data without valid consent — or Discord, which introduced ID-based age verification and then landed in hot water after that data was exposed in a breach. In both cases, users were asked to hand over highly sensitive data, only for it to be mishandled or exposed.

The world as a whole is moving towards more data collection for the sake of convenience. We’re increasingly surrounded by technologies built on the same premise — from home surveillance systems like Ring to city-wide tracking networks like Flock, which use AI-powered cameras to log license plates and vehicle details into searchable databases.

But even though these innovations are touted as a boon to security, these are all part of the same underlying problem. You’re expected to trust that these systems won’t be hacked, and at the same time trust that companies won’t misuse your data. But we’ve already seen both happen, often without users even knowing. Even when policies sound reassuring, there are always people inside organizations with access, and it only takes one misuse or one bad apple.

Which is why things like mass data collection, behavioral tracking, or always-on monitoring — whether it’s framed as safety, personalization, or innovation — feel progressively less like features and more like liabilities. Because when something goes wrong, it’s the users who deal with the fallout, not the companies collecting the data. We are expected to trust the companies to do the right thing, and rely on someone to catch it when they don’t (if you’re lucky). Maybe that’s always been the case. But as long as there are no real consequences — as the OkCupid case has shown — there’s very little incentive for them to do anything differently next time.

It’s that time of year again — AdGuard’s annual look at the hidden side of your internet traffic. We’re talking about all the extra traffic your browser has to handle that isn’t the content you actually clicked on — but requests to ad networks, trackers, and other hidden services that quietly run in the background every time you load a page. The whole process happens behind the scenes, like an invisible internet tax. The pages you want still load, but at the same time your data is quietly feeding ad networks and trackers, paying for content in ways you never agreed to. Almost every click becomes part of a massive, invisible marketing machine that monetizes your habits without your knowledge.

Most people don’t talk about this. It’s treated as an unspoken agreement between website owners and marketers, where you — the user — apparently aren't supposed to have any say in the matter.

We’re not claiming to fix the system, that would be a tall order. But we do want to shine a light on what’s happening behind the scenes and show you just how much it costs in wasted traffic. We determined that ad trackers — our umbrella term for ads that are also trackers, and almost all of them are — accounted for roughly 10.22% of global internet traffic in 2025 — but this only reflects the initial, “raw” requests. The real numbers are even worse: many ad trackers, if unblocked, can trigger a chain of hidden tracking requests, which we call “hidden ad trackers.” Before we dive into the numbers, though, it helps to understand how these requests actually multiply behind the scenes.

Hidden ad and tracking requests — what are they

Whenever you visit a web page, your browser doesn’t just load the content you see, it also makes a series of requests to external servers, many of which are for ads or trackers. Some of these requests trigger additional requests behind the scenes: for example, a single request to an ad server (a primary request) can prompt several secondary requests to related services, which, in turn, can trigger even more requests, creating a cascading chain of network activity. To estimate the impact of these hidden chains, we calculated that each blocked primary DNS request prevents, on average, about four additional requests from ever being sent — 4.17 to be precise. That means that without blocking these “bad” requests, ad trackers could account for up to 40% of global internet traffic.

It’s getting worse: more ad trackers in 2025 than in 2024

Our findings suggest that ad and tracker-generated traffic continues to grow, and that growth shows no signs of slowing down across the board. In 2024, ad trackers accounted for about 7.84% of global internet traffic, but in 2025 that figure has, for the first time since we started conducting this survey in 2023, climbed into double digits, reaching 10.22%. This increase may partly be explained by improved filter capabilites, but it could also reflect a broader trend: a growing share of internet activity consists not of the content users actively request, but of background requests generated by advertising systems, tracking services, and the infrastructure that supports them.

Overall, the numbers suggest that advertising-based surveillance is becoming a more significant part of everyday web traffic. While this doesn’t necessarily mean a worse user experience in visible terms — as the era of large, intrusive banner ads is slowly fading — it does mean that more of the internet’s bandwidth is being consumed by systems operating in the shadows, often without the user’s explicit awareness or consent.

North and Central America: widespread increase

Across North and Central America, ad and tracker-related traffic has gone up almost everywhere with a very few exceptions. What was already a noticeable share in 2024 has significantly increased in 2025, with many countries now sitting in a similar 10–13% range, in line with the global average.

Larger countries have set the tone for the overall trends in the region. The US rose from 6.61% to 10.25%, moving into double digits and showing that this is a broad, system-wide change, not something limited to smaller countries. Mexico increased from 7.49% to 11.61%, accounting for one of the biggest jumps among major economies in the region. Canada (from 6.49% to 9.86%) follows the same pattern, moving close to the 10% level. Jamaica (from 6.01% to 11.43%) also stands out, joining the higher group of countries.

In the Caribbean, several countries are now among the highest in the world in terms of ad and tracker-related traffic share. Trinidad and Tobago (6.33% → 12.94%) is one of the most striking examples, doubling in a single year. Haiti (6.32% → 10.24%) and Puerto Rico (6.49% → 9.84%) have also shown steady increases, joining the wider regional upward trajectory. Cuba is the only clear exception, slipping slightly from 11.44% to 10.04%.

What stands out most in this region is how similar the trend is across very different countries. Large countries like the US and Mexico are moving in the same direction as smaller Caribbean and Central American countries, making the overall landscape more uniform and ad-heavy.

Latin America: steady rise

South America shows one of the clearest and most consistent upward trends in ad and tracker-related traffic. Across almost all major countries, values have moved from the mid–single digits in 2024 into the 10–12% range in 2025. Just like it was the case with North and Central America, the change is not driven by a few isolated spikes, but rather by a broad shift happening across the entire region.

The strongest increases come from the Andean countries. Peru stands out with one of the biggest jumps in the region, rising from 6.60% to 12.51%, which effectively amounts to doubling in just one year. Colombia follows a very similar pattern, increasing from 7.53% to 11.59%, while Ecuador moved from 6.37% to 11.48%.

Further inland, the relative growth is even more striking. Bolivia rose from 4.82% to 10.97%, and Paraguay from 5.97% to 11.42%. Both moved quickly into double-digit levels. This reflects a catch-up effect, where countries that were at lower levels last year are now quickly reaching the same range as their neighbors.

In the southern part of the continent, the change is a bit more gradual. Chile increased from 6.56% to 10.84%, and Uruguay from 6.80% to 10.86%. Both entered double digits, showing that even the more stable and mature economies are not exempt from the same overall upward movement.

The larger economies follow the same direction, but at a slower pace. Argentina rose from 6.76% to 10.06%, while Brazil increased from 7.60% to 9.58%. Brazil’s growth is more modest in percentage terms, but given its size, even smaller shifts represent a significant amount of traffic.

Overall, South America is moving in a very consistent way, and the main takeaway is simple: ad and tracker-related traffic is increasing across the continent, and most countries are now sitting at comparable levels rather than distinctly different ones.

Europe: a very uneven map

Europe showed a moderate rise in ad and tracker-related traffic compared to other regions. In most countries, the increase sits in the 2 to 4 percentage point range, which points to gradual growth rather than any sharp shift. But beneath this stability, Europe is clearly divided into tiers that display very different dynamics.

The most meaningful increases come from Eastern and Southeastern Europe, where growth is both stronger and more consistent. Belarus stands out with a sharp rise from 7.61% to 13.20%, placing it among the highest in the region. Greece (9.47% → 12.05%) and Serbia (6.91% → 11.59%) also showed clear growth, moving into double digits. Ukraine (6.59% → 11.56%) and Turkey (7.97% → 11.20%) follow the same pattern, with both countries rising into a similar range.

Western Europe, by contrast, shows a more gradual progression. Spain increased from 8.85% to 10.36%, Italy from 7.75% to 9.81%, and France from 7.38% to 9.35% — all steady but hardly dramatic gains. The UK (6.61% → 9.61%) also crossed into higher territory, but fell short of the double-digit mark.
Northern Europe remains the most stable part of the continent as far as the share of ad trackers go. Germany (6.93% → 8.89%) and the Netherlands (6.39% → 7.92%) showed slow, consistent increases, while Sweden (5.41% → 6.98%).

Overall, Europe is not moving as a single block. Instead, it shows a clear pattern: faster growth in the East and Southeast, moderate and steady increases in Western Europe, and low, stable levels in the North. This creates a continent where ad and tracker-related traffic is growing, but at very different speeds.

Asia: a split picture between upward and downward trends

Asia doesn’t move in a single direction — instead, it shows one of the most mixed and structurally diverse patterns in the entire dataset.

On one side of the story, there is clear and visible growth. Countries like the UAE (7.50% → 11.49%) and Saudi Arabia (6.53% → 10.53%) show strong upward movement, both crossing into double-digit territory. Japan (6.74% → 9.52%) and Indonesia (5.96% → 8.81%) follow the same direction, reflecting steady growth in ad and tracker-related traffic across major economies in the region. Even China, while still at a relatively low baseline, continues its gradual rise from 2.20% to 3.63%.

At the same time, another group of countries is moving in the opposite direction — or at least cooling after earlier highs. India declined from 12.48% to 11.12%, still high in absolute terms, but showing a slight correction compared to last year. Uzbekistan also eased slightly from 13.84% to 12.73%, though it remains among the higher values in the region.

Africa — broad and steady growth across the board

Africa shows one of the clearest and most consistent upward trends in ad and tracker-related traffic.

In many of the larger countries, the increase is especially visible. South Africa, for instance, rose sharply from 7.80% to 13.69%, making it one of the biggest jumps among major economies globally. Nigeria (7.80% → 10.19%) and Egypt (7.79% → 10.64%) also moved into double digits, showing that this trend is not limited to a single country, but shared across the whole continent. Morocco (6.58% → 10.37%) and Kenya (5.89% → 9.82%) follow the same path, moving into higher levels over the year.

Even countries with lower starting points in terms of ad tracking traffic share showed the same direction of change. Botswana showed a particularly strong increase, rising from 6.96% to 12.28%, joining the group of countries that moved into double-digit levels.

Overall, Africa’s trend is simple and quite consistent: most countries are moving upward together. The pace varies from place to place, but the direction is the same across the board.

Winners and losers

Looking at all regions together, one trend stands out very clearly: ad and tracker-related traffic has increased almost everywhere between 2024 and 2025. The global shift is not extreme in every country, but it is consistent enough to show how much background advertising infrastructure is increasingly embedded into everyday browsing.

At the top end of the global scale, several countries now sit at notably high levels. Papua New Guinea (13.80%) and South Africa (13.69%) lead the group, closely followed by Belarus (13.20%) and Tajikistan (12.92%). The Caribbean and nearby regions also stand out, with Trinidad and Tobago reaching 12.94%, while Zimbabwe (12.79%) confirms the same trend in Africa.

China (3.63%) sits at the very bottom of the dataset, followed by Iran (4.65%), while parts of Northern and Western Europe also show relatively low levels, including Denmark (6.26%), Luxembourg (6.43%), and Norway (6.52%). These patterns match what we’ve seen in Europe and parts of Asia: more stable digital environments, where growth is slower.

Conclusion

Taken together, these numbers suggest a global pattern. When comparing our data from 2024 and 2025, we’ve noticed that higher values in terms of ad tracker traffic growth were mostly found in fast-growing regions like parts of Africa, the Caribbean, and Eastern Europe, where internet use is expanding quickly and advertising systems grow alongside it. Lower values were more common in the countries with already developed or tightly managed online markets, where infrastructure is already well developed, rules are stricter, or traffic levels are more stable.

However, the overall rise in ad and tracker-related traffic likely comes from a mix of things. First, ads are becoming more and more deeply built into websites and apps, which creates more background requests while people browse. Second, better filtering and detection tools, such as those used by AdGuard, can also change what we see in the data, making some traffic easier to spot than before.

In simple terms, this is not just about “more ads.” It shows how the web is changing — with more background activity linked to advertising and tracking, growing at different speeds depending on how developed, regulated, or optimized each region’s internet system is.

But times change, and so do we. Starting with AdGuard for Windows v8.0, we will no longer support Windows 8 and 8.1. You can download the last version that supports older Windows here.

Just so there’s no confusion: AdGuard for Windows v8.0 does not support Windows 8, despite the similar names. It’s just a coincidence, we swear.

Why now?

Microsoft ended support for Windows 8.1 in January 2023. For more than two years after that, we continued releasing updates for users on these systems. Now it’s time for us to move forward.

Focusing on newer versions of Windows helps us improve AdGuard faster and make it more secure and reliable. Many modern libraries, development tools, and security technologies are built for newer operating systems. Continuing to support older ones makes it harder to provide our users with the best possible protection.

What if I’m not ready to let go?

You can still use AdGuard on Windows 8 and 8.1, but only the latest supported versions. Please note that these versions may not be as efficient or secure as the newer ones.

The last stable version to support older operating systems is AdGuard for Windows v7.22.

The last supported Nightly version is also available. Keep in mind that Nightly builds may be unstable and contain bugs.

Please note that all future releases of AdGuard for Windows will require Windows 10 or newer.

It’s not YouTube’s first rodeo with this particular format. Almost 10 years ago, the platform decided to retire 30-second unskippable ads, since at the time they were widely seen as a relic of traditional TV. That was something that everyone, including the tech leaders of the day, was eager to leave behind. Well, how the times have changed…

The return of the once discarded format was first announced back in 2023, and it took YouTube a whole three years to reintroduce it.

At 30 seconds, the new format officially becomes the longest standard unskippable ad YouTube offers. That said, there has been plenty of anecdotal evidence of much longer unskippable ads appearing on the platform, with reports ranging from several minutes to an eye-watering (sic) 58 minutes.

Source: Reddit

However alarming these reports may sound — and the mere thought of an hour-long ad is enough to make anyone shudder — YouTube has either dismissed them as glitches or declined to comment altogether.

For now, the 30-second spots coming to connected TVs are the longest officially recognized format, and they appear to be here to stay.

Where the ads will be shown

In the blog post, YouTube says that VRC non-skip ads (VRC stands for Video Reach Campaign) are designed specifically to run on Connected TV (CTV) devices, like smart TVs, streaming devices (Roku, Fire TV, Apple TV, Chromecast), and other internet-connected big screens in living rooms. The longer, 30-second non-skippable spots are CTV-only, while Google’s AI dynamically mixes in 6-second bumper ads and 15-second standard non-skippable ads across other YouTube environments such as mobile, desktop, and tablets.

The rationale behind this is that viewers who watch YouTube on big screens will be more tolerant towards long commercials than those who watch YouTube on their PC or phones. That seems to be a fair assumption, but it nevertheless brings us back to where we started, and we’re talking about the era before streaming services and YouTube took off.

Back to the old but not-so-good times

This new addition inevitably brings back memories of the era when long commercial breaks were simply part of watching TV. Anyone who grew up with traditional broadcasting will remember the routine: the moment the screen faded to a commercial break, you would get up from the couch, grab some popcorn, maybe pour yourself a coffee, and return a few minutes later hoping the show had just resumed. It was a shared experience, something almost everyone went through at some point.

The problem is that very few people actually want to repeat it. Streaming and online video platforms became popular precisely because they moved away from that model. And yet with these longer, unskippable ads, YouTube seems to be edging back toward the same viewing habits many viewers were happy to leave behind. Nostalgia for the “good old days” is one thing, but this feels less like a throwback and more like a regression.

There is also another important difference. In traditional television, shows rarely cut off randomly for commercials. The breaks were usually deliberate — often placed at moments designed to keep viewers hooked, sometimes even right on a small cliffhanger. That could still be annoying, of course, but at least there was some structure and intention behind it. Today’s streaming viewers, on the other hand, have become used to a far more seamless experience. And in that context, the idea of returning to long, unavoidable interruptions feels like an unwelcome step backward.

More ads, fewer escapes: YouTube tightens the screws

The addition of a new ad format is in line with a trend that has defined YouTube’s broader strategy in the past few years: maximizing ad revenue. By that measure, YouTube has been enormously successful. According to estimates from research firm MoffettNathanson, reported by The Hollywood Reporter, the platform pulled in a staggering $40.4 billion in ad revenue in 2025, surpassing the combined ad revenue of Disney, NBCUniversal, Paramount, and Warner Bros. Discovery, which together generated $37.8 billion.

Another strategy that complements this approach (and ultimately serves the same goal) is cracking down on ad blockers to drive the subscription revenue. As we’ve reported earlier, YouTube has recently begun discouraging ad-blocking users by intentionally worsening user experience. It is doing so by hiding video descriptions and comments until the blocker is disabled.

Only this year, YouTube appears to have tightened several other loose screws as well. One example is background playback, a feature officially reserved for YouTube Premium subscribers but previously accessible through a loophole: watching videos through alternative mobile browsers like Samsung Internet, Brave, Vivaldi, or Microsoft Edge, often paired with ad blockers. Earlier this year, many users reported that the workaround suddenly stopped working. Minimizing the browser or turning off the screen now cuts the audio. A Google spokesperson later confirmed to Android Authority that YouTube had updated the experience to ensure background playback remains exclusive to Premium across all platforms.

Earlier this year, free YouTube users also reported seeing a new form of persistent advertising inside the mobile apps. These banners appear in the bottom-left corner of the video, and in some cases cannot be dismissed unless the viewer exits the video and restarts playback.

Source: Reddit

The perils of YouTube Premium subscriptions

By the look and sound of it, YouTube’s broader goal seems fairly obvious: discourage users from turning on ad blockers and nudge them towards premium subscriptions — all at the same time. That would fit neatly into the wider subscription economy that has taken hold across industries, from streaming services to printers, and even cars.

The push also comes at a time when the original free YouTube experience is becoming increasingly difficult to enjoy, thanks to constant interruptions. The most straightforward solution would be to subscribe to Premium — at least that’s how it looks on paper. In reality, there have been multiple reports over the years of users still encountering ads even after switching to Premium. Google typically attributes these cases to glitches or user-side issues — such as watching videos while logged out — but the reports keep surfacing, with some users claiming they still see ads on the homepage and other parts of the platform).

And then there’s the price. A full Premium subscription currently costs $13.99 per month for individuals or $22.99 for a family plan, which is not exactly trivial for many viewers. Unsurprisingly, some users look instead to Premium Lite, available in the U.S. for $7.99 a month. The catch, however, is that it only offers a mostly ad-free experience — ads can still appear on music content, Shorts, and during browsing or search.

Given the trajectory YouTube seems to be on, it would not be surprising to see the number of subscription tiers expand even further, with a completely ad-free experience gradually turning into something of a luxury. After all, from a business perspective the ideal scenario would be to keep both revenue streams flowing: ads and subscriptions alike.

Some observers think the situation could escalate even further. As one commenter on X put it: “Soon you'll get ‘reduced ads’ with Premium, and will need a ‘Supreme’ account for actual ad-free. And so on.” While that prediction may be somewhat tongue-in-cheek, it is not entirely difficult to imagine a future where the lines between free, paid, and “premium-premium” tiers become increasingly blurred.

Alternative — ad blockers, where possible

There is also another reason why YouTube’s advertising push is increasingly focused on connected TVs. Compared to PCs or smartphones, smart TVs offer far fewer ways to avoid ads in the first place. Traditional browser-based ad blockers simply cannot be installed on most TV platforms. That leaves network-level approaches such as DNS filtering as one of the few available options. However, even those methods have significant limitations. Because YouTube often serves ads from the same domains as the video content itself, DNS-based blockers generally cannot filter them out without also breaking video playback. In practice, that makes YouTube ads far harder to block on smart TVs than on desktop or mobile devices.

For many users, the combination of longer ads, tighter platform restrictions, and an increasingly aggressive push towards Premium leaves one obvious alternative: turning to ad blockers — at least on the devices where they still work reliably. AdGuard and other ad-blocking solutions have long been locked in a classic cat-and-mouse game with YouTube, as the platform continuously introduces new measures designed to detect and discourage ad blocking. The crackdown may be intensifying, but the other side of that equation is constantly adapting its approaches as well.

And given the current trade-offs, it is not hard to see why people keep turning to them. When Premium subscriptions continue to rise in price, occasional glitches still let ads slip through, and even cheaper tiers remain partially ad-supported, the balance can start to feel a little unfair. In the meantime, the goal remains simple: make YouTube watchable, like it used to be once, even if the platform itself seems determined to make that harder.

At the core of ad blocking lie filter lists — sets of rules written in special syntax that tell ad blockers which elements on the page to block and which to leave alone. Each filter list can consist of thousands of individual filtering rules, and some of those rules are very complex.

They don’t appear magically out of nowhere, of course. Real people work on them, creating new rules and fixing up older ones. These people are called filter maintainers, and often they do this work for free, out of pure enthusiasm and their will to help the ad-blocking community. If not for their continuous efforts, there wouldn’t be ad blocking as we know it. This is why we created AGLint — a tool aimed to make filter maintainers’ lives just a little bit easier.

A bit of history: why AGLint exists

At AdGuard, we have our own in-house filter developers, so we know firsthand what it’s like to maintain over a dozen filter lists containing thousands of filtering rules each. And let us tell you, it is not an easy task!

Filtering rules are written in a special syntax, so nuanced, that it increasingly resembles a programming language. And like any “language,” it’s easy to make a mistake when creating a filtering rule, and sometimes tiny ones can cause surprisingly big issues. With hundreds of rules created and updated every day, the odds of an error slipping into a public release go up fast. So, naturally, an idea came to us to create a tool that would help filter maintainers catch those errors early before they reach users.

Thus we developed AGLint, a program designed specifically to inspect filtering rules and point out common mistakes in them. At its core, AGLint is a linter for adblock filter lists — the name isn’t a coincidence.

In the case of AGLint, it inspects filtering rules, detects common mistakes, and flags them with actionable feedback. First released almost three years ago, AGLint has evolved into a customizable, cross-platform, open-source tool that supports multiple popular ad-blocking syntaxes (AdGuard, uBlock Origin, AdBlock, Adblock Plus).

It’s being used by many filter developers, and so we’ve received a lot of feedback on it. One of the most common complaints was that when you install AGLint into a new GitHub repository, you often get overwhelmed with a barrage of warnings, and that every single error requires manual input to fix. Motivated by this feedback, we came up with a system of automatic fixes to ease filter maintainers’ manual workload. This system, along with other changes made in the AGLint v4.0, — currently in the late beta stages — was the focus of Dávid and Liza’s presentation at the AFDS.

Before we dive in, let’s meet the speakers behind the presentation.

My name is Liza, and I’m a filter list maintainer as well as an AGLint contributor. I’m really excited to talk about AGLint v4 — a specialized linter for adblock filter lists. I’ll focus on how the improvements in AGLint v4 help maintainers like me — from rule writing and debugging, to using the new APIs and benefiting from performance boosts. Together with Dávid, we’ll show how AGLint supports both casual users and advanced contributors.

–Elizaveta Egorova, Developer & Filter maintainer, AdGuard

My name is Dávid, I’m from Hungary, and I work for AdGuard in the Extensions team as a developer. We’ve been working hard on a full rewrite of the tool, and in this talk I’ll walk you through the major updates and the motivation behind them.

–Dávid Tóta, Developer, AdGuard

Their talk is structured in three parts. First comes a quick introduction to AGLint — what it is, why it matters, and how it can be helpful to you even if you’ve never used it before. Then they walk through the key updates in AGLint v4, with practical examples to show the improvements in action. Finally, Dávid and Liza share a brief look at what’s next, outlining the ideas and plans for AGLint’s future. Below is the adapted and slightly simplified version of this presentation. For the full version, watch the video from the AFDS at the end of the article.

What AGLint does (and who it’s for)

AGLint is a linter for adblock filter syntax that supports all popular syntaxes:

• Adblock Plus / AdBlock
• AdGuard
• uBlock Origin

It scans the rules, highlights problems, and suggests fixes. The main goal is to help maintainers produce higher-quality filter lists that are more reliable and easier to maintain.

AGLint isn’t just a command-line tool — it also integrates into popular editors like Visual Studio Code. That means you get real-time feedback as you write or edit rules, with syntax highlighting, autocomplete, and instant linting built right into your workflow. The concept of AGLint is inspired by ESLint, a popular linter for JS.

AGLint logo and what its colors represent

AGLint is built with different types of users in mind, who may have different needs and levels of involvement — from casual maintainers to advanced contributors.

For most maintainers, the ideal workflow is simple: install AGLint, initialize a config, and lint your lists. AGLint also integrates with editors (notably VS Code), giving you “linting while you type” experience, with syntax highlighting and built-in tools, all right in your editor, with no extra setup needed.

For more advanced users, AGLint offers a plugin-style approach: an API that lets you adjust behavior, create custom rules, adjust existing configurations, or extend the linter for specific workflows.

Features and what’s changed in AGLint v4

AGLint v4 is not a single feature release — it’s a broad upgrade that touches performance, developer experience, and extensibility.

Here’s what the v4 update focuses on:

• a rewritten, more performant core
• caching to avoid re-linting unchanged files
• autofix and suggestion APIs
• a smoother CLI experience
• new linter rules
• better editor integration

The common thread is efficiency: faster feedback, fewer repetitive actions, and a workflow that scales with large filter repositories. Let’s zoom in closer on some of these changes.

Under the hood: a rewritten engine

The biggest change in AGLint v4 happened under the hood: we completely rewrote the engine. From now on, the engine allows efficient management of parsers and querying of the data structure using selectors. This provides a much more flexible solution — both for the core’s internal implementations and for the linter rules.

This rewrite also made the engine more flexible: it now supports debugging mode, caching, and a refined autofix and suggestion API. It also lays the groundwork for a future plugin system. Finally, we’ve put more emphasis on web support. While this already existed in earlier versions, our roadmap now includes deeper integration with web-based editors. This opens the door to better integrations and faster feedback, even without needing a full development setup.

This is the basic operation of the core through a very simple example

The very first step is parsing the filter lists into what’s called an Abstract Syntax Tree, or simply AST. The AST is essentially a structured object that represents the elements of the source code — in this case, the filter list. With the new engine, this process is much more efficient and allows us to use even multiple parsers effectively. The importance of the other parsers becomes apparent in cases like this: for example, by default we parse modifiers as ‘key-value’ pairs, but the value itself isn’t further parsed by the main parser. However, in the linter, we need to parse that value as well.

For instance, in the example shown below, we need to parse a pipe-separated domain list — and the engine provides a way to do that.

You can see a simple network rule, and below it, an illustration that shows how the AST should be imagined. In reality, the structure is a bit more complex, but the example illustrates the main idea well.

The key point is that the network rule is broken down so that we can identify the pattern, see which modifiers are used, and what values they have. In this example, the a. com domain will be considered invalid in the linter because it contains a space.

By the way, we have a two-panel AST explorer that allows you to view the AST of any filter list in an interactive, user-friendly, and well-organized way.

The second step is loading the linter rules. Linter rules essentially use CSS-like selectors to target specific parts of the AST. These selectors are then linked to handler functions that determine what happens when the corresponding nodes are reached. When we reach a domain node, its value (the domain) is validated by a function. If the function deems the domain invalid, the linter rule reports the issue back to the core. Otherwise, if everything is fine, we simply continue processing.

The API is made up of two main parts:

• Meta – holds rule information, like the type, description, and other details.
• Create – this function runs when a linter rule is initialized. Within this function, you can return selectors and their corresponding handlers.

Essentially, they are selectors to which we can attach a handler. For example, if we want to access the body of element hiding cosmetic rules, we can simply specify elementhidingrulebody and assign a handler to it.

New caching mechanism

Let’s start with a bit of context. In our GitHub setup, AGLint runs automatically on every commit — this happens through continuous integration (CI). That’s great for catching issues early, but it used to be… quite wasteful. Most commits only touch a single file, maybe two or three. It’s very rare that someone changes more than five files at once. But before caching, the linter would still process the entire repository — every single file — even if 99% of them hadn’t changed. As the project grew, this started to slow things down noticeably.

In AGLint v4, we’ve introduced a caching mechanism. Now, the linter keeps track of previously linted files and their content checksums. If a file hasn’t changed since the last run — we just skip it. Only files that were modified in the current commit are linted.

Local linting performance has been significantly improved thanks to caching. When cached, the process now takes only 66 ms on average — a major speedup compared to older runs. In a single-threaded setup, linting takes around 2.5 seconds, but with multi-threading that number drops to 1 second — more than twice as fast. These optimizations make development much smoother and more efficient for filter maintainers.

After cache:

Local linting times for AdGuard Filters repository after introducing cache

This change is especially helpful for filter maintainers working on large lists — they get faster feedback, and CI pipelines don’t bottleneck as the project scales. It’s one of those things you don’t necessarily see… but you definitely feel the difference.

Autofix and Suggestions API

When we set up AGLint in a new project, we quickly run into lots of small issues — like naming, formatting, and rule changes. These weren’t hard, but AGLint couldn’t fix them automatically, so we had to do it all manually. It was slow and left a lot of room for mistakes. And after setup, every time AGLint updated with new rules or changes, we got even more issues. These were mostly small fixes, but without automation, it took a lot of time to clean them up.

This brings us to one of the most user-facing improvements in AGLint v4 — how we help users fix problems in their filter rules. Sometimes, when the linter detects an issue, there’s a clear and safe way to fix it. In those cases, we can just apply the fix automatically. But other times, the situation is a bit more complex — maybe there are multiple valid fixes, or it depends on user preference. That’s why AGLint now provides two types of fixing APIs:

• one for autofixes, where AGLint applies the fix automatically
• one for suggestions, where it’s the user who makes the final decision.

They work together to improve the developer and maintainer experience, both in the CLI and in your code editor. Let’s have a look at each of these APIs in more detail.

This flow helps compare Autofix and Suggestions. Both start the same way: the linter finds an issue. Then the key question is — can the fix be applied safely?

• If yes, we use Autofix — the change is done automatically, no extra work for the developer.
• If no, or if there are multiple possible fixes, then we use Suggestions — the linter explains the options, and the developer decides.

So Autofix is about speed and automation, while Suggestions is about guidance and choice.

Autofix is all about safety — if the linter is confident that the fix is safe, it just does it for you. It’s great for low-risk issues like formatting, quoting, or other simple rule patterns. It works seamlessly whether you’re in the terminal or using a code editor.

Autofix API:

• Automatically applies safe, unambiguous fixes
• No user interaction needed
• Great for formatting issues and simple rule mistakes
• Works in both CLI and editor integrations
• Built for performance and repeatability

Here is a real-world example of when we can use autofix. On macOS keyboards, it is easy to type curly quotes without noticing. Curly quotes do not follow the style guide and can make the rule invalid.

AdGuard syntax only accepts straight quotes: single ' or double ". In the first version, curly quotes are used around "json-prune" and "productAds". The corrected version replaces them with straight double quotes, and the rule works as expected.

This type of fix is safe to automate because it does not change the meaning of the rule. It only replaces curly quotes with straight ones. Curly quotes are never valid, so autofix can always correct them without any risk of breaking the rule.

Suggestions are there to guide rather than decide. In situations where the linter can’t confidently pick a single fix — or where user preference makes a difference — it doesn’t try to force a choice. Instead, it offers one or more possible fixes.

Suggestions API:

• Offers possible fixes for ambiguous issues
• User decides which suggestion (if any) to apply
• Ideal when multiple valid options exist
• Integrated into editor UI (e.g. VSCode code actions)
• Gives control without sacrificing guidance

This is especially useful when multiple valid options exist. For example, a rule might be technically correct in more than one form, but it’s up to the maintainer to decide which style they prefer. The Suggestions API gives you that flexibility. The best part is that these suggestions are directly integrated into the editor UI, like VSCode. So instead of looking at cryptic warnings, you get a familiar code action menu — click, choose the suggestion you like, and move on. It’s all about keeping the user in control, while still providing enough guidance so you don’t have to figure everything out on your own.

Autofix and Suggestions are also built right into the CLI. That means when you run AGLint locally, you can not only see the issues but also apply safe fixes directly from the command line, without leaving your normal workflow. Let’s have a look at a couple more examples of applying Autofix and Suggestion APIs.

Example: Removing duplicate CSS declarations

This is an interesting case. In CSS styles, the same property can sometimes be written more than once. Let's think about when we can use autofix and when we can't. In the first situation, both the property and its value are exactly the same. In the image below, you can see the same line repeated twice. In this case, it is safe to remove one of them, because the duplicate does not change anything. So, we can use Autofix.

The second situation is different: the property is the same, but the values are not. Here, the linter cannot guess which value the user really wants. Therefore, in this case, suggestion is more appropriate. The user should decide which one to keep.

Example: Detecting unsupported CSS pseudo-classes

We support known pseudo-classes like :not(...), :has(...), or extended ones like :contains(...). But sometimes users write something unsupported, like :foo(...).

The tricky part is typos — for example, :contins(...) probably means :contains(...). A linter can’t be 100% sure, but if we find something invalid, we can do a fuzzy search (a technique that identifies matches even when the search query does not exactly match the data, allowing for misspellings, typos, and variations) and suggest likely matches.

According to what you see on this image, this contins typo can be suggested to fix as contains, because there is a very high degree of certainty that that’s what the user meant. And in the second case, if the fuzzy search algorithm does not find anything from the known names close to foo, we should offer to remove the pseudo class. However, it probably breaks the selector, so it’s not safe and we can only offer the suggestions. And this idea isn’t limited to pseudo-classes — we can apply it to modifiers, scriptlets, and more.

But how do you quickly check whether a specific modifier, redirect, or scriptlet exists in a certain syntax? For that purpose, compatibility tables exist. Compatibility tables are essentially YAML files containing information about scriptlets, modifiers, and redirects for each adblock syntax, along with APIs for interacting with this data.

They help developers avoid guesswork and ensure consistent behavior across syntaxes. The tables should be always updated as new features are added, and to keep them accurate and complete, we invite everyone to contribute. Your input helps improve the reliability of these compatibility resources. Now that compatibility tables are part of AGTree, you can check our repo at tsurlfiltr.

Preferred linter rule syntax

It is important to check rules for the correct syntax. This is especially useful for filter maintainers who work with third-party filters or with different blocker syntaxes.

In real-world filter development, it’s common to work with third-party lists, mixed syntaxes, or repositories transitioning from one style to another. AGLint’s configuration can enforce a preferred syntax and help keep rule formats consistent.

This isn’t just aesthetics: when a repo quietly accumulates mixed syntax conventions, maintenance becomes harder, and reviewers have to keep more “context” in their heads. Setting a preferred syntax makes the linting output clearer and reduces accidental inconsistency.

Part of the AGLint configuration that sets preferred syntax to AdGuard format

AGLint future

So what’s next for AGLint? Our immediate focus is on expanding the rule set to make filtering more flexible and powerful. And we’d love your help — whether that means voting on new rules, creating them, or keeping existing ones up to date. If you’d like to get involved, join us on GitHub: AdGuardTeam/AGLint.

We plan to release the next version soon, but we don’t want to do it in a vacuum. We’re actively looking for input from filter maintainers who work with real-world cases every day. Your feedback will help us shape rules that are not only smarter, but also easier to use and maintain.

Next, we plan to integrate these features into the user rules editor in AdGuard products, making it possible to customize and extend linting rules without touching the core code.

We’re also exploring formatting support. It’s still an open question, but the goal is to complement linting with consistent style — so rules can be not only correct, but also clean and uniform.

And finally, we want to create an AGLint GitHub action for GitHub Marketplace. The idea is to bundle key features — caching, autofix, and potentially even automated pull requests or issues — so teams can plug AGLint into their CI/CD pipelines with minimal setup.

Currently, Dávid Tóta is working on the official release of AGLint v4, and once it comes out, he is going to publish a separate article with a more in-depth look into it. Stay tuned!

Liza and Dávid presenting AGLint v4 at AFDS

After implementing age checks in compliance with the UK’s Online Safety Act and Australia’s Online Safety Amendment Act — which bans social media access for users under 16 — Discord attempted to preempt similar legislation in the EU, the US, and elsewhere by expanding its age assurance program globally.

On February 9, Discord announced that “all new and existing users worldwide will have a teen-appropriate experience, with updated communication settings, restricted access to age-gated spaces, and content filtering that preserves the privacy and meaningful connections that define Discord.”

The phrasing did not land well.

Many users interpreted the announcement to mean that everyone would be downgraded to a “teen experience” by default unless they verified their age — either through a face scan or by submitting a government-issued ID. Panic spread quickly across forums, social media, and YouTube commentary channels.

Discord later clarified that the “vast majority of people can continue using Discord exactly as they do today, without ever being asked to confirm their age.” But by then, the damage was done. The backlash had already snowballed into a full-blown public trust crisis.

Discord breaking its promise of on-device processing

Throughout its announcement, Discord emphasized privacy safeguards. Among the key features highlighted was “on-device processing,” with the company stating that video selfies used for facial age estimation “never leave a user’s device.”

Notably, it did not make the same explicit claim about ID-based verification.

The overall impression many users took away was that sensitive personal data would remain local — processed on-device and never transmitted to third parties. That reassurance was meant to calm privacy concerns.

Instead, it fueled them.

Discord’s old support page (it can now be accessed through web archive) revealed that users in the UK “may be part of an experiment” involving the age-verification vendor Persona.

The disclaimer read:

“Important: If you're located in the UK, you may be part of an experiment where your information will be processed by an age-assurance vendor, Persona. The information you submit will be temporarily stored for up to 7 days, then deleted. For ID document verification, all details are blurred except your photo and date of birth, so only what's truly needed for age verification is used.”

Persona is a cloud-based identity verification service. By definition, that means user data is transmitted to and processed on external servers, not purely on-device.

While the admission did not directly contradict Discord’s earlier messaging — after all, the company never explicitly promised that all age-verification data would be processed on-device — it made one thing unmistakably clear: the system was not purely local after all. Even if limited to a UK experiment, it created the perception that Discord had been speaking in half-truths or at the very least communicating extremely poorly.

Concerns deepened due to Persona’s broader data practices. Internet sleuths examining its policies pointed out references to checks against “third party databases, government records, and other publicly available sources.”

Persona CEO Rick Song later told Ars Technica that data from verified individuals in Discord’s test was deleted immediately. However, the fact that data could have been stored for up to seven days, combined with Persona’s external processing model, only intensified skepticism.

Matters worsened when reporting revealed that a Persona frontend had been left exposed, potentially allowing unauthorized access to sensitive verification data. According to Malwarebytes, the exposure stemmed from a misconfigured web component that made internal resources accessible from the internet before being secured. Though there was no confirmed evidence of exploitation in the Discord case, the timing amplified public distrust.

Meanwhile, critics pointed to a far more damaging episode: a September 20 breach in which attackers accessed data held by Discord’s third-party customer service provider. The compromised information included government ID images submitted by users who were appealing failed age determinations, along with usernames, emails, limited billing details, IP addresses, and support messages. For many observers, the incident confirmed their worst fears — that even if ID checks are meant to be a one-off occasion, forcing users to resubmit sensitive documents in edge cases dramatically increases the risk of real-world exposure.

Although references to Persona were quietly removed around February 15 — as noted by The Verge — the damage was already done. For many users, the mere fact the partnership existed contradicted the spirit of Discord’s privacy-forward branding.

Apologies and belated clarifications: Will they be enough?

With backlash mounting, Discord’s CEO Stanislav Vishnevskiy published a lengthy post on February 24 aimed at calming fears.

He reiterated that for roughly 90% of users, nothing would change. Most users, he said, do not access age-restricted content or modify default safety settings.

Vishnevskiy also revealed that Discord already uses an internal system to estimate age based on account-level signals, stating:

“Age determination works the same way, using the same category of account-level signals: how long your account has existed, whether you have a payment method on file, what types of servers you're in, and general patterns of account activity. It does not read your messages, analyze your conversations, or look at the content you post.”

He acknowledged that “trust us” is not sufficient reassurance and promised to publish a technical blog post explaining the methodology before a global launch.

As for the Persona partnership, Vishnevskiy confirmed it was a limited UK test conducted in January and stated that Discord no longer uses the service because it “did not meet the bar for entirely on-device processing.”

The question remains whether these clarifications came too late, or if they are enough.

Bottom line

Age verification is one of the most contentious issues facing online platforms today. Regulators see it as a necessary safeguard for minors. Users often see it as a slippery slope toward surveillance.

Even when implemented with privacy protections, age verification inherently introduces new risks. It creates additional data flows, expands the number of entities handling sensitive information, and increases the attack surface for potential breaches. Every additional verification vendor becomes another possible point of failure.

Discord’s experience illustrates a broader tension: platforms are trying to navigate tightening regulatory requirements without alienating privacy-conscious users. But in doing so, they risk eroding the very trust that made them successful.

Whether Discord’s delayed global rollout reflects a lesson learned — or simply a pause before renewed controversy — will depend on how transparently and cautiously it proceeds next.

AdGuard for Meta Quest works just like our browser extension for Chrome: it blocks ads, trackers, pop-ups, and malicious websites, giving you a cleaner, faster, and more private web experience. Whether you’re reading, shopping, or exploring online in your Meta Quest headset, AdGuard helps you stay focused and in control. AdGuard works on Quest 2, Quest Pro, Quest 3, and Quest 3S.

This isn’t just another platform for us — it’s a leap forward in bringing distraction-free, secure browsing into immersive environments.

– Vladimir Ozersky, Lead Product Manager, AdGuard Ad Blocker

The AdGuard ad-blocking extension is compatible with the Meta Quest Browser starting with AdGuard Browser Extension v5.2.

Follow the steps below to install the AdGuard ad-blocking extension for your VR glasses.

🔧 How to Install AdGuard on Meta Quest

Follow these simple steps to add AdGuard to your Meta Quest Browser:

1. Open the Browser app on your Meta Quest device.

2. In the top-right corner, select the three-dot icon (Menu).

3. Select Extensions from the menu.

4. Find AdGuard in the list and select it.

5. Select Install and complete the installation process.

You’re set!

Once installed, AdGuard will work like any standard browser extension for Chrome.

Meta Quest Browser is built on Chromium and is part of a broader open platform. In early 2024, it introduced support for user-installable extensions through a limited beta program. Since then, the catalog has gradually expanded, and AdGuard now joins this curated selection with its ad-blocking extension. AdGuard VPN extension is also now available, bringing VPN support directly to the Meta Quest Browser for the first time.

Install AdGuard on your Meta Quest headset today and enjoy a web experience that’s finally free from clutter, even in VR.

So… what is SockFilter?

SockFilter is a lightweight network driver that works directly with socket operations at the transport level (TCP/UDP). Instead of dealing with packets at the lowest possible level, SockFilter works at a higher, more stable layer, right where applications actually interact with the network.

And that difference matters a lot.

Why introduce a new driver at all?

Until now, AdGuard for Windows relied mostly on a WFP driver. WFP is powerful, but it also comes with complexity, compatibility challenges, and stability issues.

The TDI driver used to be an alternative, and while it is still available, it’s an outdated solution and may lead to filtering issues in some versions of Google Chrome. A temporary workaround exists, but it’s not a reliable long-term solution.

The conclusion was simple: it was time for a change. That’s why we’re introducing SockFilter — it brings a different approach that works especially well for ad blocking, plus it’s the solution we’ve been waiting for to finally put these problems behind us.

The advantages of SockFilter

When fully tested and implemented, SockFilter has the potential to bring several advantages over other drivers. Right now, it’s still experimental and unstable, so you might not see all the benefits yet. But here’s a look at what’s possible in the future:

• Better interaction with other network apps: SockFilter is designed to cooperate smoothly with VPNs, firewalls, and antivirus software. By avoiding clashes over network control, it can help prevent connection issues and make everything work together more reliably.

• Lower risk of system crashes: SockFilter works in a safer part of Windows networking, which can help it avoid deep system errors that can sometimes cause sudden blue-screen crashes. In practice, this can result in better stability and fewer chances of your system unexpectedly crashing while AdGuard is running.

• On track for better stability: SockFilter works closer to how apps normally use the Internet, instead of dealing with low-level network data, resulting in the potential to reduce complexity behind the scenes and making AdGuard more reliable in everyday use.

Known issues

So far, a small number of users have reported an issue with SockFilter: the new driver appears to interfere with voice and video calls on Discord. Two users have described the problem on GitHub.

Our QA team has successfully reproduced the issue and is actively working on a fix. If you notice any related problems or have additional details to share, please let us know.

Experimental, and that’s where you come in

Experimental mode means SockFilter is ready for testing, there may be bugs, and we’d love your help finding them.

To test it, go to Settings → Network → Traffic filtering, enable traffic filtering, and select SockFilter (Experimental) from the list of available options. If you notice anything unusual, unexpected, or just plain broken, you can switch back to TDI or WFP at any time. In that case, please report the issue on GitHub — your feedback directly helps shape the future of AdGuard for Windows.

This update adds DNS filtering and Encrypted ClientHello (ECH) support, along with userscripts, userstyles, and a more consistent update workflow. AdGuard CLI now protects you on more levels, while keeping the experience clean and predictable.

Added DNS filtering support

With DNS-level filtering enabled, unwanted domains, including ads, trackers, and malicious websites, are blocked before a connection is established. This adds an extra layer of protection and stops unwanted traffic at the earliest stage, preventing it from reaching your device.

Encrypted Client Hello

Although HTTPS encrypts the content of your traffic, the name of the server you are communicating with is usually still visible. ECH encrypts this part of the connection as well, helping to prevent ISPs, DPI systems, and other intermediaries from seeing which domains you access.

Added userscript and userstyle support

You can install and manage userscripts and userstyles directly from the command line. Management commands follow the same logic as filters, so enabling, disabling, and removing userscripts works in a familiar way.

Your feedback matters

AdGuard CLI 1.3 brings significant improvements, and we look forward to hearing your thoughts. Your feedback helps us refine the product and shape future updates.

You can share your experience or report issues on GitHub, or reach out to us through our social media channels. We appreciate your input!

The message is clear: the proposed policy represents a fundamental shift in how the Android ecosystem operates — and not for the better. We fully support every concern raised in the letter and stand in solidarity with the organizations calling on Google to reconsider.

What are Google’s new app verification requirements

At the heart of the debate is a new mandatory verification system for Android developers. Unlike existing requirements that apply only to apps distributed through Google Play, this framework goes much further. It requires all Android developers, even those who distribute their apps independently via their own websites, third-party app stores, enterprise systems, or direct file transfers, to first obtain a de-facto approval from Google.

In practical terms, this means developers will be required to create an account in a new Google console, agree to Google’s terms and conditions, pay a $25 registration fee, and complete an identity verification process. That process includes submitting a valid government-issued ID, such as a passport or driver’s license, providing a verified email address and phone number confirmed via one-time codes, and cryptographically linking their app to their verified identity. Developers must upload the public SHA-256 fingerprint of their signing key and submit a signed APK containing a designated verification file to associate the app’s package name with their registered identity.

Importantly, developers who already have apps on Google Play won’t have to start from scratch. Instead of creating a completely new account, they’ll get a new option in their existing Play Console to register any apps they distribute outside of Google Play. Developers who only distribute apps outside the Play Store, however, will need to create a brand-new account and go through the full registration and verification process. This means that for many established developers, the new requirements are an extension of what they already do for Google Play rather than an entirely separate system. For those working exclusively outside the Play ecosystem, though, it’s a completely new set of steps.

The scheme has been in early preview since November 2025 and will open to all developers in March 2026. Beginning in September 2026, enforcement will start in Brazil, Indonesia, Singapore, and Thailand. From that point forward, any developer who has not completed the verification process and registered their apps will see those apps blocked from installation on certified Android devices in those countries. Google has indicated that the policy will later expand globally.

Google has stated that students and hobby developers will be able to create special accounts with fewer checks and without paying the standard $25 fee. While that may soften the burden at the margins, it does not change the underlying reality: independent software distribution on Android will now require Google’s explicit permission.

This is a profound change, one that shatters the entire premise of the Android ecosystem, long regarded as the antithesis of the closed Apple ecosystem. Until now, Android positioned itself as an open ecosystem — one where developers could build and distribute software without having to pass through a single corporate gatekeeper. Under the new framework, that openness is fundamentally curtailed. The policy extends Google’s control beyond its own Play Store and into the broader Android landscape, effectively giving the company the technical ability to prevent installation of apps it has not approved.

What is wrong with the new Google rules

The impact on the developer community and first and foremost cutting-edge innovation within it could be significant. Volunteer-run open-source projects, privacy-focused developers, and teams in regions where Google services are limited or hard to access could all run into new hurdles. What sounds like a “10-minute process” on paper can easily turn into a real obstacle for small teams with limited time and resources.

There are also legitimate privacy concerns for developers themselves. Requiring government-issued identification, verified phone numbers, and other personal data concentrates sensitive information in one place. For developers building tools specifically designed to protect user privacy, being forced to surrender their own personal data as a precondition for distribution is deeply contradictory.

Equally troubling is the broader enforcement context. Google has a long history of app suspensions and rejections that developers describe as opaque, inconsistent, and difficult to appeal. Granting the company expanded authority over all Android app distribution — not just Play Store listings — amplifies concerns about arbitrary enforcement and limited recourse.

Moreover, there is strong reason to question whether the policy will achieve its stated goal of improving security. Determined malicious actors have repeatedly demonstrated their ability to bypass safeguards, even within Google Play, where identity verification and compliance checks already exist. A Bitdefender investigation last year revealed that over 331 malicious apps made it onto the platform, reaching millions of users despite existing verification requirements. These apps were able to bypass Android 13's security measures and deceive users, all while masquerading as legitimate software.

For legitimate developers, though, the impact will be immediate and real. Independent creators who rely on sideloading or third-party app stores may decide the extra paperwork, fees, and compliance headaches just aren’t worth it. The result? Fewer apps outside Google Play and in general — not because users don’t want them, but because the added friction pushes developers away. This, in turn, will discourage competition and slow down innovation.

From a user’s point of view, the policy could also create a false sense of security. If apps can’t be installed unless they’re “verified,” people may assume that verified automatically means safe. It doesn’t. Verification just confirms who’s behind the app, it doesn’t guarantee clean code or rule out malicious behavior. That misplaced confidence could make users less cautious, weakening the security awareness Android’s warning system was meant to encourage.

What can be done instead

Android already has solid security tools built in. Things like sandboxing, detailed permission controls, verified app signing, sideloading warnings and Google Play Protect create multiple layers of protection. If these tools are properly enforced — and that “if” really matters — they should be more than enough to address real security threats without putting the entire ecosystem under tighter centralized control.

For example, Google Play Protect continuously scans apps on a device, including those installed outside Google Play, and checks them against Google’s threat detection systems. It can warn users about harmful apps, disable them, or remove them in serious cases. In short, it’s built to detect bad behavior no matter where an app comes from.

Thus, security and openness don’t have to be mutually exclusive. Android has managed to balance both for years. But when new policies hand even more control to a single platform owner — and this is happening at a time when regulators are already looking closely at competition and market dominance — it raises real concerns. Moves like this can strengthen Google’s gatekeeping power, sideline alternative app stores, and make it harder for independent developers to compete on equal terms. It looks as if that’s not just about security and more about who controls access to users.

Android’s biggest strength has always been its openness. That’s what attracted developers and users in the first place. It’s our belief that preserving that openness benefits everyone.

For us at AdGuard, this isn’t just theoretical. Our users know that the full version of AdGuard for Android isn’t available on Google Play, because Google’s policies don’t allow full-fledged, system-wide ad blockers there. Instead, it’s downloaded directly from our official website or trusted third-party app stores.

We remain committed to keeping AdGuard accessible to everyone, and we’ll take all the necessary steps to comply with Google’s new policy to ensure the app stays available going forward when and if it takes effect. However, at this stage, it is still unclear exactly what will be required of us to remain fully compliant under the new framework. At the same time, we believe the better solution would be for Google to reconsider this direction and preserve the openness that has long defined the Android ecosystem.

According to reports we’ve been both receiving from our users and seeing on other platforms such as Reddit, YouTube has been disabling comment sections and video descriptions under all videos for at least some ad-blocking watchers, specifically on PC. It looks like YouTube is testing this approach on a select number of users, so not everyone has been running into it, but enough for the problem to make some waves. So what’s going on and how ad blockers, and specifically AdGuard, will address this?

The exact method of messing with the ad-blocking crowd may be new, but it’s far from the first time when ad blockers faced a challenge from YouTube and managed to successfully overcome it by updating the filter lists — sets of rules that tell the ad blocker what exactly to block. As with previous issues, the fixes have already been deployed. Once the updated filters reach users, the issue should resolve. But not everyone may have received them yet. And that’s where things get different.

The gap between a fix being created and it actually being delivered to users has never been wider — and that’s thanks to Google’s new extension rules. To understand why this delay now matters more than ever, we need to talk about Manifest V3.

Why Manifest V3 plays a big role

Manifest V3, or MV3 for short, is a new extension platform for Google Chrome and other browsers built with the Chromium engine (this includes Edge and Opera, for example). It was first announced back in 2018, iterated over the next few years, and started to roll out to users in 2023. By July 2025, Manifest V2, the old standard, had been fully deprecated, and no browser extensions working with it had remained available in Chrome. But why is this important in our case?

Among all browser extensions affected by MV3, ad blockers, perhaps, were hit the most. MV3 changed a lot in terms of what extensions in Chrome could and could not do, and the scope of their permissions reduced significantly compared to Manifest V2. One of the most significant changes is the replacement of the webRequest API with the declarativeNetRequest API. While both APIs allow extensions to block unwanted content, the declarativeNetRequest API is far more restrictive. It operates by pre-defining a list of rules that the extension can use to block content, and these rules are applied statically. In contrast, the webRequest API allowed extensions to intercept and modify network requests dynamically, offering far greater flexibility. This means that under MV3, ad blockers can no longer respond to requests in real-time, and their ability to update filter lists or adapt to new content is significantly reduced. As a result, blocking certain ads or trackers can become slower and less effective, as the system can’t react to new patterns until the filters are updated through a full extension review process.

This was done to improve users’ privacy, and, to be fair, this goal was achieved — with less permissions, malicious browser extensions now have less possibilities to induce real harm to your browser or system. The other side of the coin, though, is that many extensions, and especially ad blockers, have become less powerful. We had to put in a lot of effort and creativity just to keep the MV3 version of AdGuard Ad Blocker extension at the same level as its MV2 predecessor. But even then, there are more problems that may not be immediately noticeable to an average ad blocker user.

For example, and this is where we’re getting very close to the issue at hand, ad-blocking extensions under MV3 can’t just update their filters at will like before. The filters in MV3 are pre-built within the extension itself, which means that filter updates can only be delivered through full extension updates, and updating the extension requires it to go through a full-scale review process. This means that if something breaks on a popular website (like YouTube), users may be stuck without a solution for days.

There used to be a workaround we came up with, called Quick fixes filter, designed to keep some of the rules on the ‘fast update track.’ But Google shut that possibility up in early 2025 when they prohibited any remote code execution. The intention behind this policy was good — it greatly reduced the risk that a potential attacker could inject malicious scripts or remotely hosted code, but the wording used in the policy was so broad that even ad-blocking rules can fall under these restrictions.

So to keep the users’ filtering rules as fresh as possible, we had to find new ways of delivering filter rule updates to users’ machines, and this is where Chrome’s fast-track review comes into play. It allows developers to update filters more frequently without waiting for a full extension review. However, this method only applies to changes in rules that Google considers ‘safe.’ We roll out automatic extension updates with such rules every few hours. On the other hand, changing any of the rules that don’t fall under this category requires the browser extension to undergo a full review process, which can take a long time — up to a week, or even more in some cases. Unfortunately, the fixes required to deal with the YouTube issues we’re discussing today can not be delivered via the fast track, so until the extension passes the lengthy review process, they will not become available to Chrome users.

What about other browsers?

Browsers that don’t use Chromium and therefore don’t operate under Manifest V3 are few and far between. The most famous of them is, of course, Mozilla Firefox, which uses its own browser engine called Gecko. Mozilla supports Manifest V3 as a specification, but also hasn’t dropped the support for Manifest V2, so ad blockers there can keep using powerful blocking APIs. It allows them, among other things, to update filters automatically and independently from the extension. This may explain why Firefox users haven’t reported as many issues with YouTube — they likely received the necessary fixes via automatic filter updates.

There are some other niche cases like Brave browser. It is based on Chromium, and so Manifest V3 does fully apply there, with all its limitations. But Brave also features its own, built-in ad-blocking feature called ‘Shields.’ Brave updates its Shields filter lists automatically without requiring a browser update. However, it doesn’t use AdGuard filter lists by default, so unless you’ve added them manually, we can’t comment on whether the issues with YouTube comments and description should be resolved for you or not.

A systemic problem

This situation highlights a much larger problem in the world of ad blockers: the systemic limitations imposed by major platforms like Google, which control the ecosystem for most browser extensions. While it may seem like a simple bug that could be fixed, the reality is far more complex. The restrictions introduced by Manifest V3 and enforced through the Chrome Web Store review process are part of a broader trend of reducing flexibility for users and developers alike.

In the words of Andrey Meshkov, AdGuard’s Co-Founder and CTO:

The recent Manifest V3 changes in Chromium […] severely limited what ad blockers can do in Chromium-based browsers. You probably don’t feel it right now because we’ve been able to work with the Chromium team and shape the API in a way that covers most of our needs. But what’s been crippled is the ability to improve it further. It now takes much more time to implement changes — it may take years to introduce a new feature in MV3.

Circling back to the (understandable and justified) users’ dissatisfaction in regard to the delay in fixing the YouTube issues, this delay in filter updates isn’t due to a bug or oversight by AdGuard, but rather a ‘by design’ limitation in how updates are allowed to roll out. With Manifest V3, Google showed that it is prioritizing security and privacy, even if it means crippling the functionality of popular tools like ad blockers, leaving users without immediate fixes for issues like those happening on YouTube right now.

While AdGuard and other ad blockers continue to innovate within the restrictions of MV3, it's clear that this isn’t just a one-time issue — it’s part of a larger, ongoing struggle between user needs and platform policies. Problems like this have become more frequent since the shift to MV3, and when they occur on major platforms like YouTube, they emphasize the deeper conflict between protecting user privacy and security and allowing for a customizable web experience.

So what can you do as an ad-blocking user to mitigate longer filter update delays such as this one? There are a couple possible solutions:

• Get a standalone, system-level ad blocker like AdGuard for Windows or AdGuard for Mac. It will filter the traffic of your entire device and will not depend on any browser when it comes to filter updates. On top of that, the capabilities of a system blocker are exceeding what a browser extension can do.
• Switch to a different browser. Mozilla and other Gecko-based browsers do not rely on Manifest V3 and are not affected by its limitations, while browsers like Brave or Mullvad offer built-in protection from ads and trackers.

Our paths first crossed in October 2025, when Henry Fisher, the owner of TechLore and the moving force behind it, visited Ad-Filtering Dev Summit. Henry had a presentation and took a series of short interviews with attendees, including some of the AdGuard folks. That’s when the idea of a larger-scale interview with Andrey first came up.

In this interview, Andrey and Henry spoke about AdGuard’s history, philosophy, and vision, how DNS filtering differs from local ad blocking, Apple’s new groundbreaking API, and many other topics. Enjoy the video version of the interview or find the (slightly adapted) text version below.

The interview was recorded a few weeks ago. Whenever it applies, we provide the necessary updates, taking into account the more recent events.

The interview turned out to be over an hour long, so to help you navigate through it, we added a table of contents. If you don’t want to read through it all, feel free to use it to jump straight to the topic that interests you.

Table of contents:

The history of AdGuard
Different types of filtering
Local filtering: advantages and concerns
How AdGuard compares to other ad blockers
On AdGuard pricing
Where is AdGuard located?
AdGuard’s stance on open-sourcing its products
AdGuard’s role in the ad blocking community
Mitigating attacks on privacy
Why people use ad blockers
Apple’s new API

The history of AdGuard

(H)enry Fisher: Hello, today I have Andrey from AdGuard on Techlore Talks, and I would love to hear a little bit about yourself just to kick things off.

(A)ndrey Meshkov: Thank you for inviting me. Let me tell you a bit about myself. We started AdGuard 16 years ago, when I was a freshman, just out of university. After working at some company for a while, I thought it would be better to start something on our own. But that’s not how AdGuard actually came to be.

Initially, we tried to launch a different kind of startup. You may have heard of SimilarWeb, a company that analyzes web and app popularity using data from all over the place. About 17 years ago, we tried to do something similar.

Back then, we were on the other side of the barricades. In fact, we didn’t even know there were any barricades. We just thought it was a great idea to let people see how popular certain websites were, based on data collected from panelists. [Editor’s note: panelists are pre-selected, consented individuals who agree to have their online behaviors and browsing habits tracked over time.] But eventually, our money ran out. Even before that, we started to realize how much we knew about these panelists — just from their browsing history. At the time, there was no real data market, so we hadn’t thought much about it. But soon, it became clear: it wasn’t great that we knew so much about people who were supposed to be anonymous.

After running out of money and firing everyone, it was just the three of us left. We thought, “We should start something different.” That’s when we decided to create an ad blocker. And that's how AdGuard came to be. We made it a premium product, thinking we could make a living simply by asking people to pay for it. We launched the first version in 2009 or 2010, and I wrote it all myself. That was the beginning.

Over time, things evolved. We expanded beyond just ad blocking, aiming to have AdGuard on every device where it was possible to block ads and tracking. That led to multiple versions of the product. Once we reached the limits of devices to put AdGuard on, we decided to go beyond and created AdGuard DNS.

We then started thinking, "We’re blocking ads everywhere — what else can we do to help people protect their privacy?" That’s when we launched AdGuard VPN. More recently, we introduced AdGuard Mail, an email relay that hides your real email address when signing up for websites.

So, that’s a brief history of AdGuard.

H: It’s interesting, because of the people I’ve interviewed on the podcast that run projects and services, the most common bucket that I see is pre-Snowden and post-Snowden, in terms of their motivations.

A typical story by the people who are pre-Snowden is “I was developing an email provider and I realized I could just read everybody’s emails.” And then there are people who are post-Snowden who read what happened, got a bit spooked by it, and then decided to do something about it. So it’s always fun to chat with people who are pre-Snowden who got ahead of things.

A: When I read about Snowden and when I took a look at all the information that he showed the world, I didn’t believe it at first. It took some time to start believing in everything because it just sounded completely unrealistic. I still wouldn’t say that I believe 100% of that, but I believe much more than in the beginning. It’s still just too fantastic.

H: Yeah, it’s pretty spooky stuff.

Different types of filtering

H: So, from what I understand, you guys started with local filtering. Correct me if I’m wrong, but this is something you install directly on your computer — could be macOS, could be Windows, could be Linux. It essentially filters all the traffic, kind of like how a firewall might work, based on the filters you’ve set up.

Now, you also offer DNS filtering and a VPN, which can all be used together with the local filtering. So, these three tools can be combined. Could you expand on the different threats each of these tools addresses, and how all three might come in handy to someone?

Why not just rely on local filtering? What types of ads does it block, and why does this go beyond just ads? Could you explain what else is blocked through AdGuard?

A: Let’s start with DNS. To understand our motivation, it helps to yet again touch upon AdGuard’s history, and that will also explain the difference.

Before we developed the very first version of AdGuard DNS, we had apps for every major platform — Windows, Android, iOS, and so on. This was back in 2016 or 2017, when smart devices were becoming really popular. The problem was, there was no way to cover these devices just with installable software. So, we started thinking, “What’s the easiest way to give users control over all their devices?”

The easiest way to do that was actually DNS filtering. For anyone unfamiliar with DNS, let me explain what DNS is. Every device on your network typically works with domain names, not IP addresses. Domain names are easier to remember, and you can control them — change where they point to.

Whenever a device wants to connect to a website, it needs to contact a DNS service to figure out which IP address a domain name points to. DNS is a great place to do two things: first, you can monitor network traffic and see where your devices are trying to connect. And there is another side to it — it is a good way to prevent connections that you do not want to happen.

For example, you can make a domain point to a non-existent IP address, and the device won’t be able to connect. That was our motivation — to give people the ability to block tracking, ads, or anything else across their whole network — not just on their phone or computer, but also on smart fridges, TVs, light bulbs, all this stuff.

The problem with DNS, though, is that while it’s easy to set up, it’s not fully under your control. We run the servers, and you can trust us — or not, and that’s fine. So, we thought, “How can we give people full control?” That’s when AdGuard Home came into the picture.

AdGuard Home is basically a DNS server with filtering capabilities that you can install on your own device or server. With it, you are completely in control of your network, without relying on any third-party company or person. It’s open source, completely free, and we don’t make any money from it. It’s just proper open source, I guess. Free and open-source software.

But DNS is not enough, there are limitations. First of all, you can’t block all known trackers and ad servers on the DNS level, as some ad networks use multipurpose domains. Let’s take Facebook, for example. They use the same domain for both ads and for serving your Instagram feed. If you block that domain, you effectively break Instagram for yourself.

The other problem is, although you can block many trackers, some will still collect information about you. They can match your browsing history through your IP address.

That’s where the VPN comes in. Besides just changing your location, a VPN gives you a shared IP address, meaning it’s not tied to just you but to multiple VPN users. This way companies can’t rely on the collected IP address data because it doesn’t identify you or anyone else. This is another way to protect your privacy.

There’s one more challenge. With how the world evolves, browsers and operating systems — but mostly browsers — are not too happy about providing ways to easily track users, in the form of cookies, for instance. So they constantly work on improving their own privacy protection tools. This leads to ad companies seeking to use persistent identifiers, something that can be tied to you, something that you use in different places, something that can track you across all kinds of websites or apps.

And the ideal persistent identifier is your email address. So that’s the last thing that needs protecting. There should be a way to stop using the same email address for all your accounts, otherwise it becomes another way companies can track and identify you.

Local filtering: advantages and concerns

H: I would like to ask about your individual services and how they compare to some alternatives, but before that I just want to clarify something about the local filtering. As far as I understand, it is independent of the DNS, independent of the VPN and of the mail. How exactly is it different from the DNS or the VPN?

I have Brave browser set up on my desktop, and I have AdGuard running, and somehow AdGuard is able to block things in my browser, which is not happening via DNS, so can you explain what’s going on here?

A: Another thing going on with your computer is that you have many apps — Brave included, though it’s not limited to Brave — that try to connect to the network, whether to download something or upload information to the internet.

Depending on the operating system, there are different ways to intercept these network connections, right on your device. Each operating system offers different methods, but the main idea is that it is possible to intercept these connections. AdGuard is capable of doing that — it intercepts every network connection, inspects it, and compares the signatures to a set of rules that it downloads from the internet. But not just from anywhere.

We actually maintain all these rules in an open repository on GitHub, it’s open for inspection. Every version of AdGuard relies on a set of open-source rules, which we and other contributors maintain. So AdGuard compares your web requests to these signatures, finds the applicable rules, and then interprets them. Essentially, AdGuard, and any ad blocker for that matter, acts as an interpreter for a specific set of rules, which follow a special syntax shared by many ad blockers.

Ad blocking is an interesting field because we collaborate with other ad blocker developers. We come up with all kinds of new rule types, and we purposefully try to make them cross-blocker compatible when possible. Which is sometimes not. For example, AdGuard, as a network filter, can do things that aren’t possible at the browser extension level.

But for the most part, the core syntax remains the same. We make it the same, which is how we manage to have such a diverse community maintaining filter lists for different ad blockers. They communicate with each other and help each other, which is pretty cool, I think.

H: I’m sure a lot of people listening will go “oh, okay, so you intercept my web traffic.” So that means you now have to trust AdGuard. Do you mind clarifying what stays local on someone’s device and what’s actually internet connected? And does this pose any security or privacy concerns?

A: Yeah, yeah, that’s a good point, and it applies not just to AdGuard, but to every ad blocker. Ad blockers are powerful pieces of software, so they have very broad permissions, and that’s important to keep in mind.

It often happens that people just google for an ad blocker and install the first thing they find. They’re used to ad blockers being powerful software with broad permissions, so they blindly trust whatever they install, but that’s not a good idea. You should actually learn more about the developer first, to figure out whether you can trust them or not.

There have been many cases where people installed fake ad blockers, or ad blockers that were later sold to someone else and started collecting browsing history. It’s an unfortunate consequence of ad blockers being so powerful. But we need that power to block ads and tracking, so it’s kind of an unsolvable problem.

As for intercepting traffic, here’s what you need to know: the traffic is intercepted locally, right on your device. Nothing goes to our servers or anywhere else. What we do is decide whether your request goes through or if it gets blocked. The decision is made right on your device, by the software you use.

It could be AdGuard, it could be uBlock Origin, AdBlock Plus, Ghostery, or any other ad blocker. That’s essentially what all of us do. The difference lies in when the request is intercepted. Then, we just decide whether it goes through or gets blocked.

My point is, you need to be aware that an ad blocker has a lot of permissions. If you use a software like that, take the time to learn about the developer and decide for yourself whether you want to trust them.

How AdGuard compares to other ad blockers

H: Yeah, definitely good advice. So would it be safe if someone installs AdGuard on their devices? It downloads data, it downloads new rules, it gets updates, but it’s not going to be uploading that person’s web traffic, everything happens locally in the program? Theoretically, if there was a way to disable internet access to AdGuard, it would still function properly, assuming your traffic could still go through the network. Would that all be fair to say?

A: Yeah, yeah.

H: So back to my use case, because I have Brave and AdGuard running [simultaneously] right now. How does this compare to just Brave’s protections? Nowadays, we’re starting to see more things built out of the box. Mullvad browser has uBlock Origin built out of the box, Brave has its own shields. Some other browsers have built-in ad blockers. Why would anyone use AdGuard if their browser already has some protections in place?

A: AdGuard comes in different versions. You’re using the full-scale network filter, but there’s also a browser extension, which is pretty much an alternative to uBlock Origin with similar capabilities.

So, what’s the difference between the browser extension and the network filter? There are several key differences. The first one is that, in the browser, the extension only sees and controls what the browser allows it to see and control. In every browser — be it Brave, Mozilla, or especially Chrome — your browser extension is limited and doesn’t have visibility into certain internal requests, like those going to the browser settings. That’s the first difference.

The second difference, which is also important, is that a network filter isn’t just limited to the browser. It can also block tracking and ads initiated by your apps, which isn’t as well-studied as web tracking. Everyone knows about web tracking, like Google Analytics and Google DoubleClick, which are ubiquitous on the web. But no one studies the kind of tracking happening inside apps.

Many apps use Google Analytics, Google Tag Manager, and other similar tools. On top of that, apps have much more permissions than websites do. Any app you have installed — even something like a text editor — sees and knows far more about you than a regular website. Apps have access to your computer, and can inspect your files and properties. Imagine what kind of information, even inadvertently, could be shared with tracking services.

Lastly, browser extensions aren’t just limited in what they can see — they’re also limited in what they can do with web requests. This is especially important given the recent Manifest V3 changes in Chromium, which severely limited what ad blockers can do in Chromium-based browsers.

You probably don’t feel it right now because we’ve been able to work with the Chromium team and shape the API in a way that covers most of our needs. But what’s been crippled is the ability to improve it further. It now takes much more time to implement changes — it may take years to introduce a new feature in MV3.

A network filter isn’t limited by that. We can innovate and adapt much faster than browser extensions can.

H: Got it. So, what I’m hearing is that these tools can all be swapped out, and actually, the next section will touch on this a bit. It doesn’t necessarily matter if it’s all AdGuard; it’s just that these different threats target different parts of the stack. So, for anyone listening, there are various ways to handle these issues and different tools to use. You might have your browser and browser extensions to block things within your browser, local programs to do system-wide filtering, DNS filtering, and a VPN. Then, there are additional tools that can work on top of all of that, like email aliasing, phone number aliasing, and so on. Is that a fair way to put it?

Okay, now, the fun part. If you want to give the same answer for some of these, like, “Hey, we like our UI and we think it’s the best,” that’s fine. But I’m just curious — what do you think sets you apart from some of the competition for each of these products?

I wanted to start with your extension — the AdGuard extension. I think I can already guess, at least for iOS on Safari, because I haven’t found anything better that works as well. But I’ll let you go ahead and explain how your extension is maybe different or how your approach differs from most of the alternatives, like uBlock Origin.

A: As far as I remember, uBlock Origin takes a very different approach on iOS. Essentially, it migrated its MV3 version to Apple. AdGuard still uses the older approach — the Safari Content Blocking API. And we would actually prefer to avoid migrating to MV3 on iOS.

We don’t like how it’s implemented in iOS Safari right now. There are some minor issues that can be really annoying for users. So, we stick with an older, a bit different but more tested approach.

But other than that, uBlock Origin comes as a static bundle. It can’t change the way rules are interpreted without updating the app. This is actually a common issue on Apple devices — many ad blockers can’t update their rule sets without updating the entire app.

AdGuard took a different approach from the start. We developed our software so it could download new sets of rules and apply them without needing an app update. And in order to do that, we created a library — sorry if I’m getting into too many details, but maybe this will be interesting to some.

So one of the issues with Apple’s approach is that they invented their own method for content blocking. Instead of relying on the rule syntax the ad blocking community had been developing for years, they came up with their own syntax, which is quite limited compared to what we had before on other platforms. They essentially told everyone, “You need to use these rules. We don’t care that you have millions of rules written in different syntax for other ad blockers. You just have to redo everything.”

Of course, we didn’t like that. We didn’t want to redo all that work, so we created a library, an open-source library, by the way, that’s used by many other ad blockers (I hope they at least mention us somewhere). This library can take traditional ad blocking rules and convert them into the syntax that Safari understands.

And we continue to maintain it. It is a good, fast library, and we maintain it and improve it all the time. It gives us the ability to dynamically change the way we do the work, the way we update rules and apply the changes. It also lets us offer you different settings to customize — to add your own rules right in the app and choose what to block, what to unblock, and so on.

I wouldn’t say we’re completely satisfied with this solution at the moment. But I can say that on this platform, with the capabilities we have in Safari, this is probably the best you can do. There’s no other way to improve things further within Safari’s restrictions.

H: Yeah, and I know you talked about the new API in Cyprus [Editor’s note: at the Ad-Filtering Dev Summit 2025] that I’ll ask you about later as well. But what about for desktop? Like if someone’s just using Firefox, what are the differences in the approach between UBO [uBlock Origin] and AdGuard?

A: We use different filtering engines under the hood. So we basically have different code. But other than that, honestly, the two browser extensions are interchangeable. AdGuard’s UI is a little bit different from UBO’s, some people like ours more, some people like theirs more. But in terms of capabilities, UBO and AdGuard Browser Extension are pretty much the same.

H: Got it. And then for the filtering, are there any differences in approaches there beyond just UI and the specific block lists that you choose to use?

A: That’s basically it. We have different filtering engines, but they are very similar in what they do. Actually, we collaborate with UBO’s filter maintainers. We try to maintain cross-blocker compatibility so that their rules could work in AdGuard and AdGuard rules could work in UBO.

H: Very nice. And then there is AdGuard Home — the way I understand it, it’s kind of your own alternative to Pi-hole. Is that correct?

A: Probably, yes — you can say that. We started a couple of years after Pi-hole.

What we didn’t like about Pi-hole at the time (I’m not sure how things are now) was that it was basically a set of scripts that configured dnsmasq.

I don’t want to say anything bad about Pi-hole — it’s a great piece of software. But for me, it felt pretty complicated. It relied on different components like dnsmasq and a PHP admin interface, and those tools weren’t originally developed specifically for this purpose. So you were essentially configuring other software to do the job.

With AdGuard Home, we wanted to build something made specifically for filtering DNS. That makes it easier to extend, easier to add features, and easier to keep developing further.

And it also just looks simpler. If Pi-hole is a set of different tools orchestrated together, AdGuard Home is a single binary that you run, and it just works.

H: So I just pulled it up, and it looks simpler for sure than the Pi-hole last time I looked at it. But I haven’t used either of these, so I can’t really speak to what you said about Pi-hole and if it’s still that way.

On AdGuard pricing

H: I wanted to ask about pricing, too. So if somebody is looking at all these services, what are the pricing models across your ecosystem? It’s probably good not to use specific prices because I know this stuff changes all the time. But just in general, what are the pricing structures that you have? Because I bought, I think, an unlimited plan for filtering.

A: Yeah, we do have a lifetime license, but only for the ad blocker. There’s an option to buy a license once, and it just works — it’s not limited in time, and it’s not limited in updates. It’s a one-time purchase, and you just have it.

But for the VPN and DNS, we only offer subscriptions. Same with Mail. The reason is simple: with DNS and VPN, we have ongoing infrastructure costs to maintain these services.

With the ad blocker, we just develop the software, and the main additional expense is maintaining the filter lists. And honestly, these days, with so many users, it’s not as cheap as it used to be. But whatever — I can’t undo what was done in the past. So we still maintain lifetime licenses, and we don’t plan to change that.

Where is AdGuard located?

H: I wanted to pivot to the company as a whole. I also have a few random questions I haven’t been able to fit in yet. So first: you’re based in Cyprus, if I understand correctly. Was that an intentional decision, or is it just where you ended up?

A: The company is mostly remote. We have a pretty small office in Limassol — I live in Limassol, and part of the team also lives in Cyprus, not only in Limassol but in different parts of the island. But most of the company is remote. We have people working all over the world, honestly — in China, Poland, Germany, South Korea, Japan. Pick a country and there’s probably someone working from there.

H: How large is your team?

A: 170, I guess.

H: Wow, that’s impressive. But what about Cyprus in general?

A: We incorporated in Cyprus in 2014, more than ten years ago. The reason was that, back then, Europe was the most advanced when it came to privacy legislation. GDPR was just emerging, and it’s still a pretty modern law — no one else has really managed to write something at that level.

These days, more countries have strong privacy laws, but GDPR is still kind of the model for all of them. So we thought: okay, we need to be based in a country that actually respects privacy. And if we’re choosing somewhere in Europe, we also need a place we’re willing to live in, which also makes financial sense for running a company. Cyprus was an obvious choice, to be honest.

There aren’t that many countries that are so welcoming to foreigners. Of course, things change over time, but ten years ago it wasn’t that easy to move to, say, a Western European country, run a company there, and not have people look at you strangely. In Cyprus, people are very welcoming. I really can’t say anything bad about it — I love it.

H: Very cool. And yeah, it was beautiful when I visited.

AdGuard’s stance on open-sourcing its products

H: What of your products are open source?

A: Ideally, we’d love to have all our products open source. Unfortunately, for some of them, we still can’t make that decision, and I’ll explain why.

When it comes to open source, AdGuard Home is probably the most popular open-source software we make. Our browser extensions are open source. AdGuard for Safari — the software for macOS desktop and Safari — is also open source. And finally, the iOS version: even though it’s a premium product, it’s open source too.

But this is actually one of the reasons we’re cautious about making everything open source. With AdGuard for iOS, we’ve had a lot of cases where people simply cloned it and uploaded it to the App Store under a different name, without respecting the open-source license, without even mentioning that it’s based on AdGuard’s code. We’re not asking for anything more than that. Just at least mention us somewhere, even on the About page.

H: ‘Don't be shitty’ is the license. [laughs]

A: That’s one of the issues with making things open source. We’ve been saying for a couple of years that we’ll open-source our VPN software, and it’s going to happen very soon — either this month or next month. We’re planning to properly open-source the AdGuard protocol*, because it’s different from most other VPN apps: we have our own, state-of-the-art protocol.

How TrustTunnel differs from a regular VPN protocol

But we don’t want to just publish the code. We want to open-source it together with some client apps, so anyone can take it, set up a server that uses this VPN protocol, take the client apps, and just use them. We want it to be a real open-source project — not “open-sourcing the code” just to tick a box.

Ideally, we’d love other VPN providers to start using it as well. That’s why we’re planning to open-source it under a different name, with as few ties to AdGuard as possible. We just think it’s a good protocol, and it can be useful for others.

AdGuard’s role in the ad blocking community

H: Very cool. I also wanted to ask about your general involvement in the broader ad blocking ecosystem. One thing I learned when I went to Cyprus and attended the Ad-Filtering Dev Summit is that you get all these people in a room — and some don’t see things the same way as others. It’s like trying to satisfy a big group with different perspectives. But it also seems like everyone in the ad blocking world is mostly on the same page, and there’s a lot of collaboration — Ghostery, DuckDuckGo, AdGuard, Firefox, Brave, and so on.

So can you speak to AdGuard’s role in the broader ad blocking ecosystem?

A: It’s not like we’re trying to take a special role or promote ourselves as something. We’re just part of the community. The people who contribute to AdGuard’s filters are part of that same world of list maintainers, contributors, and developers.

And it’s not really one single community, either. There’s the community of filter list maintainers, and there’s the community of ad blocking developers. Those two groups work together all the time, because filter list maintainers — the people who actually create the rules that block ads and tracking — are also the most demanding users we have. They constantly push us to improve the software so they can block more, or block better.

So developers and filter list maintainers stay in contact all the time. We talk to each other, we exchange ideas, and we try to help each other.

As for AdGuard’s role specifically, one thing I find really valuable is the summits themselves. You saw it with your own eyes: people in ad blocking might be a bit different from each other, but they still understand each other very well. We have a lot in common. And when we meet every year, we come up with new ideas that we then take back to our companies — and that helps improve the products.

What’s different about ad blocking communities is that there’s not much competition between us. It’s more like everyone is working toward the same goal, which is pretty cool, honestly.

H: Yeah, that was the feeling I got — seeing all these different products that, to end users, feel like competition. People go online and say, “This is what Ghostery does, that’s why I hate Ghostery and I love uBlock Origin,” and someone else goes, “I hate uBlock Origin,” and so on. But then I’m in a room with all of you, and you’re all like, “Okay, how do we make ad blocking better?” There are new threats, MV3 is making things harder, here’s what we’re doing to address it — and it’s pretty collaborative behind the scenes, which was really cool to see. So I’m glad you spoke to that.

Mitigating attacks on privacy

H: I also have a few random one-off questions that didn’t fit anywhere else in the interview. The first one is this: you see some researchers at these summits talking about very sophisticated attacks. I’ve seen these kinds of things over the years, so none of it surprises me — but when you present it clearly to someone who doesn’t know what’s happening behind the scenes, it can really wake them up.

So I wanted to ask: is there a specific attack you’ve seen over the years that AdGuard had to proactively mitigate — something that struck you as an insane, clever way to spy on people? It could be from a big tech company, it could be from a malicious actor. Just curious to hear your thoughts.

A: I wouldn’t say this is something unique to AdGuard, but I do have an example. It’s not new, but it really impressed me when I first read about it. Several years ago [in 2017], researchers — I think from Washington University — published a very interesting study. To explain what they did, I need to give a bit of background first.

When you open a mobile app and there’s an ad slot — a banner, for example — the app needs a way to decide which ad to show you. So the ad network responsible for that slot runs what’s called an ad auction.

Here’s how it works: the network takes some information about you and sends it to a number of participants in the auction. Each participant looks at that data, compares it to their own database, and then submits a bid — basically, how much they’re willing to pay to show their ad in that slot.

And this happens every time the system wants to show you a banner. So what did the researchers do? They registered a company — I assume that’s the only way to participate. They paid the fee, and they connected that company to the ad network as an auction participant.

Once they were in, they started receiving these signals from the ad network — the same user data that would normally be used for bidding. But they didn’t actually bid. They just recorded the information.

And then they went further. They had a person participating in the experiment, took the identifier of that person’s mobile device, and started filtering for signals containing that identifier. So they were collecting the auction data specifically for one person, or rather one device.

And what they achieved was that they could reconstruct the person’s whole day. They produced a map: “This person lives in this house. Then they go to this bus stop. Then they go to this coffee place. Here is where they work. Here’s where they have a beer after work. And this is the route they take home.”

That’s proper surveillance, and it is very precisely targeted at a single person. And all they needed was one identifier from that person’s device. Basically, spend a thousand bucks and you can spy on someone — your wife, I don’t know.

That’s what scared me. Anyone can spend that kind of money and effectively track almost any person in the world — or more realistically, someone specific you know. You can just follow them. You can stalk them, using capabilities provided by ordinary ad networks.

H: So I assume the two-step way to avoid this is: first, download trusted apps — ideally ones without ads, with a business model that doesn’t rely on advertising in the first place. But if you do have to use an app with ads, then make sure you use some kind of ad blocker. I assume AdGuard on a mobile device would prevent this kind of thing from happening.

A: It’s not that hard to prevent. AdGuard can prevent it — or even a DNS service with ad-blocking capabilities can. So in general, it’s not some unique, unstoppable threat. It’s just scary that this kind of information can be retrieved through an ad network.

H: Right. I don’t think people realize what’s going on behind the scenes. They just see, “Oh, those are the shoes I looked up on my laptop last week, and now I’m getting an ad for them — how fun.” But it’s pretty crazy.

And actually, one of my favorite ad campaigns I ever saw — it was very short-lived, because they pulled the ads — was from Signal. I don’t know if you saw this, but they ran ads, I think on Facebook and Instagram, that used the unique identifiers being collected to generate personalized ads. The message was basically: “We can see you’re on an iPhone, we can see your location, we can see this and that about you.” It was their way of showing how much information ad platforms have. If you haven’t seen it, I recommend checking it out.

A: I haven’t seen it, but I can imagine. And what you’re describing is still a very small, simple example — an easy thing to get. It’s not even full surveillance, but it’s already scary enough. I guess people weren’t very happy seeing ads like that, right?

Why people use ad blockers

H: Right, right. And this leads into another question — I promise I’ll try to keep these brief.

When people hear “ad blocking,” I think a lot of them just think of annoyances. Like: “I don’t want to watch a one-minute unskippable ad on YouTube,” or “this website looks ugly with 30 different ads surrounding the content I actually want to see.”

But there are a lot of other reasons to use an ad blocker. Official U.S. government agencies recently started recommending ad blockers as a basic security measure, to help prevent malware from being installed on your device. And a lot of TechLore community members also see privacy as a major reason to use an ad blocker — because ad blockers can block trackers and the whole ad surveillance ecosystem you were just talking about.

So where do you see ad blocking having a role on the internet? Do you think it’s a mix of all these things? Is there one thing most AdGuard users care about the most? Is it really just that they don’t like ads? I’d love to hear your view.

A: We’ve actually asked people about this in surveys — what they think is most important. And we also watch how people react in practice: how they respond to changes in filter lists, or to cases where the ad blocker suddenly stops blocking ads on some site.

If you combine those survey results with what we see from real user reactions, I’d say blocking ads is the main driver for about 70% of people. Even when users say privacy is the most important thing, for most of them the real motivation is simple: they just don’t want to see annoying ads. That’s what pushes them to start using an ad blocker.

And that’s pretty logical, right? We’re an ad blocker. [laughs] But at the same time, people do care about privacy — they value it a lot. The problem is that they don’t really know what to do. Privacy threats are complicated, and people don’t always understand how to protect themselves. They want a simple button that at least gives them a sense of safety.

And more broadly — looking at the web and the industry — I think ad blockers also play an important role in shaping the ads that other people see.

This is one of the ways people give feedback to big companies that something isn’t okay. Companies read that signal and react. They try to make ads less annoying and more acceptable. Just seeing that signal — how many people use ad blockers — forces them to pay attention and improve the situation at least a little.

I’m not talking about creating some “acceptable ads” standard — that’s not my point. My point is simply that corporations look at ad blocker usage, and they have to react. They have to improve things.

Apple’s new API

H: Got it. And the last thing I wanted to ask about was Apple’s new API. This isn’t something I even knew was happening. It’s not the kind of thing Apple announces loudly at WWDC [Apple's Worldwide Developers Conference] — it’s pretty niche, but it’ll quietly end up on people’s phones. I’m sure people listening to this podcast will appreciate these sneak previews, because I didn’t learn about it until your talk at the Ad Filtering Dev Summit.

Do you mind explaining Apple’s new API — how it differs from what mobile operating systems have today, and what it might enable for users in the future?

A: Apple came up with a pretty interesting idea. Earlier, we were talking about local filtering — intercepting requests, controlling where your device connects, what data it uploads, and so on. Apple decided to give developers something built specifically for this purpose: an API for filtering web requests at the system level. Not just in the browser, not just in Safari, but a way to control where all apps connect.

What’s especially interesting is that they’re trying to make this API truly private. Remember how I said ad blockers usually need very broad permissions to do the job? With Apple’s API, the idea is that it can be safe and private.

So ad blockers won’t actually see the traffic. There won’t be “interception” in the usual sense. The interception will be done by the system. The ad blocker will be asked whether a request should be allowed or blocked — but in a smart way, so the ad blocker doesn’t even learn what the actual address was.

I talked about this at the summit — if someone wants the technical details, they can look that up. But the core idea is simple: give apps a way to filter traffic system-wide, while keeping it completely private — in a way where the developer can’t learn anything about your traffic.

So you won’t have to trust my word. It will be a guarantee that AdGuard doesn’t see your traffic and can’t see it — even locally. We just won’t be able to learn anything ourselves. And at the same time, the goal is still achieved: tracking gets stopped.

H: Yeah, that’s pretty cool. So how does this compare to what we can do today? Because on iOS you can already use DNS filtering, I’m using it myself. How is this new API different from DNS?

A: There are two main differences.

First, with DNS filtering, the app itself knows the domain you’re trying to connect to. That’s obviously required, because the app needs to understand whether the domain should be blocked or not.

With Apple’s new API, the app won’t even know the domain name. It sounds strange, but it will still be able to block bad domains without actually knowing which domains you’ve visited. Pretty smart and interesting solution.

Second, the new API isn’t limited to domain names. Remember how I mentioned Facebook using the same domain for both ads and normal content, like your Instagram feed? This new API would finally let us differentiate: block the ads without touching the other parts of a multipurpose domain.

H: Very cool. And do you have an ETA by any chance?

A: Yeah, the problem is that in order to start using this API, we first need to go through a special review, not just a regular App Store review. We need to apply specifically to get permission to use it.

And we did apply a month ago, or even earlier than that, but we’re still waiting for the response. And as far as I understand, it may take several months to get one. But once we get the approval, it will get implemented very fast.

H: Apple bureaucracy. And it’s funny, because Apple’s approach here feels similar to other things they’ve done: they look at the worst-case scenario — how someone could abuse a permission — and then they come up with some incredible engineering to prevent that. The downside is that it also prevents people from taking the most powerful, “maximal” approach to solving the problem.

You see this with WebKit, for example [an open-source web browser engine]. We don’t really have truly independent browsers on iOS, because everything has to use WebKit. That means you don’t get “bad” browsers — but it also means browsers like Brave can’t do more or make something more powerful. This seems to be Apple’s pattern, so I’m not surprised they did something similar with this new API. [laughs]

A: Yeah. But again, it does have downsides. Still, I have to admit, the way they decided to do it is pretty innovative. I hope they improve it over time, but even as it is, it’s interesting.

For me as an engineer, it’s a really interesting engineering problem to solve — that’s another reason I like it.

H: Yeah — and kind of the last thing. I don’t know if you’ve tested this, or if you already know off the top of your head. One thing I don’t like about Apple — and anything iOS — is that they add a lot of exceptions for themselves.

Apple says, “We’ll give you the ability to use a VPN,” but then their own domains don’t go through the VPN, which is pretty crappy — especially because VPNs on iOS are presented as system-wide, even though Apple excludes its own stuff.

With this new API, are you able to block Apple domains? Or have you tested whether they prevent that from working?

A: One downside of the API is that it’s not transparent what’s going on internally. We don’t see what’s being filtered and what isn’t. So we can only judge indirectly — for example, by checking device logs.

What I can say is that Apple didn’t add direct exceptions for themselves. But there are some limitations in how the API is implemented in general, and those limitations make it possible to bypass it in some cases, unfortunately.

For example, on macOS, the Chrome browser won’t be filtered, simply because of how the API works. It’s not because Apple decided to make a special exception for Chrome — it’s just a limitation of the implementation.

H: I want to give a massive thank you to Andrey for taking the time to explain all these technical things in a way all of us can understand. I feel like I know how to navigate this landscape a little better as a result, and I hope you got the same out of it too.

On behalf of the entire team at AdGuard, we’d like to extend a big thank you to Henry Fisher for inviting Andrey Meshkov to take part in this interview on TechLore Talks. True to the name of the podcast, it turned out to be packed with tech talk, but also with various tidbits and anecdotes from AdGuard’s history. We’re happy to find that Henry himself is a satisfied user of AdGuard products, and we wish him and TechLore only the best in their future endeavors, whatever they might be.

Faster filtering engine startup

The filtering engine, known as TSUrlFilter, powers the extension, blocking unwanted content and keeping pages clean. With this update, the engine starts up twice as fast, so the extension runs smoother, and remains stable even after background restarts.

Native :has support

To block and hide page elements, the engine uses CSS selectors — a fast and reliable way to keep pages clean. Previously, :has selectors were injected by the extension itself using extended CSS. Now, where supported, the engine uses the browser’s built-in :has selector instead. This makes filtering more stable and predictable, while also reducing the load on the system.

Improved HTML filtering

A single filtering method is usually not enough on its own. When ads or other elements try to blend in with page content, HTML filtering comes in handy. It works directly with the page’s structure to detect and remove such elements. This update improves HTML filtering and brings it in line with the latest CoreLibs version, offering more accurate handling of :contains rules.

Restored csp_report blocking

Lastly, about our ongoing work with MV3. After moving to the new architecture, the blocking of csp_report requests stopped working, which could let websites collect additional data on blocked content and user activity. This update restores csp_report blocking in an MV3‑compatible way, bringing back the same level of protection and improving user privacy.

Share your feedback

Have an idea or spotted a bug? Let us know on GitHub or social media — every message helps us make AdGuard even better.

You click.

The page explains how to install Homebrew, a popular package manager. The wording is technical, confident, and familiar. It even mirrors the real installation method — a one-line terminal command that downloads and executes a setup script. The command format looks almost identical to the official one published on the Homebrew’s website brew.sh:

• It invokes bash
• It fetches a remote script
• It runs it immediately

If you’ve installed developer tools before, this feels normal. Expected, even. So you copy the command into Terminal. You press Enter. The script runs. Except it’s not Homebrew.

Instead of downloading the official installer from GitHub, it quietly pulls a malicious payload from an attacker-controlled server and executes it. From your perspective, nothing dramatic happens. But in the background, your machine is now compromised.

If you’re a typical Homebrew user, you are likely:

• A developer
• A DevOps engineer
• A researcher of any kind
• A power macOS user working with code or infrastructure

That means your laptop isn’t just a regular personal device — it may contain sensitive credentials that act as gateways to other systems, repositories, or infrastructure. If your machine stores SSH keys, GitHub access tokens, cloud credentials, VPN configurations, API keys, CI/CD secrets, or read-write access to repositories and production environments, then a malware infection doesn’t stop at your laptop. It turns your device into a compromised entry point — a poisoned link in a much larger chain.

That malware can potentially read configuration files, extract authentication tokens, and exfiltrate them to a remote command-and-control server. With stolen credentials attackers can incur massive damage. The scope of it is almost infinite and as to how devastating the impact can be depends only on your imagination.

We’ll list only some of the scenarios that are far from being far-fetched. Once attackers have your credentials, they could insert malicious code into a public or private repository. Once added to the repo, the code can spread when it’s used in shared libraries or deployments, turning what seems like a normal update into a hidden threat that eventually reaches other projects and users.

The attackers might tamper with the build process or release files, so that even software that looks official is secretly compromised. They could publish backdoored versions of widely used packages, spreading malware far beyond the original target. And with access to company networks, attackers can move through internal systems like ghosts, reaching sensitive databases, private servers, or production environments — all starting from that one infected laptop.

Facts, or how Google ads pushing Claude links have become poisonous

You’ve probably guessed by now that all of the above is not just a figment of our imagination — not a fever dream, although we would like it to be so. All of that actually happened and potentially affected thousands of people. As of February 11, when we began monitoring the campaign, one the pages promoted by these ads had already received around 10,000 clicks. By now, the two pages we identified received roughly 25,000 clicks in total (a bit over 20,000 on one and 4,300 on the other), according to their own built-in counters, while the number of ad impressions was likely much higher.

The attack is striking in its simplicity and scale. Here’s how it transpired step by step in practice:

• An attacker creates a public, user-generated artifact on claude.ai containing instructions for installing Homebrew.
• The page follows the same installation pattern as the official instructions, but the command is replaced with one that is base64-encoded and designed to download and execute a payload from an attacker-controlled server.
• The attacker then purchases Google search ads targeting queries like “brew macos” or “brew install.”
• Because the ad snippet displays the trusted claude.ai domain, users are more likely to trust the link and click it.
• Users land on what appears to be an official Claude page, but is in fact user-generated content controlled by the attacker.
• The base64-encoded command (we established it has a botnet-related URL) fetches and immediately executes remote code — a classic malware delivery technique. This all happens unbeknownst to the user.

There were several pages like this, promoted via Google Ads by different fake entities, with a cumulative view count of around 25,000. While it’s impossible to know how many of those views turned into actual executions of the command, even a small fraction would be enough to cause serious damage, given the kind of access and credentials typically present on developer machines.

Importantly, these pages were not created by the Claude team. They were user-generated content (UGC) hosted on the claude.ai domain. That said, the way this UGC is hosted and presented is itself part of the problem. Placing user-generated content on the main second-level domain (claude.ai) may be justifiable from a business or SEO perspective, but it inevitably creates an unjustifiably high level of trust in that content from the user’s point of view. For most users, a page living on claude.ai looks indistinguishable from an official Claude page, which makes confusion not just possible, but likely. The disclaimer that the content is user-generated is placed at the top of the page in small, barely visible print, making it easy for less inquisitive users to miss. Moreover, the disclaimer is not visible at all when the page is viewed on a phone.

In that sense, responsibility for the resulting trust abuse does not lie solely with the attackers or Google that let the ad be placed: the domain and UX choices lowered users’ guard and amplified the effectiveness of the campaign.

When time is of the essence

It’s worth stressing that we reported this incident immediately after discovering it. The timeline looked like this:

• February 11, 15:00 UTC — A report was filed with Google Ads
• February 11, 16:00 UTC — A public disclosure was posted on X
• February 11, 20:00 UTC — A report was sent to Claude

Despite this, the malicious pages remained accessible for hours. Moderation of user-generated content (UGC) on Claude.ai proved to be slow: the specific page we reported was only taken down 16 hours later. By that point, it had accumulated roughly 21,000 visits in total during the period we were tracking it.

Even more concerning, other malicious artifacts remained live even after that. At least one similar page is still accessible and has collected around 4,300 clicks as of the time of writing. In other words, while the initial report was handled eventually, the overall response lag allowed the campaign to continue operating and attracting new victims well after the issue had been flagged.

What makes this malware poisoning campaign so clever

From our perspective, this attack has the potential to be particularly effective because it combines trust at every stage with extremely precise targeting.

At a high level, it creates a dangerous trust chain:
Ad from a Google-verified publisher → Official Сlaude.ai domain → Execution of hidden code

That chain dramatically increases the chance that users will run the command without closely inspecting it.

More concretely:

• Trust presumed at every step
• The ad shows a real, recognized domain (claude.ai), not a spoof or typo-squatted site (and many users don’t pay much attention to the “Sponsored” label).
• Clicking the ad leads to a real Claude page, not a phishing copy.
• The text is written in a convincing, technical style and looks exactly like the kind of instructions developers expect.
• The installation flow mirrors the legitimate Homebrew one, including a one-line shell command (which, to be fair, already looks a bit scary even in the official version).

Here we need to provide a brief explanation. The legitimate site is https://brew.sh/, and the legitimate install command is:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Which, to some extent, already looks exactly like the kind of thing security people warn you about. It downloads a script from the internet and immediately executes it with bash. This pattern is precisely the same pattern used by real-world malware droppers. Of course, in this case the command is legitimate and points to a well-known GitHub repository maintained by the Homebrew project. But from a purely mechanical point of view, the workflow is identical: you are trusting a remote server to give you code, and you are executing that code without inspecting it first.

But this is only one component that contributed to the attackers’ success. The other is a perfectly matched target audience.

• The target audience consists of users who actively want to install Homebrew (brew); otherwise, they wouldn’t be searching for it in the first place.
• The audience likely does engineering work and has corporate access, SSH keys, GitHub tokens, and other credentials.
• The audience expects to run a command in the terminal and is not surprised by that at all. In other words, the malicious action is perfectly embedded into a normal, expected workflow.
• Since the ads are shown for queries like “brew macos” or “brew install,” Windows users or those not interested in Homebrew won’t see them. That makes the traffic highly relevant.

Another factor is how cheap and easy this attack is to scale. There is no need for fake domains and no need for social engineering in direct messages or emails. The attacker simply creates a page on a trusted domain, buys ads, and lets the Google’s own traffic do the rest. From the attacker’s perspective, the operational effort is minimal. There is no complex infrastructure to build and no prolonged interaction with victims. Create the page, launch the ads, and the distribution happens automatically. Once the ads are live, the reach is limited only by the ad spend and the traffic, turning a small setup into an efficient and potentially large infection funnel.

From our perspective, taken together, this created something close to a perfect storm: a familiar and widely accepted installation pattern, a highly trusted distribution channel, and an audience with the potential to cause significant damage down the pipeline with exactly the right intent at exactly the right moment. While we do not condone the attackers’ actions in any way, it’s hard not to notice a certain grim “elegance” in how efficiently all these pieces were made to fit together.

What conclusions can be drawn from this

This attack demonstrates how quickly trusted domains and platforms can be weaponized. Users see a link to a legitimate domain, follow instructions that appear normal, and unwittingly execute commands that compromise their machine. One click can turn a developer’s laptop into a gateway for stealing credentials, injecting malicious code into repositories, or tampering with builds and releases among other things.

The consequence is clear: Google Ads + a well-known trusted platform + technical users with high downstream impact = a potent malware distribution vector. Even a single infected endpoint can set off a supply-chain chain reaction affecting thousands of users downstream, far beyond the original target.

Just as importantly, this incident also shows why this was possible in the first place.

First, there is the long-standing problem of poor ad moderation on Google’s side. This is not a new or isolated issue. While the sheer volume of ads Google has to process may partially explain the problem, it does not change the outcome: malicious campaigns continue to slip through and reach large audiences. Similar cases have been documented before, for example in this analysis of the Bumblebee malware campaign abusing Google Ads.

Second, there is the lag in Claude’s moderation of user-generated content, combined with a questionable product and domain design choice. Hosting unverified, potentially dangerous UGC on the main second-level domain (claude.ai) effectively lets that content inherit the brand’s trust.

Taken together, this was not just a clever attack — it was a systemic failure across multiple layers: advertising review, platform moderation, and trust signaling.

That said, we hope that this incident will serve as a cautionary tale for both companies and lead to swift fixes. Given the scope of the problem, thousands of people may already be caught in the crosshairs or at risk of falling victim. It is in the interest of Google, Anthropic that owns Claude, and most importantly, users that these issues are addressed as quickly as possible.

Update (February 13)

We observed the same tactic being reused by the attackers, with one notable change. Instead of hosting the poisoned instructions on claude.ai, the malicious page was published on share.evernote.com, a third-level domain used for user-generated content on Evernote. The mechanics of the attack remained the same: a seemingly legitimate UGC page on a trusted platform was used to deliver a harmful command, showing that this approach is not tied to a single service like Anthropic’s Claude, but can be replicated across different popular platforms that host user content.

Ads are set to roll out to free and lowest-tier ChatGPT users in the US in the coming weeks if not days. Some users have already gotten a sneak peak via a beta version released last week. In that beta, ads appear below the response window and are clearly marked as “sponsored.” They are personalized by default, with targeting based on both the current conversation and a user’s historical chat data unless the user opts out of ad personalization. In that case, only the chat directly tied to the prompt is used for ad targeting. OpenAI has also emphasized that no user data will be sold and that the ad experience will remain as holistic as possible.

On paper, these assurances sound good — perhaps too good. OpenAI CEO Sam Altman’s stance on ads has shifted over time, from a self-professed hatred of ads as an aesthetic choice to a more pragmatic “good if done right.” That alone makes it hard to rule out a future where ads creep into more parts of the chatbot experience. And while that may not happen anytime soon or at all, it’s difficult not to imagine how easily it could.

Anthropic’s jibe is crude, but concerns are real

Anthropic, an OpenAI rival founded by former OpenAI researchers and best known for its Claude chatbot, has seized on the ad debate — and the way it chose to do so says a lot about how intransigent the AI arms race has become.

Still from an Anthropic ad. Source: Anthropic/YouTube

Anthropic has published several short video clips, each showcasing a familiar scenario in which users turn to chatbots for help: looking for workout advice, brainstorming business ideas, getting help with academic work, or figuring out how to communicate better with a family member.

The videos, posted to Anthropic’s YouTube channel and set to air during one of the biggest advertising moments of the year — the Super Bowl on February 8 — all follow the same structure. They begin with a chatbot offering advice that seems reasonable, thoughtful, and genuinely helpful only to derail abruptly into an ad that is completely tone-deaf. A personal trainer representing the AI agent suddenly starts recommending shoe insoles that add a vertical inch and help “short kings” stand tall. In another clip, the agent veers away from business advice to pitch a sketchy loan service. In yet another, a therapist talking to a user about his relationship with his mother suddenly trails off mid-sentence to serve an ad for a dating app where he can meet older women.

All the videos wrap up with the screen flashing: “Ads are coming to AI. But not to Claude,” set to Dr. Dre’s “What’s the Difference” playing in the background. The ad has uncanny parallels with Black Mirror episode Common People, which imagines a world where a character survives a life-saving experimental brain procedure only to discover that staying alive now requires a monthly subscription. As costs rise, she’s pushed onto an ad-supported tier, causing her to involuntarily blurt out ads mid-conversation that are highly inappropriate, although can theoretically follow from the context. In one instance, a student tells her that his parents are fighting and his mother wants to leave his father, and she suddenly recites an ad for a Christian family counseling website encouraging families to stay together. In another, she interrupts an intimate moment with her husband to recommend an erectile dysfunction gel. The only way to stop it is to pay for the ad-free that is very expensive. The episode exaggerates the fear Anthropic highlights: monetization intruding at moments where it is deeply inappropriate and jarring. And unlike with traditional search ads, it feels way more personal if it’s a chatbot that mirrors human speech patterns.

This is a discussion worth having. After all, chatbots are rapidly becoming a staple of everyday life. We increasingly hear stories of people growing dependent on ChatGPT, of AI companions turning into emotional stand-ins, even love interests, and of conversational bots becoming a kind of cognitive crutch, something many can no longer imagine living without.

As Denis Vyazovoy, Head of Product at AdGuard, points out:

“If advertising models start becoming more deeply integrated into AI assistants, it raises an important question of trust. Users perceive these services not as media platforms, but as helpers. Any hidden commercial motivation, even in the form of recommendations, needs to be as transparent as possible. The very fact that major AI developers are debating this issue shows that the market has yet to settle on the ethical boundaries of monetization, and right now is the perfect moment to have that conversation.”

In that sense, AI is starting to resemble the personal computer in its early days, back when it quietly but permanently reshaped how people worked and thought (bless those simpler times). So if ads in AI agents are indeed heading in the direction Anthropic warns about, alarm bells should be ringing.

Deceptive ‘doublespeak’: OpenAI’s response

Are they, though? So far, it’s hard to tell, since ads in ChatGPT are still yet to roll out widely. OpenAI CEO Sam Altman responded directly to Anthropic’s jabs in a post on X, pushing back against what he called a misleading critique.

“I guess it’s on brand for Anthropic doublespeak to use a deceptive ad to critique theoretical deceptive ads that aren’t real, but a Super Bowl ad is not where I would expect it,” Altman said.

He claimed that ChatGPT would never run ads in the intrusive way Anthropic depicts. Altman took the opportunity to contrast the two companies, calling Anthropic elitist for selling a niche, expensive product to a small, wealthy audience while highlighting ChatGPT’s democratic reach which manifests itself in free access for billions of people, with paid tiers optional and ad-free. “More Texans use ChatGPT for free than total people use Claude in the US,” he noted. Altman also framed the debate as a matter of control versus openness. While Anthropic blocks certain companies from using its coding product and positions itself as an arbiter of how AI should be used, OpenAI pitches ChatGPT as a broadly accessible tool.

Historic parallels: a well-trodden path

Cutthroat competition drives cutthroat advertising. Anthropic wouldn’t have launched such jabs and poured money into one of the most coveted ad slots just for the laughs. The company is clearly putting serious cash on the line: the 30-second Super Bowl spot reportedly costs over $8 million, and the longer pre-game ad, showing a man asking for help communicating with his mother, apparently costs a dime too.

Offering one of the most expensive AI models on the market (Altman wasn’t kidding when he said it was made for rich people), Anthropic has long been regarded as best for specialized tasks — most notably coding. But with OpenAI poaching Anthropic’s talent and cranking out new models — most recently GPT-5.3-Codex — there’s little time for sentiment. In this AI arms race, any means are justified: all is fair in love and war.

Anthropic is also clearly taking a leaf out of Apple’s playbook with its Super Bowl push. Like the iconic 1984 ad, which positioned Apple as the rebellious underdog taking on the monolithic IBM, Anthropic’s ads are designed to make a statement by mocking ChatGPT and portraying Claude as the pure unbiased choice. The impact from the Apple ad back then was immediate and measurable: reports at the time indicated that around $3.5 million worth of Macintosh computers were sold shortly after the ad aired.

The difference, of course, is that ChatGPT positions itself as the democratic alternative, while Claude remains, arguably, a high-end product for a select few. With this ad, Anthropic may be attempting to change that perception once and for all. The big question is whether this push succeeds or backfires. But Anthropic also courts a big risk: should it ever try to introduce ads of its own, it might wake up to a full-blown PR firestorm of its own making.

The onboarding screens tell you about what ads you are going to see and why, teach you about ad controls and, most importantly, reassure you that the chatbot’s responses themselves will remain unaffected by advertisers.

The ads you see will depend on your current conversation with the chatbot — however, OpenAI claims that the advertiser will not get access to your chats, memories, or any personal information, only to aggregate ad view and click counts. Other factors that will influence the ads you see include your past conversations and your history of interacting with previously seen ads, both positive (clicking on the ad) and negative (hiding the ad). Yes, you will be able to hide the ad from an overflow menu. The same menu will offer you more information about the ad, an option to report it, or even “ask ChatGPT” about it.

Screenshot by Tibor Blaho on X

If you request more information about the ad, a pop-up will display basic details, like who the ad is sponsored by and why you are seeing it, alongside with a button to purchase an ad-free subscription, of course.

Screenshot by Tibor Blaho on X

Finally, and potentially the most important part of it all, is the “Ads control” page. On it, users will be able to turn off ad personalization, but not entirely. The current chat will always retain at least some relevancy to the displayed ads, although it’s not clear to what degree. At the same time, you can completely toggle off personalization based on past chats and memory. Notably, it will also be possible to delete all ad-related data without affecting any of your chats.

Screenshot by Tibor Blaho on X

As much as we may not be thrilled about ads invading yet another digital space, we have to admit that the initial implementation, at least, could be far worse. Time will tell if this ad format is going to stay the same for the foreseeable future. Will OpenAI follow the path of many other companies, starting with reasonable ads but eventually sliding into more intrusive formats?

Either way, for now it looks like we’re dealing with precisely the type of ads we predicted in our previous article — outside chatbot’s reply window, clearly separated from the actual reply and labelled. Any ad blocker worth its salt (including AdGuard, of course) should be able to block such ads without any issues — that is, in the web version. Blocking ads inside apps on Android is much more tricky so we’ll reserve judgement until we can see those ads with our own eyes.

First question is from katy perry's boyfriend:

I've been online for ages, and I'm guessing my personal data is probably already out there for anyone who's interested. Does it make sense to start using ad blockers and VPNs? Or how can I start living a more private life after years of shitposting ? It seems a bit pointless now

First of all, it’s understandable to have regrets about all the data we’ve shared throughout the years, especially when we did not know better. However, unless you’re living completely off the grid, it’s impossible not to leave a trail of personal data behind. The real question isn’t whether that trail exists but how accurate and how distinct it is. As for having already left a trail, the truth is, you can’t be a purist in the digital age without a massive tradeoff in convenience, and very few people are in a fundamentally different position. In fact, younger generations arguably have it worse thanks to “sharenting,” which doesn’t mean they should give up on privacy from the start. Chances are, you’re actually in a better position than them. The key point here is that information is valuable mostly while it’s current. You can’t turn history back, but you can make sure that whatever you leave online from this point onward is limited. And data only really works as long as it’s searchable and linkable to you which means there are ways to blunt its impact.

From there, the goal isn’t to erase yourself from the internet, but to slowly make yourself less legible. Put simply, the goal is to make the data you leave behind fragmented, harder to link together, or less accurate, so anyone trying to track you, target you with ads, or aggregate your personal info will get a muddled picture rather than a “readable” profile.

Even small, boring changes in how you go about digital hygiene matter, and compound over time. One of those is clearing cookies and cache, especially if you automate it. In Chrome, you can configure on-device data to delete automatically upon closing. Similar features are available in most popular browsers. This doesn’t make you anonymous, but it does prevent long-term tracking from neatly stitching together months or years of behavior. The tradeoff is that you'll log out more often, and things will be a bit less convenient.

The same logic applies to separating contexts. Keeping work, private life, and casual online activity from constantly bleeding into one another makes profiling harder. Whether that’s separate browser profiles or separate email addresses, you’re making it harder to link different parts of your life. In this regard, using email aliases and temporary addresses can help. Aliases are useful for accounts you actually use but don’t fully trust with your main inbox like newsletters, shopping sites, or online services you want to keep separate. Temporary addresses are great for one-off sign-ups, trials, or downloads where you don’t expect or want any follow-up.

Social media works similarly. Simply reducing discoverability can go a long way; one example is opting out of search engine indexing, which you can do on Instagram. Other measures include changing the name displayed on your profile, switching to a different username (or/and using different usernames for different social media accounts), or limiting who can see your posts in the first place — that is according to recommendations from X, but they are universally applicable. These steps can prevent your profile information and posts associated with it from appearing in search engine results. In short, changing a handle can help disrupt name-based searches, even if it doesn’t erase existing data entirely. And while none of this is a panacea, most data collection relies on ease rather than persistence.

You can also deal directly with search engines. Google, for example, lets you request the removal of private information like your address, phone number, email, government IDs, bank details, medical records, or even confidential usernames and passwords. Use Google’s “Results about you” feature to find and request removals, and you can even set up notifications for new results. Keep in mind that Google can only remove information from its search results — if you want content taken down from the original website, you’ll need to contact the site owner directly.

If there’s one unglamorous but genuinely effective step, it’s dealing with data brokers. Opting out is tedious, but it works, and once done it tends to stay done. You can visit the opt-out pages of sites like Spokeo and Epsilon to request your records be removed. However, given how many of such data brokers are out there, perhaps the most surefire way is to use a specialized removal service.

Beyond controlling what’s already out there, you can also limit how much new data gets collected about you. Ad blockers help stop trackers and third-party scripts from quietly following your activity across sites, which reduces the amount of behavioral data that can be linked back to you. VPNs, meanwhile, mask your IP address and encrypt your connection, making it harder for websites, advertisers, or even your ISP to build a profile based on your location or browsing habits. Neither of these tools makes you invisible, but combined with the other steps such as separating contexts, using aliases, and managing search visibility, they make it significantly harder for anyone to piece together a detailed picture of your online life.

Taken together, none of this is about achieving perfect privacy. That ship sailed for almost everyone a long time ago. What is achievable is making your data older, noisier, and less connected over time. And in practice, that’s usually enough.

Now, second question comes from Elle:

I'm sooo not tech-savvy. If I leave my VPN on, will it stay on when I shut down my PC? Thanks so much for your time.

If you leave your VPN on and then shut down your PC, the VPN won’t keep running in the background once your computer is powered off. When you restart your PC, the VPN will need to reconnect to establish the secure connection again. So, answering your question — no, the VPN won’t stay on once you shut down your PC.

However, most popular VPNs provide an option to automatically reconnect after a system restart, which is a common feature.

With AdGuard VPN, you can streamline this process with a couple of helpful features. First, you can enable Launch app on system startup in the app’s settings. This ensures that the VPN app automatically opens as soon as your computer boots up, so you don’t have to manually launch it each time.

Next, you can enable the Auto-connect on app launch feature. This ensures that as soon as the app opens, it will automatically connect to the VPN without any extra action needed from you. Together, these features make sure that your VPN is ready to protect you right from the moment your computer starts up, with no additional steps required.

Upd. This promotion is over. If you didn’t get a chance to buy AdGuard Ad Blocker, AdGuard VPN or AdGuard DNS at a discount, don’t worry — we often run other promotions. Not to miss the next one, subscribe to our newsletter — we’ll keep you in the loop!

Protecting your privacy and getting to the ad-free Web can be a challenging discipline. Just like an athlete needs the best gear to succeed, you need the right tools to glide through the Web without any hurdles. To help you out, we’re offering special prices on AdGuard products through February 10. Take advantage of these discounts to stay protected no matter what the Web throws at you!

Getting Ad Blocker is a winning strategy

AdGuard Ad Blocker is your first line of defense against ads and trackers. It removes annoying banners, popups, and video ads, so you can focus on what really matters when you’re online.

Lifetime licenses are 40% off, 1-year licenses are 30% off. Already have a license? You can upgrade it to cover more devices or extend it in your AdGuard account.

Skating freely through Web with VPN

AdGuard VPN lets you break through digital barriers — watch your favorite shows and live streams, find lower prices, and protect your connection in public Wi-Fi from hackers.

The most advantageous plan is the 2-year subscription, which is 80% off right now. You can extend your existing subscription at a discount — it’s cheaper than auto-renewal. Simply purchase a new subscription using the same email address.

Defending your home with DNS

AdGuard DNS acts as a protective shield for your devices, blocking malicious websites and unwanted content. Everything at your home that connects to the Internet will stay safe.

The Personal and Team plans are 55% off. If you’re already using AdGuard DNS, now’s the perfect time to extend your subscription — it’ll cost less than auto-renewal.

Securing your inbox with AdGuard Mail

AdGuard Mail is the perfect tool for receiving emails without sharing your personal address. With AdGuard Mail, you’ll get temporary addresses and aliases that you can use instead of your personal email on any service. This way, you can receive promo emails, newsletters, and anything else you want, while keeping your personal address away from prying eyes.

Since the product is new, you can join early and get a subscription for less than half the price.