Manifest V3

[khlr]

SAML-tracer is currently a Manifest V2 WebExtension. In 2018, Chrome announced Manifest V3. Migrating to Manifest V3 requires quite some effort form a WebExtension, but in principle it is probably doable. Have a look at the Firefox- or Chrome-Migration Guide for more details.

However, Chrome will discontinue support for V2 by the end of 2022. So theoretically there is not much time left if we wanted to continue to provide SAML-tracer for Chrome. See the Chrome-Manifest V2 support timeline for more details.

Well, that's still five months. More than enough time one could think. But there's a really nasty gotcha... Chrome drops support for the WebRequest API! But the WebRequest API is the central linchpin of SAML-tracer. As an alternative there's the new Declarative Net Request API (declarativeNetRequest / DNR).
From the point of view of SAML-tracer, however, this API is far from sufficient. For privacy reasons, it does not allow access to potentially confidential contents of requests. However, full access to cookies, headers, etc. is essential for SAML-tracer to function.

What does this mean?

From my understanding this renders SAML-tracer effectively in-migrateble to Chrome's Manifest V3. In the end, this would mean that we could no longer provide SAML-tracer as a Chrome WebExtension. This is bad and really sad news 😥 I was so happy when we added support for Chromium-based browsers back then.

So what about Firefox?

At least in this respect there are a few positive points 😌 Firefox takes a more relaxed approach. There is no final deprecation date yet:

We have not yet set a deprecation date for Manifest v2 but expect it to be supported for at least one year after Manifest v3 becomes stable in the release channel.

and:

Work is continuing in parallel, and we expect to launch MV3 support for all users by the end of 2022.

This could be understood to mean that V2 will still be supported for the entire year 2023.

But that's not all. The folks at Mozilla also feel the omission of the webRequest API is critical. Therefore, in parallel with the new declarativeNetRequest, they will continue to support the webRequest API in MV3!

We will support blocking webRequest until there’s a better solution which covers all use cases we consider important, since DNR as currently implemented by Chrome does not yet meet the needs of extension developers.

--

What's your take on the whole thing, @jaimeperez, @thijskh, @tvdijen?

--

Resources:

• Chromium Blog - Trustworthy Chrome Extensions, by default
• Firefox Extension Workshop - Manifest V3 migration guide
• Chrome Developers - Migrating to Manifest V3
• Chrome Developers - Manifest V2 support timeline
• Chrome Developers - Migrating to Manifest V3 - Modifying network requests
• Chrome Developers - chrome.declarativeNetRequest
• GitHub/SAML-tracer - Pull request 45
• Mozilla Add-ons Community Blog - Manifest v3 update
• Mozilla Add-ons Community Blog - Manifest v3 in Firefox: Recap & Next Steps

[tvdijen]

I never read anywhere that the WebRequest API is being dropped by Chrome.. Just that you need to use their new API for modifying requests. Also, when looking at the sunset list, I don't think we use any of those?

[kellenmurphy]

@tvdijen and @khlr -- from the migration checklist it DOES seem that it is only deprecated for blocking webRequests... can't we just remove 'blocking' from the extraInfoSpec?

Perhaps I'm wrong... but I did a quick smoke test of the current code with 'blocking' removed from extraInfoSpec and the "webRequestBlocking" permission removed from the manifest. The module still works as desired in Chrome with those changes. Since it's this "webRequestBlocking" permission that needs to be replaced with "declarativeNetRequest", I would assert that there's a good chance that this is sufficient for the next iteration of the code with Manifest V3.

Are there circumstances where the module would actually block a webRequest? I can't think of any... but I fully assert that I'm not an expert here.

I'm very happy to help with the effort to migrate to Manifest V3. This tool is too essential for my work (and my customers) to not support it!

[khlr]

Citing one of my favourite idioms: Those who can read have a clear advantage.
So you're obvisously in advance 😁

Are you currently using the blocking version of chrome.webRequest?

So you're certainly right, @kellenmurphy! I simply overread that crucial little word.

SAML-tracer probably works fine without webRequestBlocking but there's one situation where I'm not completely sure if the blocking-feature will be necessary:

The reviseRedirectedRequestMethod alters a request's HTTP method under certain circumstances.

The docs say this regarding responses:

To do this [modifying responses], you must have the "webRequestBlocking" API permission as well as the "webRequest" API permission [...]

SAML-tracer doesn't need to modify responses but requests... So we may get around needing the blocking-feature if webRequest suffices to modify requests. I guess we'll just have to give it a try.

[kellenmurphy]

Ironically from the note, FF is the misbehaving party for Case 2 in reference to the reviseRedirectedRequestMethod issue.

It's on my to-do list to attempt to help with this, so I'm glad to report back my findings. From a naive look at the errors thrown from a first go-through last night this looks like a doable job for me. That said, now that I see your note on where this might fail, I'll mock up an example of Case 1 failure right away and see what happens. I think I can replicate that pretty easily.

[kellenmurphy]

I have a PR for this coming inbound shortly. It needs to be evaluated by others, especially in light of #79 (comment), as I'm not 100% certain I'm accurately reflecting the circumstances in which that code is invoked. I will provide more context on the PR.

It also should be noted that FF doesn't yet support MV3, so we'll need to hold off on MV3 until that support comes out later this year.

[thijskh]

As an update, Chrome announced that the deadline for dropping Manifest V2 is now pushed back to June 2023 at the earliest.

[kellenmurphy]

Further update: MV2 support in Chrome will be continued for some time. In March 23, they promised at least 6 months notice before deprecation of MV2 in favor of MV3.

I was going to pick up my PR and prep this last summer, but changed jobs and got busy last October. I can still pick this up at some point 😀

[tvdijen]

Your contributions are still very welcome @kellenmurphy !!

[khlr]

Hi Kellen! Yep, this would be great 👍

[khlr]

Unfortunately, this issue is now becoming urgent... MV2 extensions will be disabled from June 2024 in pre-stable versions of Chrome and then (June 2024 + 1-X months) also in the stable releases!
This means that from July 2024 we have to expect that SAML-tracer can no longer be installed by users!
https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline

@kellenmurphy, will you be able to implement the necessary adjustments in the remaining time? Should I support you? Should I take over this issue?

[kellenmurphy]

@khlr I think I can do that, no problem. I was waiting for an update and apparently missed this one. I will pick this back up shortly :-)

[tvdijen]

Thanks for your efforts @kellenmurphy ! I see I have messed up your PR after rebasing it.. Let me make sure it's back to a workable state before you continue your work!