Opened 20 months ago

Closed 19 months ago

Last modified 17 months ago

#5910 closed change (worksforme)

[webextension] Provide a way to add multiple filter subscriptions on Firefox Mobile

Reported by: kiboke Assignee:
Priority: Unknown Milestone:
Module: User-Interface Keywords: options-page
Cc: jeen, greiner, athornburgh, kzar, mapx, fanboy, arthur Blocked By:
Blocking: Platform: Firefox Mobile
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kzar)

Background

In mobile firefox it's only possible to have one filterlist, one is not enough.

What to change

Please add a way to pick our filter lists to subscribe to on Firefox Mobile. It should refresh when filter lists are updated.

Change History (10)

comment:1 Changed 19 months ago by kzar

  • Cc jeen greiner athornburgh kzar trev mapx added
  • Component changed from Unknown to User-Interface
  • Description modified (diff)
  • Keywords options added
  • Summary changed from A configurator for multiple filterlists to [webextension] Provide a way to add multiple filter subscriptions on Firefox Mobile

Seems like a reasonable suggestion, but perhaps this is not possible for performance reasons. Any thoughts?

comment:2 Changed 19 months ago by kzar

  • Keywords options-page added; options removed

comment:3 Changed 19 months ago by greiner

  • Resolution set to worksforme
  • Status changed from new to closed

This issue has been resolved with the release of the new mobile options page which allows you to add multiple filter lists. Therefore I'm closing this ticket.

comment:4 follow-up: Changed 19 months ago by mapx

What about the performance when managing a lot of other filters ? cpu / memory ?

If it's about performance probably - before the car body - should be re-projected the engine (from PC to the mobile).
For example uBo is using multiple lists from beginning. I remember years ago somebody proposed you to adopt the core-engine of uBo in ABP. See #488. It was rejected.
I see some intensive activity on the C++ lib adblockplus front..is it only rewriting js to obtain some speed improving (some code optimizing) or it's about a new approach / algorithms to better manage memory / cpu ?

comment:5 in reply to: ↑ 4 ; follow-up: Changed 17 months ago by greiner

Replying to mapx:

What about the performance when managing a lot of other filters ? cpu / memory ?

This is always an issue, not just on mobile but also on desktop. Therefore it'd be more beneficial to find solutions to reduce the size of filter lists, informing/warning the user about the impact on performance/memory as well as work to make filter management more efficient in general.

The other points are probably best discussed elsewhere but I'll quickly respond to them here:

For example uBo is using multiple lists from beginning. I remember years ago somebody proposed you to adopt the core-engine of uBo in ABP. See #488. It was rejected.

There is no proof that I'm aware of that replacing the core ad blocking code with uBlock Origin's would improve the performance and/or memory usage of Adblock Plus. None was provided in #488 either which is why it got rejected back then.

However, I'd be happy to participate in discussions about improvements to or replacements of the core code to find workable solutions for the inherent memory issue that ad blockers generally have.

I see some intensive activity on the C++ lib adblockplus front..is it only rewriting js to obtain some speed improving (some code optimizing) or it's about a new approach / algorithms to better manage memory / cpu ?

I'm not directly involved in those efforts but rewriting some JavaScript code in C++ to achieve more efficient usage of memory is part of that.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 17 months ago by mapx

Replying to greiner:

There is no proof that I'm aware of that replacing the core ad blocking code with uBlock Origin's would improve the performance and/or memory usage of Adblock Plus. None was provided in #488 either which is why it got rejected back then.

Well, it's a fact for all the users who tested uBo too. It's a huge fact. Probably you weren't curious to test it.

The memory is quickly to check: just open task manager in chrome for example. More: uBo has by default a lot of lists enabled (not only easylist / regional list but also easyprivacy, peter lowe's, ublock specific filters, malware domains). Even with all these extra lists ..uBo occupy less memory (RAM) and (!) it's faster than ABP (and less CPU-intensive). Again: I tested all these facts by real daily use (months).

Another important thing: you (eyeo) wrote nice articles (see https://adblockplus.org/blog/how-cryptojackers-maliciously-worm-their-way-into-ads-to-turn-your-computer-into-their-mining-zombie ) about crypto-crap but did nothing to protect your users.

Enable by default easyprivacy in all installations (only easyprivacy contains a special section to fight against the miners / crypto-crap) !

Last edited 17 months ago by mapx (previous) (diff)

comment:7 in reply to: ↑ 6 Changed 17 months ago by greiner

Replying to mapx:

Well, it's a fact for all the users who tested uBo too. It's a huge fact. Probably you weren't curious to test it.

I'm not claiming whether or not one is better than the other and I trust your experiences. What I'm saying is that since those are two completely different code bases, it is difficult to say whether integrating uBlock Origin's code into Adblock Plus would yield the same benefits as it does there since various changes would be required to get it to work in the first place.

Since nobody has ever attempted to swap out the core engine of Adblock Plus, there's simply no reference data to refer to, to evaluate that. I'd welcome such attempts on either side of the isle so that ad blockers can learn from each other and work together.

Another important thing: you (eyeo) wrote nice articles (see https://adblockplus.org/blog/how-cryptojackers-maliciously-worm-their-way-into-ads-to-turn-your-computer-into-their-mining-zombie ) about crypto-crap but did nothing to protect your users.

I hate such crypto scripts probably more than most other people. That being said, we have to stick very closely to what the user expects us to do out of the box. If we want to go beyond that we'd either have to get their explicit consent somehow (see anti-adblock warning removal list notification) or offer separate products for blocking non-ad related content.

Do you happen to know why EasyList doesn't include those filters in plain EasyList but only in EasyPrivacy? They might not be traditional ads but they're not traditional tracking either, one could argue.

comment:8 Changed 17 months ago by mapx

yeah, it can be considered abusive practice, probably would be better moving them in easylist.

Eventually @Arthur / @fanboy could respond ?

Last edited 17 months ago by mapx (previous) (diff)

comment:9 Changed 17 months ago by mapx

  • Cc fanboy arthur added; trev removed

comment:10 Changed 17 months ago by greiner

I created a spec ticket now for adding a warning to the options page to inform users if they have too many filters (see https://gitlab.com/eyeo/spec/issues/128).

Note: See TracTickets for help on using tickets.