Future of using easylist as default

[max06]

In the last days we had serious trouble caused by the easylists maintainers by adding generic url parts without domain limitation, affecting many more projects than intended.

Feedback got ignored, requests to revert the changes rejected. I'm questioning if a small group of people not showing responsibility should be able to destroy parts of the internet, as well as destroying the reputation of innocent companies and projects.

Please read easylist/easylist#4067 for details and think about not enabling those lists per default.

[gorhill]

I've neutralized the filters for uBO users: uBlockOrigin/uAssets@e8017aa.

[max06]

Thank you very much for that quick reaction!

I would still think abut keeping the easylists as default in your tool.

[uBlock-user]

They removed those filters after all -- easylist/easylist@0b2ea95

[max06]

Yes, for now. I'm pretty sure they'll wait some days and try it again then.

[gorhill]

I want to keep it opened. I went through the discussion thread and I do see an issue.

A filter such as /v1/events is obviously way too generic, this should never have been added in the first place, this hightlight there is really an issue. It's difficult to tell exactly why it was added as a generic filter rather than just for the site which was apparently targeted -- ozon.ru (where btw I couldn't see requests matching /events on that site).

Such generic filters is likely to cause widespread breakage -- we even had to badfilter generic filters with more targeted keywords because they were causing breakage.

In the big picture, breakage will cause users to disable their blocker, which is a worst outcome than allowing one specific tracking script on one specific web site -- which can be addressed with a well targeted filter.

The list at issue here is EasyPrivacy, not EasyList. A potential replacement is AdGuard Tracking Protection, so we should evaluate whether it can be a replacement if it lowers the likelihood of breakage for uBO users while providing the same level of tracking protection (we already enable Peter Lowe's in uBO).

[wachri]

They removed those filters after all -- easylist/easylist@0b2ea95

This thread is being watched by them (as the event logging urls have been changing). Not assuming everyone is in the event logging/tracking business. but most them will be aware of this thread.

I've removed the filters for the time being, 0b2ea95 It'll be reviewed again later.

easylist/easylist#4067 (comment)

[max06]

@gorhill You're absolutely right. Just want to point out that easylist, easyPrivacy and some more are all managed by the same people. And judging by their reaction something like that will probably happen again in any of those.

Edit: To be more clear: I'm not worried about accidential overblocking, but I care about being open minded to changes instead of sticking to own ideas.

[ryanbr]

Some companies have a heavy interest in any filters we add, When issues arise having valid examples of breakages and not just companies just trying to circumvent the list by issuing fake faults. "Feedback got ignored," when you have a thread from many people, you can't address every user comment or question.

I adjusted the filters twice (based on the sample urls given) before removing the filter. If someone believes we added a filter by accidentally or the filters were overreaching, then having a valid example of these page(s) is broken. But the thread lacked a lot of real world examples, and the examples we did have were already fixed.

This is why we have Issue report templates.

[gorhill]

the thread lacked a lot of real world examples

I am going to argue that for generic filters, the burden of proof is reversed and first on filter list maintainers: your generic filters also lacked a lot of real world examples.

There should have been a at least a sufficient commit history to make the case that /v1/events was worth converting into a generic, but there was none, it went from no filter to one very generic filter with questionable keywords and with one single case made (in the commit title).

Generic filters need a commit history similar to /v1/events$domain=[...] where the list of domains keep growing over time, and where eventually the list become large enough to the point it makes sense to entertain whether the specific filter should be converted into a generic one -- and even then depending on the keywords involved it still could be hard to make the case for genericity.

[ryanbr]

Understood. Though any generic filter we add to EL/EP will always have some level possible problematic issues. Some sites would act perfectly fine, where other sites would have issues. Its supplying us the website and example of why its broken so we can then reproduce it. Depending on the breakage, the example given, and/or a recent recent added filter we'll either remove the filter or whitelist the affected site.

In the case of /v1/events filters, we didn't really have many (or any real world testable examples) that weren't already fixed with list updates to the filters. (adding | end of string and specific filter strings).

I probably should've acted sooner, but I wanted to see the breakage (reproduce the fault) in action before making the call, like any other issue report from any other user.

My intention was not to break people web sites, and for that I apologise.

[kulfoon]

As for: #738 (comment), agree, and there is another example of such similiar issue with generic filters in EasyList: easylist/easylistgermany#70 - creating generic filters for single websites, even though there is no breakage side-effect, but there is a performance side-effect which for example collides with gorhill's efficiency based aproach. I'm very curious what do you think about (easylist/easylistgermany#70).

[jspenguin2017]

@kulfoon I don't think that's a problem. The rules look safe and tokenizable. As for the specific issue, I'll open a new issue in Quick Reports.

Update: NanoMeow/QuickReports#3666

[gorhill]

there is a performance side-effect which for example collides with gorhill's efficiency based aproach.

I don't see a performance issue with any of the filters added. Adding one single generic cosmetic filter on top of the thousands already being enforced makes no difference performance-wise. The DOM surveyor code has to execute with or without that added generic cosmetic filter, so performance should not be invoked to argue against it.

[kulfoon]

gorhill: I don't see a performance issue

So how you at the same time do see a performance issue here ( as I already mentioned in easylist/easylistgermany#70 (comment) ):

From uBO:

Generic cosmetic filters are those cosmetic filters which are meant to apply on all web sites.

Though handled efficiently by uBlock₀, generic cosmetic filters may still contribute measurable memory and CPU overhead on some web pages, especially for large and long-lived ones.

Enabling this option will eliminate the memory and CPU overhead added to web pages as a result of handling generic cosmetic filters, and also lower the memory footprint of uBlock₀ itself.

It is recommended to enable this option on less powerful devices.

How can one see and not see a performance issue at the same time? Perhaps remove the tiptool then? Wtf? Why denying yourself, a hypocrisy or what.

gorhill: Adding one single generic cosmetic filter on top of the thousands already being enforced makes no difference performance-wise.

The one generic filter is just an example, it's obvious that there might be already hundreds or thousands of them ( as I already mentioned in: easylist/easylistgermany#70 (comment) ).

Also keep in mind we're talking about genericfilters which cover just a single website, an example (from easylist/easylistgermany#70 (comment)): easylist/easylist@e146cf3 https://publicwww.com/websites/Ad_SmartBrokerBar/ I have nothing against generic filters which cover multiple websites.

============================================================

Another example of a person who is denying himself is Khirin, as I wrote in my comment: easylist/easylistgermany#70 (comment):

kulfoon: A mystery for me is Khirin accepting my point of view (to not fix potential non-existing cases, see: easylist/easylist#5220 (comment)), and now he suddenly start denying himself by upvoting his friend's solution: see easylist/easylistgermany#70 (comment) which, the solution, does fix potential non-exisiting cases/pages.

Is he just supporting his repo's friend, no matter whether his friend is right or not...or what is it, wtf? Another one who is denying himself, a hypocrisy or what, he didn't even reply, is he outargumented or what.

============================================================

Not mentioning uBlock-user, who was hidding comments in one thread: #971, but not in another: #984. Again a hypocrisy or what.

============================================================

Guys just stop denying yourself all the fukin time.

See this cool movie, see those fukin morons downvoting, one must be an idiot to downvote it.

This is all bullshit, fck it, I'm out, let's everbody dance now =)

[gorhill]

@kulfoon, one generic cosmetic filter or 10,000 generic cosmetic filters is essentially equivalent, both cases require that the DOM surveyor execute. Only zero generic cosmetic filters prevent the DOM surveyor from executing.

All I see is you wanting to argue for the sake of arguing.