Unaddressed MV3 regression with June deadline approaching

582 views
Skip to first unread message

Alex

unread,
May 1, 2024, 11:04:09 AMMay 1
to Chromium Extensions
With less one month till June, privacy and link cleaning extensions still face a critical functionality gap. It is still not possible to properly extract and redirect to URL-encoded components of URLs with Declarative Net Request.

For example, an extension may want to "clean" https://www.google.com/url?q= redirect URLs by extracting the value of the q parameter and issuing an internal redirect to the actual destination URL, to avoid unnecessary network requests and reduce data leakage to Google.

This issue impacts millions of extension users.

This is a regression from Manifest V2 where one could write imperative code that correctly decodes URL components. For example, inside a blocking webRequest.onBeforeRequest() listener:

```
let url = new URL(details.url).searchParams.get('q');
return { redirectUrl: url };
```

This was first reported in the W3C WebExtensions CG issue tracker:

The corresponding Chromium tracker issue:
https://issues.chromium.org/issues/338071843

Oliver Dunk

unread,
May 7, 2024, 6:01:15 AMMay 7
to Alex, Chromium Extensions
Hi Alexei,

Thanks for raising this. As I’m sure you noticed, we are supportive in general of implementing a way to extract and redirect to URL-encoded components in line with the issue you opened.

We did make the decision to focus on this after June, rather than before the deprecation. We made many improvements to Declarative Net Request over the last few months - but ultimately not every feature request could be completed before June. As you shared there are extensions that would use this functionality, but significantly fewer than would benefit from some of the other DNR changes we worked on and made a higher priority.

Looking at the request, I think there is a clear path for handling the simple cases, for example with example.com/?redirect=test.example.com. While we might not be able to support every variation, I am hopeful we can find ways to support some of the trickier cases where the URL has been added to the query parameter in a more encoded form. We’ll definitely think more about that ourselves and are open to brainstorming with you in the community group.

There are workarounds for the general case of extracting URL parameters, such as with RegEx filters and using content scripts. I know you have also pointed out limitations with those in various things you’ve written in the past, which is why we want to solve this at a platform level - but it does reduce the number of cases where developers are likely to hit this limitation.

We are very glad extensions like Privacy Badger exist and if you’d like to reach out to chat more about how to migrate specific features we’d be very open to that.
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB


--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/1aad87de-555e-4b81-812b-1b2677f395d3n%40chromium.org.

wOxxOm

unread,
May 7, 2024, 6:58:02 AMMay 7
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Alex
>  but significantly fewer than would benefit from some of the other DNR changes we worked on and made a higher priority.

Without verifiable statistics this is just an uneducated guess. In reality there are lots of use cases not covered by DNR, because its goal was always to solve just one use case: trivial modifications used in list-driven adblockers. It also doesn't help that there's just one developer working on this API, but to implement all the things that were possible previously with webRequestBlocking several more full-time developers would be necessary.

> While we might not be able to support every variation [...]
> There are workarounds for the general case of extracting URL parameters, such as with RegEx filters and using content scripts. I know you have also pointed out limitations with those in various things you’ve written in the past, which is why we want to solve this at a platform level - but it does reduce the number of cases where developers are likely to hit this limitation.

While your attempt to help is commendable, but this is not an approach expected from a sensible platform API developer, because if an API can only work for some trivial specific cases, it shouldn't be even suggested as a general-purpose solution due to the perceived randomness in the unsupported cases. Content scripts won't help with intercepting requests from DOM elements (the initial request will be made first since we can't use the synchronous mutation events anymore), observing the entire DOM incurs CPU overhead, intercepting window.open requires MAIN world injection, which is impossible to perform safely due to https://crbug.com/40202434, it won't help with requests from service workers and other workers, injecting a content script world into every frame is wasteful since it consumes memory and CPU, regexFilter supports only the most trivial expressions due to the size constraint.

In ManifestV2 and policy-installed ManifestV3 extensions a general-purpose solution exists: webRequestBlocking. Despite the entirely unsubstantiated claims made by ManifestV3 developers, its impact on performance is practically non-existent when used only for main_frame/sub_frame requests as they constitute just ~1% of all requests. A reasonable thing to do for a responsible developer team would be to allow using webRequestBlocking at least for main_frame/sub_frame requests until DNR matures sufficiently.

Alex

unread,
May 7, 2024, 9:28:31 AMMay 7
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Alex
Thanks, I appreciate your reply. However, Google is breaking its promise to not launch before closing critical functionality gaps. This isn't a feature request. This is something that trivially worked in Manifest V2 and does not work in Manifest V3. (You argue it half-works in Manifest V3 but do you understand that half-working is half-broken and that this is not good enough?) Yes, the Chrome extensions team is understaffed and has to prioritize fixes. Sounds to me like it's time to push back the deadline.

Oliver Dunk

unread,
May 7, 2024, 11:15:04 AMMay 7
to Alex, Chromium Extensions
Hi Alexei,

Our promise last year was to fix the prioritized platform gaps that we documented on developer.chrome.com. We announced that we had finished that work in November along with the new timeline for MV2 deprecation. Given that, we don’t plan to change the timeline.

As mentioned, we’re very supportive of this use case in general and it’s something we plan to build features around with time.
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

Alex

unread,
May 7, 2024, 11:56:47 AMMay 7
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Alex
You're telling me your failure to document missing functionality (an issue that was raised well in advance, in October 2022) is reason to declare all is well, we're go ahead with removing Manifest V2.

wOxxOm

unread,
May 7, 2024, 4:09:30 PMMay 7
to Chromium Extensions, Alex, Oliver Dunk, Chromium Extensions
Someone should probably start a list of all such regressions with links to extensions, probably in a github repository so that everyone can contribute.

Alex

unread,
Jun 11, 2024, 10:30:17 AMJun 11
to Chromium Extensions
A workaround with caveats is documented in https://issues.chromium.org/issues/338071843

There is now also a proposal for a new "decodeRegexMatches" property in DNR to address the most common redirect encoding scenario where the URL matched by the `regexFilter`'s capturing group is URI parameter encoded:

Matt

unread,
Jun 13, 2024, 7:42:20 AMJun 13
to Chromium Extensions, Alex
I appreciate everyone's position here but I want to come in and say that I feel there is a lot to be done still until people are ready for the sunsetting of MV2, even the commits suggest that Chromium itself isn't ready, and we are now in June, so is another date going to be announced where we can realistically expect MV2 support to be dropped, and in the meantime can we have a regression list and can we also close the gap with some of the missing functionality. This seems critical to me, and I know others are feeling the pain too.

Oliver Dunk

unread,
Jun 13, 2024, 7:58:17 AMJun 13
to Matt, Chromium Extensions, Alex
Hi Matt,

I'm definitely sorry to hear that the migration has been painful for you. Are there specific issues or gaps you're concerned about? Overall, most extensions should have a path forward at this point.

As we announced here we're moving forward with the deprecation timeline we previously announced. We have already begun showing warnings to users in pre-stable channels and will soon begin disabling extensions, so we're making definite progress with that work. We're always open to feedback but I do want to be honest that the deprecation is happening and that now is the time to migrate if you haven't already.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

woxxom

unread,
Jun 13, 2024, 8:24:21 AMJun 13
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Alex, Matt
>  Are there specific issues or gaps you're concerned about?
  • Full-featured uBlock Origin is impossible in MV3.
  • Userstyle extensions like Stylish or Stylus can't ensure there's no flashing of unstyled content when the site is faster than the time to start the background script and load the styles.
  • Live editing of background scripts is impossible in devtools workspaces, so we have to reload the entire extension and re-open all its tabs, popups, re-inject content scripts, lose the state. This alone pushes us twenty years back in time.

Matt

unread,
Jun 13, 2024, 8:33:06 AMJun 13
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Alex, Matt
Due to all the complications in how we have to block in MV3, we are still literally on a daily basis working out how to get features to work across all sites that we support, and we are a full team of professional devs, the workarounds we've had to come up with are flabbergasting to say the least, due to commercial sensitivity I can't divulge without obtaining permission from my employer, but I can tell you know that the transition from .NET to .NET Core was nothing like this and that was substantially more complicated. Even the dates specified in the link are wrong because it is the 13th now and there is nothing in the commits that materialises on the GUI for us to test so that we can prepare for when we need to support clients with the switchover. I'm not sure how others stand in this, but we've not only lost faith with Chrome, but also Google.

Oliver Dunk

unread,
Jun 13, 2024, 8:41:00 AMJun 13
to Matt, Chromium Extensions, Alex
Hi Matt,

As I'm sure you can understand it's hard to say anything concrete without being able to talk about specific issues. If you are able to get permission to share them either here or privately, that would be great and we'd definitely be happy to chat.

Regarding the blog post, is there a specific line you are referring to? We said that on June 3rd "some will start to see a warning banner" and that is currently the case. This is a slow rollout because we are being very cautious and want to do it carefully, so it won't affect everyone at the same time.
Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

Matt

unread,
Jun 13, 2024, 8:48:04 AMJun 13
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Alex, Matt
You can't roll out what isn't in the code, so when you say start to, the rollout hasn't started yet.

Why can't you just push back the date if you aren't ready yet because of a myriad of features that aren't ready, and that others are saying they aren't ready, which is on part because you're not ready?

Oliver Dunk

unread,
Jun 13, 2024, 8:57:09 AMJun 13
to Matt, Chromium Extensions, Alex
Hi Matt,


This is already enabled for some users in pre-stable channels.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

Matt

unread,
Jun 13, 2024, 9:08:04 AMJun 13
to Chromium Extensions, Oliver Dunk, Chromium Extensions, Alex, Matt
Thank you but I am aware of that code, I know too that this code is not yet doing anything that anyone can get their hands on, only developers of the browser can use the code at the moment.

Patrick Kettner

unread,
Jun 13, 2024, 9:13:09 AMJun 13
to Matt, Chromium Extensions, Oliver Dunk, Alex
It actually is doing something, just for a small percentage of users. You can opt into the experience by launching a Chrome with a version higher than126.0.6468.0 with the flag --enable-features="ExtensionManifestV2DeprecationWarning"

patrick

Matt

unread,
Jun 13, 2024, 9:29:07 AMJun 13
to Chromium Extensions, Patrick Kettner, Chromium Extensions, Oliver Dunk, Alex, Matt
Thanks Patrick, appreciate you pointing this out, at the very least it is a start so that we can start to show people what to expect.
Reply all
Reply to author
Forward
0 new messages