I don't think Firefox will disappear, it can lose users but Google will always keep Firefox alive as a caution to prevent a split of their business by US Gov (like Microsoft have done with Apple). I would miss "Dynamic filtering" since I use it occasionally to un-break some filters that are good but that on specific website cause problems. The problem I see with option 3 if my understanding is fine is that a native app would not be able to remove some objects like cosmetic filters are doing ?įor me a native app sound like when I use AdAway on android, I'm pretty sure I'm missing something here about how would work a native app 🤔 ❓ On the other hand, overly broad RegExp rules from EasyList are constantly causing problems.įirst thanks for your very detailed answer. I don't think it'll be a problem because neither uAssets (nor me) really use RegExp rules. The only thing missing is RegExp rules (and HTML filtering if you want to count that). The badfilter option is resolved in compile time, so it doesn't matter. Same thing for redirection, (the current draft of) declarativeNetRequest supports redirect rules natively. The new APIs will actually make script snippets injection better, as the proposal contains new APIs that allow extensions to dynamically modify content scripts. The important, csp, and inline-script options (covered above)įor cosmetic filtering (normal and extended), pretty much everything is implemented in content scripts, which are not part of the manifest v3 proposal, so I would assume they are not going to change.
The inline-script option can be (AFAIK, is) implemented using csp.įor extended syntax, these are a few notable ones:
If not, it can still be implemented using content scripts (script snippets). It's not going to be pretty, but theoretically possible.įor the csp option, I think there'll be some way left to modify headers. Note that filters maintainers will probably have to publish their own filters as extensions then attach them to the public APIs of the coordinator. Each filter becomes an extension, one extension to enforce all important rules, and one master extension to help with whitelisting and management. When it comes to the important option, I think it's possible to implement with more than one extension. So as far as I'm concerned, that's not an issue. To be honest I don't even know how it works. The rules count limit is a legitimate concern (one of my two primary concerns mentioned above), as EasyList alone has more than 80k rules.Īs for dynamic filtering, I never use it. In the other thread, gorhill listed his concerns: If the 30k limit is lifted and rules can be dynamically modified, then I would say it's OK. The currently proposed APIs are on the weak side. If the new API is OK, then converting to the new API is probably going to be the easiest solution. And soon Chromium-based browsers will probably become the only usable browsers. If websites can more easily get around the weak APIs of Chrome, then website owners will have a motivation to push everyone to use Chrome. If the new API is really weak, then I don't think Firefox can survive for long.
0 kommentar(er)
