4 ms·
> gorhill's comments here indicate many issues remain with MV3 and that it still fails to meet his own requirements. How do you figure? Gorhill actually states
by staticassertion 4y ago
> gorhill's comments here indicate many issues remain with MV3 and that it still fails to meet his own requirements.
How do you figure? Gorhill actually states that there are many improvements only possible because of V3. What's also said is that for some features in the future there's further investigation required. And the last thing said in that comment is:
> Many users of uBO will dislike the limitations of uBOL when compared to uBO. There is no point complaining about it, it's just not for you, it's meant for another kind of users -- you do not have to use it.[..] but I want to offer an option for those who use uBO as an install-and-forget blocker without ever interacting with it.
I think you're kind of mischaracterizing the comment.
- AaronFriel 4y ago> Gorhill actually states that there are many improvements only possible because of V3. I think that's a charitable - to the Chrome team - misunderstanding of an artificial limitation they've imposed. The improvements are possible without MV3: * declarativeNetRequest is implemented today, they could expose it in MV2 * nothing prevents Google Chrome from continuing to offer the current onBeforeRequest API as a permission extensions can request in MV3 * nothing prevents Google Chrome from working with developers like gorhill, who are sensitive to performance concerns as you'll see below, to develop more powerful APIs that fit within a security and performance profile that satisfies end users, gorhill, and the Chrome team. On performance: While many of the performance improvements are made possible with a declarative API, uBlock Origin uses WebAssembly for an extremely performant fully dynamic blocking implementation that has almost no impact on battery life. (I believe other experiments have shown that blocking these requests yields increases in battery life, even.) You can see some benchmarks here that were posted from his experimentation: https://raw.githack.com/gorhill/uBlock/master/docs/tests/hnset-benchmark.html https://raw.githack.com/gorhill/uBlock/master/docs/tests/hns... On security: gorhill has proven that he's capable of writing WebAssembly to implement highly performant and sandboxed checking of dynamic filters. WebAssembly is in fact the perfect technology for a "declarativeNetRequest" to use. Could Chrome cut the Gordian knot of enabling performant and safe ad blocking extensions with an API that registers a WASM program as web request filter? The program could be limited to pass/fail/redact actions, where redact would involve removing headers, query parameters, trailing path parts. That is, "utm_campaign=..." could be removed, but the extension would not have a side channel for injecting information into requests.
- gorhill 4y agoFirefox adopted the `scripting` API and made it available for MV2 extensions: > This API is available in Manifest V3 or higher in Chrome and Firefox 101. In Safari and Firefox 102+, this API is also available in Manifest V2. When I say, it's not possible in MV2, I of course mean Google's version of MV2. --- [1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
- staticassertion 4y agoNice, I definitely think Firefox is doing it the right way.
- staticassertion 4y agoActually I changed my mind
- AaronFriel 4y agoNot so static, now? :)