This version makes a strong accent on the Networking issues. This doesn’t mean everything else was abandoned, on the contrary, there’s been a lot of ad blocking- and UI-related fixes and improvements, just the network-related fixes happened to be the most important ones.
[Fixed] Unrelated TCP connections get reset when starting AdGuard service #2291
AdGuard needs to reset connections when it starts/restarts its service in order to properly filter them. What AdGuard doesn’t have to do is to reset connections that it is not going to filter anyway. So from now on, it won’t do it, as simple as that.
[Fixed] Avast Free prevents AdGuard from suppressing QUIC #2310
The current way of whitelisting apps from filtering for WFP driver has been extended to TDI driver. It allows to avoid compatibility issues with other software, especially with antivirus software.
[Improved] TLS version has been upgraded #2337
Up to this moment we were using a draft of TLS 1.3 technology ([#2155](https://github.com/AdguardTeam/AdguardForWindows/issues/2155)), as we always want to be at the cutting edge. Now, as TLS 1.3 standard was officially accepted by IETF, we are happy to say that AdGuard supports the most modern encrypting standards.
[Improved] Popup Blocker has been updated to v2.5 #2295
Popup Blocker is an extension (userscript) that is added to AdGuard by default. As it’s clear from its name, it helps block various popup windows (most of which are all kinds of ads). It’s been around forever, but the new version for the first time features its own UI accessable from “Extensions” settings tab. You can whitelist websites there or disable notifications for certain websites. The blocking capabilities have been improved too, of course.
[Changed] TLS 1.2 is used by default if Avast is detected #2368
As we’ve said earlier, TLS 1.3 is the current standard, but some antiviruses still use v1.2, notably Avast. We would like to completely switch to v1.3 but have to take this into consideration.
[Fixed] Application update resets Assistant settings and restores deleted extensions #2365
There won’t be enough fingers combined on hands of all people in our office to count the number of times users complained about this issue. One of our current priorities is to make the process of updating AdGuard as smooth as possible, and certainly preserving users’ settings is a big step in that direction.
importantmodifier by default #2305
AdguardSvcprocess memory leak #2114
While we are still polishing CoreLibs and are not ready to implement it just yet, we can sweeten the waiting with this new release. New "Nightly" update channel, added TLS1.3 support, improved performance and many more other changes.
[Added] Nightly update channel
The concept of a “Nightly” build is very simple. It literally means “a build that is released at the end of every day”, hence “nightly”. In reality, it may not happen every single day, but rather every 3 or 4 days, but the idea is there. All the latest changes made by developers will be included in the nightly build (yes, including possible bugs — be prepared!). If you feel that beta is not enough for you, and you need to be a step ahead of the rest, this is the choice for you. Just go to AdGuard settings and switch to Nightly update channel.
[Added] TLS1.3 Support (draft 28) #2155
TLS 1.3 is a new version of the cryptographic protocol used to encrypt messages sent via HTTP. It is faster, more secure and overall better than its predecessors. It has not been accepted by IETF as a standard yet, but it is only a matter of time. The process has already started, and we want to be at the forefront, and thus we have already added the TLS 1.3 (draft 28) support. As not everyone supports TLS1.3 yet, there can be problems on some websites potentially, so we added a new advanced setting to switch between TLS versions at will.
[Added] Option to subscribe to a filter by clicking a special link on a webpage #1945
Many filter developers put a special subscription link on their filters' homepage. Now AdGuard is able to detect these links when you click on them and will ask you if you'd like to subscribe to that filter right away. A minor thing, but it will save you just enough of extra clicks to be worthy.
[Added] A notice to inform about closed connections to websites with EV certificate #2015
Some websites have so-called EV (extended validation) certificates — basically, this means that the owner went through a very long and thorough process of validating their identity. In other words, these websites are generally the safest on the web. Filtering these websites is often extensive, as they rarely have ads anyway, but can sometimes lead to conflicts. AdGuard provides an option to disable filtering for such websites, and if it is enabled, a notification will inform you when you visit them for the first time. Clicking on the notification will allow to force filtering on the website anyway.
[Added] Stealth mode options applied to requests added to Filtering log #247
This is something a lot of aspiring filtering rules creators asked for. Knowing which Stealth Mode options affected this or that request is often crucial when working on a new rule. Now you can find it right in the Filtering log when you select a request. For sure, this sounds a little bit nerdy for an average user, but we try to take into account needs of all our users, casual and advanced alike.
[Changed] Default builder has been drastically reworked #1965
Basically, this is the change that caused the build size reduction that was advertised in the introduction. As the app accretes new features over the years and the code mounts up, this becomes more and more relevant. Thanks to this change, now we can add even more!
[Improved] Better support for visually impaired users #2068
AdGuard tries to provide the best online experience for all users alike, and visually impaired users are no exception. Starting with this version, AdGuard menus are much better suited to be read by NVDA Screen Reader and other screen reading programs.
[Improved] Filters update procedure's performance #2211
If you had the misfortune of a habit to update your filters often, you certainly noticed that it took quite a lot of time, as well as installing new filters. We addressed this problem, the situation should change drastically for the better now.
Over the last weeks, we've received several reports about bugs that slithered in the latest release. They turned out to be both moderately important and relatively easy to fix, so we decided to release a new update off-schedule.
[Fixed] "Reinstall certificate" feature does not work in Firefox #2013
While not being the most important feature, the automatic certificate reinstall is more relevant for Firefox-based browsers than for any other ones. This fix eliminates the need to do it manually.
Hello! The changelog this time is truly gigantic. Every time we thought we were going to release the current version, there was always something we felt was essential to fix, add or improve. How did it turn out?
Let's start with UI changes. Both Filtering log and Filter editor have been seriously redesigned. We need to say a big 'thank you' to everyone who has expressed his or her opinion because few changes depend as heavily on users' feedback as these.
[Changed] Filtering log rework #96
We know for certain that quite a few of our users are actively using Filtering log — both for creating new custom rules and generally knowing what's going on. So why not help them a bit? It has undergone a major renovation. New Filtering log overlaps with Filter editor a great bit, for example, you can create new rules and unblock blocked requests right therefrom.
There are more details to see about each request, too. The request details dialog window is very reminiscent of the Developer tools in Chrome browser. All in all, the new Filtering log is much more than a simple list of which requests are blocked and which are not.
[Changed] Filter editor rework #1293
Filter editor has also changed for the best. The addition of an 'Edit mode' allows replacing the data grid with a text area. This lets you copy/paste/delete many rules at once without having to bother with export/import.
Basic hotkeys are now available, which will speed up the process of working with the filter editor. There are many other quality of life changes, especially to the UI, which will draw your attention as soon as you launch the new version.
[Added] Integration with Windows 10 notifications center #1554
Many Windows 10 users find the Notification center to be helpful when it comes to tracking the activity of their apps. We have finally decided to take advantage of it and integrated AdGuard with the center. AdGuard has a surprisingly decent amount of various notifications. Just to name a few: notifications related to the license/trial period, automatic filter activations, new rules in User filter, Safebrowsing triggers, update checks results, etc. If you use Windows 10, you'll be able to find them all in one place now, thus making it much easier to keep up with what's going on with AdGuard.
[Changed] Network settings moved to a separate settings tab #1404
This one is rather straightforward. Previously, all network settings were crowding inside the 'General settings' tab making it harder to scroll up in down, searching for the one setting you need. Adding a separate first-level tab makes it easier to navigate through the app.
While not being an integral part of AdGuard for Windows, some extensions (or *userscripts*) have grown over time to become strongly associated with it. And we showed them some love!
A lot has been done in terms of improving AdGuard Assistant, and a lot more is planned for the future, so we decided to allocate it a separate, own GitHub repository: https://github.com/AdguardTeam/AdguardAssistant/
By the way, you may notice that the 'Report website' button now leads to a whole new page. Basically, what you see is a web reporting tool that allows you to easily send us a report on anything from a missed ad to a false positive. More about this later.
What else is done already? The biggest change is the ability to drag the Assistant icon across the page and place it wherever you see fit. Moreover, AdGuard will memorize the position of the Assistant icon for each website separately, so you can really customize it according to your taste and preferences.
The Assistant interface overall has become smaller but retained full functionality compared to earlier versions. There is even one new feature: a switch for toggling the filtering on the website on and off. Previously, the Assistant wasn't shown on websites with disabled filtering, and you had to go to User filter to enable it back.
Oh, and we could use your help with translating the new Assistant. Did you know that anyone can volunteer as a translator? If you feel confident, head right here and find your native language. Don't forget to read through the translator's memo.
[Added] AdGuard PopupBlocker extension v2.1 #1883
For quite a while now, AdGuard works as a userscript manager — you can install any script via AdGuard to use it in any browser. PopupBlocker has always been one of the 'native' userscripts that are installed by default, alongside AdGuard Assistant. Its purpose is clear — to block any unwanted pop-ups.
Previous version (v1.0) was functional but very little beyond that. We have completely redesigned the PopupBlocker. It now has advanced pop-up detection, compared to its predecessor and its alternatives, restores the initial click behavior and is invisible to other scripts. All in all, new PopupBlocker is a solid addition to your online protection suite.
By the way, it is available as a standalone script that can be used on its own with any other userscript manager. To find more information about PopupBlocker, visit its GitHub repository.
[Added] Integration with Reports Web App #1964
When it comes to keeping our filter lists updated, we owe our users a big one. Thanks to their timely reports of missed ads, false positives etc., AdGuard filters are always up-to-date. We want to make the process of reporting a website easy for users and informative for filter developers, that’s why we decided to integrate AdGuard for Windows with a special web reporting tool.
When you see any problem like missed ad or annoyance, click on the Assistant icon and choose “Report this website”. You will be taken to a new page and asked to fill in some information about your AdGuard settings and the nature of the problem. Good thing is that AdGuard pre-fills most of the fields automatically, so most of the job is already done for you :)
We hope this change will strengthen the feedback from our users and allow AdGuard filters to stay at the cutting edge of ad blocking technology.
[Changed] The way AdGuard handles userscripts #1714
A lot of effort has been put into improving (better to say, rethinking) the way AdGuard works with userscripts. This actually has two different aspects:
First, from now on, the communication between AdGuard and Assistant is based on WebSocket, which results in better performance. This is also perfectly applicable to AdGuard Browser extension, when it is working in the integration mode with AdGuard for Windows.
Second, we have taken a whole complex of measures that allow for any external userscripts that you install via AdGuard to show higher speed and execution stability.
[Added] Settings export/import #1405
A lot of users were asking for this, and finally we deliver. Now you can save your settings configuration into a file and then use it to set up AdGuard on another machine exactly how you prefer. Another implication of this is to quickly switch between different settings profiles without having to feverishly click through a dozen of tabs and checkboxes.
[Improved] A complete "Exit AdGuard" functionality was added #1509
Now users have a choice between closing AdGuard as they usually do, and closing it completely. That means closing the Windows service as well as UI, and when UI is getting started again, the service will start as well (you may be asked for the admin privileges, though).
[Added] An option to create custom filters not backed with a file #1669
In addition to the usual option of adding any list by URL or loading it from a local file, you can now create independent new filters from scratch. It is possible to create several such filters, give each of them their own name and fill with any rules. As a result, you can create a set of specified filters which can be separately enabled, disabled and edited.
This update might not be the biggest one, in a sense it doesn't feature any revolutionary additions or the immense number of changes. But it's surely a unique one, and it's because it is by far the most influenced by the user feedback. We sincerely thank everyone who has helped us!
It is super important for two big reasons, both concern networking/compatibility: we have *finally* fixed the compatibility issue with KIS/ESET and, also, we've fixed a certificate issue in modern Chrome versions (59+). Details below.
[Fixed] Compatibility with KIS/ESET #1565
Adguard used to have compatibility issues with such antivirus software like Kaspersky and ESET. Users had to seek for compromises: disabling SSL scanning in antivirus, disabling WFP driver or even HTTPS filtering in Adguard. The core of the problem was the WFP network driver incompatibility, and we had had plans to develop a new driver for what now seems like an eternity.
We'd already claimed to have this fixed in the previous releases, but things turned out to be more complicated. We've come through countless iterations, test builds, and driver updates, and now we are confident enough to say that this time the problem is fixed for real. No more BSODs and other funny stuff when you run Adguard alongside with KIS or ESET.
And again, we can't thank enough everyone who was willing to cope with raw test builds and provided invaluable feedback in order to help us make things right. Just look at the task - it is blowing up with comments. We are happy to have such users, you are awesome.
[Fixed] Compatibility with Chrome 59+ #1597
With big news which WFP driver compatibility fix is it could be easy to neglect other changes. And that would be so wrong! This fix, in particular, is of utmost importance. It ensures Adguard will run without problems on modern (v59+) Chrome versions. Otherwise, there would be troubles with Adguard certificate validation.
UPD: hotfix update 6.1.314 brings a fix for the bug #1569, messing with filtering when HTTPS filtering is disabled.
It was quite a while since the last Adguard for Windows release. And there are other reasons for that apart from the Christmas/New Year holidays: we'd been extensively testing the new network driver before, finally, we felt ready to include it in the new release version. But what is there for me in this network driver, you might ask? Well, it fixes an old compatibility issue with several antivirus programs. For sure, there are other fixes and changes as well, and you will find the whole list below.
You can also find all relevant information about this release (and discuss it) in our blog.
[Improved] WFP driver was updated to fix compatibility issues with KIS and ESET #1497
Previously, it was not unusual at all that Adguard would have compatibility issues with some antiviruses, and KIS and ESET being the most common ones. The workarounds existed but were far from ideal - you had had to sacrifice some parts of functionality on either Adguard or antivirus side. With updated WFP driver these conflicts will be no more, allowing users to run Adguard alongside with KIS and ESET.
[Improved] The way we respond to HTTP protocol violation #1452
It would take too long to explain technical nuances, but effectively this fixes the problem some users might have come across before: when you try to open a page and it is downloaded as a file instead.
This version should be considered as a revision of the Adguard for Windows 6.1 release. This is why you will not spot many 'major' changes - mostly bugfixes, small changes, improvements etc. More drastic changes will come eventually with 6.2 version.
[Added] $important modifier #1312
This new addition is an important one (no pun intended), but mostly relevant for creators of custom filter rules. With it's help you can give certain rules higher priority.
[Changed] WOT extension is now disabled by default #1364
Recently, an article was posted in one of the popular technology blogs, claiming that Web of Trust is selling its users' browser history to third-parties. WoT extension is preinstalled in Adguard for Windows, and although it was developed by us and is not sending any of your data to WoT, we can not leave this without a reponse. For this reason we make WoT extension disabled by default in Adguard for Windows. You can read our official stance regarding these news in our blog.
Many other minor fixes and changes. The full list can be found in descriptions to prior beta versions in our repository on GitHub.
Briefly about new Adguard for Windows version: Stealth Mode got new useful options, userscripts work better now, ad blocking became more advanced and our network drivers - more stable. All the details are below.
[Added] "Self destructing cookies" option in Stealth Mode #678
Previously Stealth Mode module provided only the option to completely block third-party cookies. Now you will not only have an ability to differ first- and third-party cookies, but also the ability to set the exact time which cookies will be kept alive for. Important note: you can still block cookies alltogether, just set the keep-alive time to '0'.
[Added] Added an option to block "Browser location API" #139
[Added] Added an option to block "Browser notifications API" #1121
Normally browsers may detect your location and use this information to prioritize specific search results or make other various suggestions based on it. With browser location API blocked this will be impossible.
Blocking browser notifications API feature works somewhat similar, but rather prevents browser from showing things like news or social media frames that pop-up in the corner of your browser.
[Improved] Content injection algorithm #1099
We completely redesigned content injection algorithm. First and foremost, this should solve issues with scripts that start when the page opens, resolve some of the known conflicts (AdsBypasser, YouTube+), and also optimize usage of scripts and ad blocker styles. Overall, a technical, but very important change.
[Added] Userscripts handling #1172
We adopted a new way of handling user.js (userscript) files. Now Adguard will automatically detect when user.js file was processed. If it is a valid userscript, Adguard will open a dialog window, offering user to install it. Of course, this setting will be optional and possible to turn off through settings.
We continue to make Adguard more easily accessible for users all over the world. This time we add two more new localizations and fix some mistakes in already existing ones.
[Improved] Network SDK was updated #1179
In reality, this implies many various fixes that concern our network drivers. It would be hard to list them all here, and most of them are rather technical anyway. For example, the WFP driver - Windows Defender compatibility issue was addressed.
[Added] Support for extended selectors #1225
This is a technical term, but what hides behind it? With extended selectors support, we can much more easily create some rules that were very, very hard to create earlier. Notably, this concerns rules required to block such things as 'Sponsored posts' on Facebook.
[Added] Extended CSS support https://github.com/AdguardTeam/ExtendedCss
This is a very important addition in terms of future (and present) possibilities that it opens for ad blocking. Extended CSS is a module for applying CSS styles with extended selection properties. Basically, it means that we will be able to select and, therefore, block some elements that we would not be able to block otherwise. Currently we support following pseudo-classes: -ext-has (:has), -ext-contains (:contains), [-ext-matches-css (:matches-css).
Dozens of minor fixes and improvements.
A hotfix after last weeks release. Previously there turned out to be several problems, including router page loading problem and other. These bugs are fixed with this version.
Good news, everyone! We haven't seen any new bugs since the latest beta version, and it means nothing else but the new stable release is arriving. During the last couple of months that had passed since the 6.0 release we were able to track quite a lot of bugs and defects, which were crucial to fix. So we concentrated on them for a while. Finally, everything seems to be fixed and we are ready to turn on the autoupdate for all our users who still use Adgguard 5.10. We were looking forward to this moment! Even if you were already using Adguard 6 and you are not as excited by these news, you should be. This release means we can finally put all our efforts into implementing cool new features you might have or have not seen in our [roadmap]. In case you missed last beta releases and respective release notes, you can catch up and read about all the fixes and additions below. Most important of them, as usual, are described in detail.
Languages and Translations