Email or username:

Password:

Forgot your password?
Top-level
mathew

@ljrk @catsalad @mozilla @torproject @eff "They're okay with not blocking everything (like YT)"

The problem with that theory is that AdGuard blocks YouTube ads. It also uses EasyList-syntax blocklists just like uBlock Origin does. In fact, uBlock Origin's wiki points to AdGuard's documentation as a source of information on writing blocking rules.

The only thing I've found that AdBlock don't want to block is paywalls (presumably because of the DMCA), so I just subscribe to a set of community-maintained paywall removal rules in standard format.

People should definitely switch from Chrome to Firefox, though. Google's sleazy attempt to sell user tracking in the browser as "ad privacy" is enough reason for that.

arstechnica.com/gadgets/2023/0

12 comments
folti

@sdueckert @mathew @ljrk @catsalad @mozilla @torproject @eff it's de facto managed by the Google Chrome team as the base of Chrome. So don't expect anything else from it than from Chrome. Some other browsers based on it pledged to either retain V2 support, or implement their own adblock features (Brave, Opera, Vivaldi), while others don't, like Microsoft Edge who already stopped supporting V2.

lj路rk

@FamilyCyclist @sdueckert @mathew @catsalad @mozilla @torproject @eff Yup, if nothing changes, the code will not only be disabled but removed from the code base and maintaining a fork that keeps it is unrealistic.

tbqf, the fundamental idea of MV3 isn't bad: Allowing for near arbitrary scripts to execute in the browser, fetched automatically from remote servers is basically a critical RCE vulnerability by design. The move to declarative filters and reimplementing the filtering code itself in native code is a good move and even speeds up filtering! It's something we, usually, should cheer!

Unfortunately Google decided to have a rather restricted set of API filtering features available that don't aren't sufficient to reimplement uBO in this declarative way, and also put arbitrary restrictions on foreign filtering rules. It's a gift, but a poisoned one.

@FamilyCyclist @sdueckert @mathew @catsalad @mozilla @torproject @eff Yup, if nothing changes, the code will not only be disabled but removed from the code base and maintaining a fork that keeps it is unrealistic.

tbqf, the fundamental idea of MV3 isn't bad: Allowing for near arbitrary scripts to execute in the browser, fetched automatically from remote servers is basically a critical RCE vulnerability by design. The move to declarative filters and reimplementing the filtering code itself in native...

mkind

@ljrk @FamilyCyclist @sdueckert @mathew @catsalad @mozilla @torproject @eff Execute code from a remote source is the whole idea of the web. That's the design idea. The CSP allows mitigating arbitrary exec though.

lj路rk

@mkind @FamilyCyclist @sdueckert @mathew @catsalad @mozilla @torproject @eff Well, it's the idea of the web since Javascript -- at least depending on your definition of "executing code". But I'd argue viewing an HTML file is not executing remote code but local code that's interpreting a declarative(!) file, just like viewing a PNG; I wouldn't call either executing remote code.

That being said, running code from a website is still less of a problem than an extension, since the website's code (barring exploits) can only exfiltrate data I give/enter the website the data anyway. The extension can, in theory, exfiltrate data from any website.

@mkind @FamilyCyclist @sdueckert @mathew @catsalad @mozilla @torproject @eff Well, it's the idea of the web since Javascript -- at least depending on your definition of "executing code". But I'd argue viewing an HTML file is not executing remote code but local code that's interpreting a declarative(!) file, just like viewing a PNG; I wouldn't call either executing remote code.

lj路rk

@mathew @catsalad @mozilla @torproject @eff Yes, they currently do block it but they don't have much of an incentive to do so and it takes a lot of resources to keep that up to date. Right now they *have to* try blocking it to keep up with the competition.

If, with MV3, the lists have to be bundled and ack'ed by Google, there's great likelihood that this will die first. Either because the filter won't be ack'ed or because YT just updates their stuff too frequently.

Suddenly, not blocking YT becomes the norm and is considered "good enough". Much more of a comfortable position for AdGuard.

And yes, since the people around AdGuard invented the filter syntax *back then*, that's still the point of truth for the syntax. However, due to this standard, people using uBlock can also import AdGuard lists etc. With user filter import gone this feature goes away as well...

@mathew @catsalad @mozilla @torproject @eff Yes, they currently do block it but they don't have much of an incentive to do so and it takes a lot of resources to keep that up to date. Right now they *have to* try blocking it to keep up with the competition.

If, with MV3, the lists have to be bundled and ack'ed by Google, there's great likelihood that this will die first. Either because the filter won't be ack'ed or because YT just updates their stuff too frequently.

183231bcb

@mathew@universeodon.com @ljrk@todon.eu @catsalad@infosec.exchange @mozilla@mozilla.social @torproject@mastodon.social @eff@mastodon.social Mozilla is also attempting to sell spyware as "privacy-preserving," and they partnered with Facebook to do it. Mozilla wants you to totally trust that Facebook has your back on privacy:
https://blog.mozilla.org/en/mozilla/privacy-preserving-attribution-for-advertising/

There are no good browsers left.

ploum

@mathew : I鈥檓 interested by the paywall blocking list if you care to share it. Thanks!

Andreas K

@mathew @ljrk @catsalad @mozilla @torproject @eff
Not really DMCA, but they have been in a constant legal battle with big German publishers about the legality of adblocking at all. While they have won in court, I'd guess they wouldn't want to provide them arguments.

Go Up