Chrome Manifest V3 discussion megathread

[mikhoul]

Hi,

I really like Nano more than UBO but I was asking to myself what will be your direction if the proposal is adopted and that the actual API is neutered ?

My understanding is that Chrome (for me ) would become inferior to Firefox for adblockers (unless Firefox implement the same restriction which I doubt).

If the change happen they can happen in the next 12 months which is relatively fast so the solutions/alternatives I've see are:

• Make an official version for Firefox and drop Chrome.
• Make an Edge version with their new browser with blink engine IF they don't have the same restriction.
• Submit to the new API and have an inefficient adblocker comparing to today.
• Forking Chromium keeping the old API as it is today and have a version especially build for Nano.

Maybe there is other solutions that I don't foresee. 🤔

What is your take on this @jspenguin2017 ?

[jspenguin2017]

I see 3 options:

• Use the new API
• Fork Chromium
• Make a native app

I'll explain in detail later.

I would guess Edge will closely follow Chromium, so that's probably not going to work.
What about Firefox? Well, I'll explain later.

[jspenguin2017]

Option 1: Use the new API

If the new API is really weak, then I don't think Firefox can survive for long. 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. And soon Chromium-based browsers will probably become the only usable browsers.

If the new API is OK, then converting to the new API is probably going to be the easiest solution.

The currently proposed APIs are on the weak side. If the 30k limit is lifted and rules can be dynamically modified, then I would say it's OK.

In the other thread, gorhill listed his concerns:

• Rules count limit
• Dynamic filtering
• The important option
• The csp and inline-script options
• Extended syntax

The rules count limit is a legitimate concern (one of my two primary concerns mentioned above), as EasyList alone has more than 80k rules.

As for dynamic filtering, I never use it. To be honest I don't even know how it works. So as far as I'm concerned, that's not an issue.

When it comes to the important option, I think it's possible to implement with more than one extension. Each filter becomes an extension, one extension to enforce all important rules, and one master extension to help with whitelisting and management.
Note that filters maintainers will probably have to publish their own filters as extensions then attach them to the public APIs of the coordinator. It's not going to be pretty, but theoretically possible.

For the csp option, I think there'll be some way left to modify headers. If not, it can still be implemented using content scripts (script snippets). The inline-script option can be (AFAIK, is) implemented using csp.

For extended syntax, these are a few notable ones:

• Cosmetic filtering
• Script snippets injection
• Request redirection
• The badfilter option
• The important, csp, and inline-script options (covered above)

For 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 new APIs will actually make script snippets injection better, as the proposal contains new APIs that allow extensions to dynamically modify content scripts.

Same thing for redirection, (the current draft of) declarativeNetRequest supports redirect rules natively.

The badfilter option is resolved in compile time, so it doesn't matter.

The only thing missing is RegExp rules (and HTML filtering if you want to count that). I don't think it'll be a problem because neither uAssets (nor me) really use RegExp rules. On the other hand, overly broad RegExp rules from EasyList are constantly causing problems.

[jspenguin2017]

Option 2: Fork Chromium

I would assume code for manifest v2 will eventually be removed, so the forking process will eventually become not a simple flag flip. Maintaining a browser fork is really difficult in general, and vulnerabilities can be opened if not careful.

Another way is to use Electron to build a new browser. Unlike WebExtension, Electron provides really powerful APIs, which are unlikely to go away. However, the amount of work to maintain a browser is likely more than that of a fork, but since Electron apps use JavaScript and not native code, vulnerabilities are less likely to occur.

Also, implementing WideVine (DRM) will be really difficult in either case.

[jspenguin2017]

Option 3: Make a native app

There's a shell there's a way. I'm sad to see that there's no open source native app that does more than DNS blocking.

A native app is the best way to get around the constantly changing browser APIs, and as a bonus, it'll probably work for all browsers and even non-browser apps.

I'm not sure how hard this will be though, last time I tried it didn't go so well.

[jspenguin2017]

I probably will go with option 1 or 3. As for the timeline, I don't think it'll happen within 12 months. Right now, the APIs are not released yet, and the phase out period will likely take more than a year.

I think it's a good time to get started on option 3, if things go wrong, option 1 can be used as fallback.

[mikhoul]

First thanks for your very detailed answer. 👍

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 ?

For 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 🤔 ❓

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.

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).

IMO if Google weaken their API for blocking ads it could revigorante Firefox with power-users and gain 2-3% of users. When I migrated from Firefox to Chromium I dragged with me ~150 users and those users today recommend Chrome/chromium to their friends and I'm pretty sure I'm not alone.

But Mozilla management is crazy those day they removed so many things/features that I migrated to Chromium to stop from suffering from the many memory leaks in Firefox. So in one way it would not surprise me that they do some crazy thing in the future like following the very same Chrome API unless the management at Mozilla change.

For the fork I was thinking it was more easy than you said it is to keep the old API, like some module you glue to the main code when you build chromium and that don't require lot of maintenance. I've seen Slimjet a Chromium fork and with an integrated ad-blocker so I was thinking it was "easy" to integrate in a fork.

Time will tell.

[jspenguin2017]

native app would not be able to remove some objects like cosmetic filters are doing

Again, there's a shell there's a way. Native apps are (theoretically) able to do cosmetic filtering on their own as they can patch everything the browser receives, however, I do agree that for cosmetic filtering, it's easier to implement using extensions.

There's nothing stopping native apps from loading extensions into browsers, so if needed, the native app can have a companion extension.

sound like when I use AdAway on android

AdAway is a DNS manager, it is really limited in what it can do. I'm talking about native apps that can repack HTTPS requests.

but Google will always keep Firefox alive as a caution to prevent a split of their business by US Gov

Possibly.

But Google can also point to those 20+ Chromium forks and say their code is under a permissive license, and everyone is free to fork and compete.

For the fork I was thinking it was more easy than you said

I never tried so I don't know for sure. Maybe you're right.
If you have more experience with the Chromium code base maybe you can start a Chromium fork?

[jspenguin2017]

Actually instead of trying to reinventing the wheel and fail miserably, I'll probably just take a wheel off the shelf.

I'll probably still need a JavaScript runtime though, as RegExp in filters are JS RegExp. For a prototype it'll be fine, if it works out I'll worry about optimization later.

[mikhoul]

Thanks for your complete and detailed answer it's enlighting and it remove interrogations I had. 👍

So it would be a little bit how AdGuard work, I never used AdGuard but my understanding is that there is a component that work at the OS level and another part as an extension for better efficiency.

If you have more experience with the Chromium code base maybe you can start a Chromium fork?

I don't have experience but it is something I 'm thinking about for 2-3 months to be able to modify the Chromium GUI and keep it tight, maybe I will give it a try this year, this issue will ad some motivation make this project higher in my priority.

Regards

[onmyouji]

Another way is to use Electron to build a new browser. Unlike WebExtension, Electron provides really powerful APIs, which are unlikely to go away. However, the amount of work to maintain a browser is likely more than that of a fork, but since Electron apps use JavaScript and not native code, vulnerabilities are less likely to occur.

I don't really know about Electron, but I remember this talk about building a web browser in Electron. The security engineer actually recommends not try to do it. Their company tried it and it didn't go so well.

[nl255]

Option 1: Use the new API
If the new API is really weak, then I don't think Firefox can survive for long. 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. And soon Chromium-based browsers will probably become the only usable browsers.

Are you saying that websites will simply block Firefox users entirely if Firefox insists on keeping the existing webRequest API?

Option 3: Make a native app
There's a shell there's a way. I'm sad to see that there's no open source native app that does more than DNS blocking.
A native app is the best way to get around the constantly changing browser APIs, and as a bonus, it'll probably work for all browsers and even non-browser apps.
I'm not sure how hard this will be though, last time I tried it didn't go so well.

For this to work it would need to support HTTPS interception/rewriting which while it can be done opens up a huge can of worms security wise, especially if it is not done properly. It would also require having a companion GUI app for creating and installing the custom SSL certificate used for said interception as most people aren't going to be able to do it on their own using the standard command line tools. Even worse, on Android by default apps will not trust user installed root certificates (Chrome does but many other browsers and apps do not) and will need to be patched (unless the device is rooted, then the certificate can be installed to the system certificate store either directly or with a Magisk module).

[mikhoul]

@jspenguin2017 I have my answer for a fork on chromium to bypass a weak API if it was needed it'S possible and Brave seem to already use this strategy:

A developer on the Brave team was explaining it on Reddit:

---

_Bat-chriscat
BAT TEAM[M] 34 points 1 day ago* RemindMe!

It's worth noting that our Brave Shields (ad blocker) is not an extension; it is natively implemented. So extension API changes leave our shields unaffected.

Edit: We can always remove any code or update we don't like from the Chromium base we use. So even if this didn't just affect extensions but something deeper, we could just exclude it._

---

Source: https://old.reddit.com/r/brave_browser/comments/aijqm4/chrome_may_soon_change_how_3rd_party_ad_blockers/eeopqpb/

So maybe if they already do that you could fork Brave to integrate natively Nano inside and bypassing the API to intercept the calls you need ? 🤔

This way it would be future proof and the control would be very granular to block everything. User would just install the browser and use it. ☺️

Regards

[nhantrn]

@jspenguin2017 You might want to checkout Proxydomo hosted here on github. https://github.com/amate/Proxydomo

It's a local proxy with https filtering capability. I've been using it to strip out <script /> among other filters of blacklisted pages before it even reach the browser. It's a reverse engineered program of the popular Proximitron in the early 2000s.

There's also a recent separate effort called Proximitron Reborn, but I think the author of that hasn't release the source she promised yet. On going discussion of it is on the ancient prxbx forum here: https://prxbx.com/forums/showthread.php?tid=2331