Actually, AdGuard Home checks for updates periodically (unless it’s docker or snap) and can update itself right from the admin panel.
2,363 karma · joined October 15, 2017
Oh and one more thing: there's an option to "share" video from the YT app or YT webpage to AdGuard. This is probably the only possible way to get rid of ads when you're using the YouTube app.
Here's a short update on what happened since then:
1. DMCA takedowns did not destroy ad blocking (thank god), but there were a couple more times when it was tried, nothing huge though.
2. Streisand effect is a thing and the domain in question was blocked by everyone and everywhere. There was even a special filter list and later a browser extension which only purpose was to block such domains. It got some traction but later got abandoned: https://github.com/paulgb/BarbBlock. If something like that happens again I am pretty sure it can be revived very quickly.
3. The corporations still try different angles to prohibit ad blocking. The last example I know about is something like this: Axel Springer claimed that the web page and all its content (including subrequest) and ads is subject to copyright law. So when you modify the web page with adding new styles or blocking a web request you violate the copyright.
Mostly this boils down to one thing: there needs to be an alternative to service workers and there are tons of legitimate use cases for long-living background pages or workers. I think by this point everyone agrees on that, the question is when this alternative will be made available to developers. It’s only 3 months until the deadline after all.
You see, now extensions are supposed to do background work in an ephemeral service worker. This service worker lifetime is very short (up to 5 minutes, then it's getting killed forcibly). So it's constantly getting killed and waked back up. Waking up includes doing some initialization which consumes additional cpu cycles.
The situation will improve when Google implements the alternative to service worker (so-called "Offscreen documents"), but no one knows when exactly this will happen.
Also, I am not entirely sure other Chromium-based browsers will be able to maintain MV2 compatibility in the long run.
This is so true. It is often overlooked, but the root problem of Manifest V3 is not declarativeNetRequest, but this service worker move.
Firefox and Safari implemented an alternative to them so there's a chance.
Google proposed a different solution (called "Offscreen documents") which is also not too bad, but I doubt they'll implement it by the January deadline.
The only piece of reliable information is this: I once asked Google engineer whether they plan to support declarative cosmetic rules (that's what we do ourselves in MV3 and that's why the extension still requires wide permissions) and the answer was that they definitely do plan to do that in the future.
https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED&b...
> Without us chrome would likely not be in the position it is today and google could not dictate the terms like they do.
I kind of disagree with this. Google Chrome's current popularity stands on two things:
1. It is a great browser and it does its job very well.
2. Google in the first years was very active with its distribution. And this is not only about the link on their homepage. I remember how 10 years ago every piece of software you were trying to install was bringing Chrome alongside.
Engineers recommending Chrome to their friends and relatives shouldn't be discounted, but I tend to think that it's less important that the two other points above.
We'll now need to rely on Chrome team for implementing what we need. But they do it painfully slow or not do at all.
Also, where will we get the new ideas if every browser follows that path? Take Safari for example, every little improvement that we requested [1] was inspired by what we already did in other browsers long ago.
Anyways, a working content blocker on MV3 is possible. I even think a casual user won't feel much difference. But there is a big difference under the hood and to feel the consequences we have to wait a few years.
[1]: https://bugs.webkit.org/ (search for those reported by @adguard.com). Just a very small part of what we requested was implemented, content blocking is not a priority I guess, and it won't be a priority for Chrome.
Apple uses Cloudflare for their private relay so there’s a chance that these IPs won’t be blocked.
To be completely honest, Manifest V3 technically is not THAT bad and it's capabilities at the current moment are really close to what major ad blockers can do.
There're still some things that bother me:
1. Debugging a content blocker is really inconvenient (not as bad as Safari though) 2. The future. What if its development stalls after it's released? 3. Google's goal (probably, for Manifest V4) is to make content blocking completely declarative, i.e. get rid of any host permissions and content scripts.
First of all, shame on me for missing this, and thank you for pointing this out.
Unfortunately, this still does not solve the issue in question - we cannot figure out which rule was triggered. But it is definitely better than nothing, at least knowing what's blocked we can try creating something resembling a debugging tool.
> Thankfully, many unblock rules can be merged into the corresponding block rules in the form of "unless-domain" specifier.
Some of them can be handled this way, some of them cannot. Trying to handle all possible issues automatically right on the device is not at all as trivial as simply converting EasyList. And we need to do it that way (real-time, on device) because our goal is not to just convert a few lists, but also to provide maintainers with a tool they can use to develop their lists and test&fix them for Safari.
> Due to their design, content blocker extensions can guarantee privacy, unlike the ones that can run JS code.
Content blockers that can run JS code can guarantee privacy better by doing their work better than the others.
Anyways, let's not go further on this, we won't change each others view on this and we've already stated our positions.
My point was that we want to extend the declarative API, it has nothing to do with running JS.
There’s an important difference, these browsers can also run additional JS on web pages and partly compensate for missing content blocking capabilities. This could help to an extent, but I am not sure if the said browsers do that.
At least developers can do that. But most of the people who maintain filter lists are not developers and cannot afford enjoying compiling WebKit for the sake of finding what exact rule has blocked this or hidden that.
> There’s SFSafariExtensionHandler API which you can use with blockers as another extension with higher privileges to track who blocked what.
I am not sure what you mean here. This API (available only on macOS) does allow injecting scripts and stylesheets, it does not provide any feasible debugging tools. Granted, you may inject a script that will get some information about what's blocked, but it's far from what's required.
Just compare what Safari provides with AdGuard's filtering log on any other platform or with uBlock Origin's log. The lack of such tool is the main reason filters maintainers avoid dealing with Safari.
> Compiling speed, for the process that happens once the blocker rules json is changed, is irrelevant for the users
Compiling speed is the reason for the rules limitation.
> There's also some rules that don’t match 1 to 1, but it isn’t something that can’t be solved.
Unfortunately, there is something that cannot be solved, and YT is a great example of that something.
> The number of rules limit is a non-issue
I have to disagree here.
We're not dealing with EasyList alone, there're many other lists (regional lists for instance). You may say - okay, let's split them all to different content blockers. There's a serious problem with that, though. Different content blockers are completely independent. However, that's not how those lists are being developed - there're lists that are supposed to influence each other.
Let's take the simple example - unblocking something. For instance, here is the most obvious example that happens all the time. There may be a regional list that unblocks something blocked by EasyList (or EasyPrivacy) because this "something" breaks an important website in that region. Putting EasyList into one content blocker and the regional list into another breaks the regional list.
> And the most important thing. It seems that AdGuard guys don’t get why content blockers in Safari don’t run scripts. It’s privacy. But Safari itself doesn’t prevent you from doing that, only not as a part of content blocker extension that is privacy-safe.
We accept that argument despite me being literally sick of hearing it (so there's privacy on iOS, but no privacy on macOS since scripts are allowed to extensions there, okaay).
What's important is that we do not propose allowing running arbitrary scripts. We propose extending the declarative API in a controlled manner and it does not conflict with Safari vision.
Also, that's just one of the feature requests (and bug reports) reported over the years.
edit: typos