ameshkov

We don't use GH as a CDN, it's used solely for developing filter lists and issue reports.

The issue is resolved now, the repo is available again.

We have not received any response to the support case that we opened, but we assume that it was a false positive of some automatic algorithm.

As a consequence of this we're going to set up a mirror outside Github so that the work didn't stop if something like that happens again.

UPD: We received the official response explaining that this was a mistake. I must admit the whole situation was resolved really quickly, good job.

We opened an appeal on Github and are waiting for their response.

So far we have absolutely no idea what's wrong and what is the violation they're referring to.

I'll be surprised if this is a copyright issue as Github according to their policy should've given us a prior notice so that we could file a counter-notice.

I hope this is some sort of a false positive caused by Github trying to handle the spam issue [1] lately.

[1]: https://www.bleepingcomputer.com/news/security/github-commen...

Could you please explain what auto-reverse and multiple record types mean? The reason for asking is to learn what's missing from AG Home/DNS and maybe adding it in the future.

My point is that reporting must be accurate and factually correct.

The “safe rules” concept is a little strange indeed, not very consistent.

I actually agree that for an MV3 ad blocker I’d better have a fully declarative default (emphasis on default), but I’d like to provide an option to grant more permissions and allow more rules. I’ll wait until declarative cosmetic rules become a thing before going this way though.

What I don’t like about your way is that it’s very difficult to use the MV3 version for filters development, filter list authors will have to re-build the extension every time they make any change to the underlying filters.

Maybe this is not a big problem though, we’ll only see it when MV3 becomes the only option and there will be more issue reports from its users.

It isn’t “nothing else”, cosmetic rules can still be updated independently “over-the-air”. One more approach (a bit “hacky”) is to distribute cosmetic rules inside static rulesets (hide them in a separate “metadata” field).

I personally like the fast track idea as we can use the CWS infra to distribute updates quickly, but this is not the only way.

Differential updates are also possible and if they’re implemented, you can keep a normal release cycle (6 weeks for instance).

> Cosmetic meaning what exactly?

Filter lists are composed of two types of rules: “cosmetic” and “network”. Network rules define what needs to be done with web requests (block or redirect). In MV3 these rules should now be implemented via new declarative API.

Cosmetic rules is a very wide subset of ad blocking rules that define how a web page needs to be changed. These are implemented the old way.

> I don't see any issues with ublock in firefox, so what's going on there?

uBlock Origin does not use remote JS so yeah, what’s going on with the article is a good question.

The article’s claim is factually incorrect, self-update will also still be possible to implement even without the fast track. It will be more complicated than it is now as we’ll need to do that via differential updates, but nevertheless.

JS is important, but it’s only a part of what’s required. webRequest allows the extension to manipulate web requests: blocking or redirecting them. MV3 tries to replace the old webRequest with a declarative alternative and it’s almost impossible to provide a declarative rule for every possible use case.

The most problematic part of MV3 (removing part of the webRequest API functionality) is a part of the platform.

This remote JS stuff is a CWS policy.

Firefox kinda also does. In both cases side loading is rather painful experience, thanks to all the malware that is exploiting the extensions feature.

If the server is yours it will probably be rejected. Definitely will be rejected by Mozilla.

Userscripts is a notable exception of this rule as in this case the user instructs the extension what JS to execute.

I like that Ars tries to defend ad blocking, but please, prepare better, maybe talk to actual developers and avoid false accusations.

It’s completely okay to criticize Google for doing really controversial (to say the least) stuff like getting rid of blocking webRequest, but criticizing them for prohibiting inclusion of remote JS in the extension is simply bad work.

They could do a minimal fact check, remote JS was never allowed in Mozilla Addons store. A bit more research and they’ll learn that cosmetic filters updates do not require an extension update. A little bit more research and one can learn about the no-review-fast-track that Chrome WebStore plans to implement next year.

Here’s what I heard: they are okay with such a workaround for now because they realize how hard it is to adapt to the new model, but in the future they’d prefer to see extensions adapt and be able to quickly reinit.

> MV3 now brings "offscreen documents"

Yeah, at first I thought of using offscreen documents as a replacement, but it appears that:

1. They're not persistent too.

2. They have a different purpose, they're supposed to be used as a temporary crutch that gives access to DOM features for the time until it's brought to service workers.

> persistent service workers

You're right to write it in cursive, there're ways to prolong the lifetime of a service worker, but they're not persistent anyways. All in all, the only reliable way to live with service worker is to rewrite extensions in a way that allows them to very quickly initialize after the service worker is brought back to life. For some extensions it's easy, for some it's quite a complicated task.

edit: formatting

> Isn't this basically the same concept they already used with ordinary content scripts for years?

It was implicit, now it's explicit and it gives more control and better understanding. It also allows introducing more levels of isolation, like a separate "USER_SCRIPTS" world or "MAIN", before that you had to mess with evals and adding script tags.

> Yes, but those too are just an improvement compared to the previous state of MV3

Yes, that's why I listed these as improvements.

> And it again sounds like "we're now slightly less shitty to extension devs than we were before".

They went from "1 person that tries to make things not crumble" to a large team of developers, it's a big step forward. What signal do we send them if we always say "everything you're doing is bad" even when it's factually not true?

> Firefox shows that it's no technical problem at all to implement both APIs at the same time.

At first we all thought that DNR is there for them to limit content blockers. With time they proved us wrong when they worked hard on improving it and covering more and more use cases.

Now I tend to think that this is an engineering decision that's driven by the other change - the shift from persistent background pages to service workers.

Is there a better solution that could save the blocking webRequest and achieving their goals at the same time? Most likely there is, but how hard would it be to implement it instead or what if it requires an architectural change? Anyways, these are speculations, I am with you here and I don't support blocking webRequest removal.

MV3 is basically MV2 with one tectonic change: replacing persistent background pages with ephemeral service workers. So a large part of this effort actually DID go into MV2.

There's a better question: what if instead of investing huge amount of times into DNR they put it somewhere else? For instance, into providing better tools for extensions to persist their state so that we didn't have to rewrite the extensions from scratch to make them work with the new service workers model? I think it would've been much much much better. Unfortunately, that's how hindsight works.

It's natural for Google in their public communication to quote positive stuff and not quote anything critical. Recently I tried to explain the current state of MV3 objectively: https://adguard.com/en/blog/chrome-manifest-v3-where-we-stan...

But yes, my opinion about MV3 did improve with time. Briefly: it is not ideal, DNR is not a full replacement for the blocking webRequest, but their work for the last several years made me hope that they can compensate for what we're losing by other platform improvements.

edit: grammar

I would argue that new APIs are better thought through and cover the use cases that the extensions actually need.

Let me name a few examples.

1. chrome.scripting API and the concept of "isolated worlds" is easier to use and understand than what we had before.

2. Dynamic content scripts registration that everyone has waited for so long.

3. userScripts API is also a welcome addition. It does not provide everything and it needs to be improved, but it is already a good step forward. Finally the existence of userscript managers was recognized by Chrome and they're trying to make life easier for them.

Also, the bug fixes. Before the expansion of the extensions platform team there were major bugs that could be open for many years, and now I see them closing one by one. To an outside observer it may look ridiculous that there was such a problem from the start, but that's how underinvestment looks like and I am happy that the situation improves.

Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it.

edit: formatting

Good comment. I guess it’s a matter of hope :) I really want to believe that the extensions platform will continue to develop with at least the same pace, and eventually comes to Android. Maybe I am over optimistic though, we’ll see, but otherwise I just don’t understand what was all that about and what justifies such a significant investment in the extensions team.

For the most part I agree with your quote save for the “stuck in the past, unable to adapt” part, I’d replace with “lag behind”.

If the things continue to develop the way they are now, the new features will be eventually incorporated into DNR (in somewhat different form, but anyways). Basically, the “innovation” should be requested via the W3C group from the browsers and only then (after quite some time) it can be used as a part of DNR.

Is it worse than what we had before? Absolutely, adding anything to DNR is now a many-months process.

Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant.

I’d say that the situation changed from “MV3 is bad, DNR is unusable” to “MV3 is good, DNR is useable-but-limited”.

Sorry for jumping in but since AG is mentioned.

If you want to have all the data under you control, there's this: https://github.com/AdguardTeam/AdGuardHome

Regarding open source, AdGuard DNS actually is: https://github.com/AdguardTeam/AdGuardDNS

In the case of AdGuard DNS being open source does not change the fact that it is a centralized service and using such a service is a matter of trust.

Cool, we'll add a link to this to AGH readme: https://github.com/AdguardTeam/AdGuardHome/issues/5858

Fixed it, thanks

I wouldn’t say that these are exceptions or that they’re meaningless. EU and US antitrusts are just very slow, but we’ve already seen examples how antitrust authorities in other countries change the situation (see South Korea vs Apple, but there are more). These cases usually affect rules in a single country, but they contribute to the big ones (EU and US) too.

At this point I don’t believe that public discussion can change anything. Antitrust can, though, and in my opinion it would be better if the discussion was steered that way.

If my comment makes you think that I support this rule in any way, maybe I should’ve explicitly stated that I do not.

What I am saying is that the title is misleading as it tries to represent an old rule as if it is something new.

This is getting posted again and again and I don’t understand why.

There are no news here. Ad blockers were never allowed to Play store, here is the relevant policy: https://support.google.com/googleplay/android-developer/answ...

This is exactly why AdGuard ad blocker is not distributed via play store. It was removed in 2014, we learned the lesson and see no reason in trying to abuse Google’s non-existent review process.

Interestingly enough, at first Google used a different rule, some vague stuff about interfering with networks. Later they reworked the rule and added ad blocking to examples of common violations.

Anyways, at least Google allows sideloading so devs can live without Google Play. When Apple pulls something like that we have no choice.

AdGuard is not a russian company since long time ago. We moved the HQ in 2014, the core team including the owners are also on Cyprus, and finally half of AdGuard websites are even blocked by russian authorities. Anyways, I guess we’ll never get rid of this badge so ignore my rant:)