Clarification on CORB/CORS rules

[Marcus McLaughlin]

Hi,

  If it's possible, I'd like some clarification on the CORB/CORS rule changes that extension developers should expect to see and when.

  In March, upon the release of CORB blocking, we had our extension added to the allowlist, and resumed business as usual.  We were planning to do more work to understand what was necessary in order to move all of our cross-origin requests to our background page.  However, shortly after that we found this comment and thread about the future unification of CORB and CORS [https://bugs.chromium.org/p/chromium/issues/detail?id=920638#c13].  Our understanding after reading this was that extensions would be allowed to continue to make cross-origin requests from their content scripts, as long as the requests were CORS-approved.  Additionally, I understood this thread to mean that no reputationally or functionality detrimental actions (publishing allow-list, or removing items from the allowlist) until CORS and CORB are unified.   As a result, we didn't see a need to move our requests to the background page.  That was our status until about a week ago.

On 10/30, with Chrome 78 reaching stable, the pre-production versions of our extensions stopped successfully making cross-origin requests due to the removal of the ability to disable the BypassCorbOnlyForExtensionsAllowlist flag.  Although this wasn't in direct conflict with any of the prior information received, it was surprising, and caused us to inspect v79 and v80 to see if there were any changes to this functionality in those versions.  We found that v79 did not work with our production extension which is on the allowlist, and v80 did.  Upon inspecting the changelog, it looks like this change: https://chromium.googlesource.com/chromium/src/+/3bc5ad98e0e835e86ad4f85f0401f72b471cd658, may be the difference, and mentions there being value in including it in v79 as well, which is consistent with our experience.  However, if this results in CORS-approved requests being immune from CORB, then it seems that it should also result in our pre-production extensions functioning as well.   However, it appears that our cross-origin requests from our pre-production extensions are still being blocked via CORB.  That leads to the conclusion that only those extensions on the allowlist can make CORB requests currently.

Lastly, I'd expect to see an 'origin' request header on XHRs from content scripts if CORB and CORS are unified, but haven't seen that on any of the versions of Chrome, regardless of whether OOR-CORS is enabled or disabled.

We have a few questions as a result:

• Is our understanding of what will happen under CORB and CORS unification correct, or did we misinterpret something and actually we do need to move all of our cross-origin requests to the background-page?
• Should we expect to find 'origin' headers on content-script XHRs?
• Has the plan changed in regards to not publishing the allow-list, or removing items from the allow-list until CORS and CORB are unified?
• We've considered the possibility that CORB and CORS are not yet unified, and the allowlist is the only way to allow cross-origin requests from content-scripts to be completed until we reach that point.  If that's true, is the omission of 3bc5ad98e0e835e86ad4f85f0401f72b471cd658 a bug that we should expect to see resolved before v79 goes stable?

I'm happy to answer any questions that I can.

Thanks,

Marcus

[Chris Cowan]

+1, I'm in the same boat here with our Chrome extension that was on the allowlist. From https://bugs.chromium.org/p/chromium/issues/detail?id=920638 which was linked from https://www.chromium.org/Home/chromium-security/extension-content-script-fetches, I was under the impression that the CORB behavior wasn't changing until CORB and CORS were unified, and that this unification meant that cross-origin requests from content scripts would be treated as equivalent to CORS requests from the containing web page, which in our case worked, so I didn't believe our extension would need any changes. Chrome v78 removed or broke the --disable-features=BypassCorbOnlyForExtensionsAllowlist flag which broke our development builds, and the Chrome v79 Beta seems to have removed or broke the CORB extension allowlist which broke our production extension. We have workarounds ready, but I'm concerned that I may be misunderstanding Chrome's plans for extension CORB behavior.

[Hansen Qian]

Not to pile on, but we've experienced the same issues you've described: Two of our Chrome extensions that were on the allowlist which were making cross-origin content script requests suddenly broke in v79 (but are still working in v80).

Based off of the testing that we've done internally (and reading Marcus and Chris's bug descriptions), it seems to me the most likely solution is that the allowlist was incorrectly removed in v79, but not yet in v80. Nothing to me points to the fact that CORS and CORB were successfully unified, since the origin header is still not being sent for requests sent from the content script. 

As a result, we've had to push an immediate workaround for our many of our customers that are using Chrome Beta v79, in order to address the fact that our content scripts, which were previously able to make cross-origin requests without being blocked, were now displaying a "CORB blocked cross-origin response" error. 

(see my previous question in this thread https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/1hJtDYUAWf8/cqplIqtwAQAJ)

I have the same question as above: 

• Does Chrome v79 still respect the chrome extensions on the allowlist? 
• If so, could we get an an explanation as to what change started blocking cross-origin content script requests?
• If not, could we expect this change to be reverted? And some clarification on what the future plans of the CORB/CORS unification are?

Best,

Hansen

[Simeon Vincent]

At first blush this seems like it may be related to the Re: Heads-up on webRequest API changes in m76 and OOR-CORS (previously mentioned as Network Service CORS in this group) thread. I'll also reach out to Takashi to get his eyes on this thread.

Simeon - @dotproto

Extensions Developer Advocate

[Takashi Toyoshima]

Thanks Simeon, let me ask +Łukasz Anforowicz since the first mail mentioned about CORB allow-list.

--
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/6b368e35-62a0-4ea1-8bd0-1dced83f8af5%40chromium.org.

--

Takashi Toyoshima
Software Engineer, Google

[Marcus McLaughlin]

As an update, https://chromium.googlesource.com/chromium/src/+/3bc5ad98e0e835e86ad4f85f0401f72b471cd658 has been merged into v79.0.3945.29 and now our allowlisted extension works fine.  I can't definitely say that this commit is the cause, but at the very least they're correlated.  This answers the last of the 4 questions I asked, and overall makes this issue much less urgent for us at Amitree.

However, I'm still really interested in anything you can tell me in regards to the rest of the questions listed.

Thanks,

Marcus

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/6b368e35-62a0-4ea1-8bd0-1dced83f8af5%40chromium.org.

[Łukasz Anforowicz]

On Mon, Nov 11, 2019 at 1:49 PM Marcus McLaughlin <mar...@amitree.com> wrote:

As an update, https://chromium.googlesource.com/chromium/src/+/3bc5ad98e0e835e86ad4f85f0401f72b471cd658 has been merged into v79.0.3945.29 and now our allowlisted extension works fine.  I can't definitely say that this commit is the cause, but at the very least they're correlated.  This answers the last of the 4 questions I asked, and overall makes this issue much less urgent for us at Amitree.

However, I'm still really interested in anything you can tell me in regards to the rest of the questions listed.

I'll try to answer some of the questions below.  This is a long thread, so if I miss an important question, please let me know.

On Wednesday, November 6, 2019 at 10:24:47 PM UTC-5, Takashi Toyoshima wrote:

Thanks Simeon, let me ask +Łukasz Anforowicz since the first mail mentioned about CORB allow-list.

On Thu, Nov 7, 2019 at 11:17 AM Simeon Vincent <sim...@chromium.org> wrote:

At first blush this seems like it may be related to the Re: Heads-up on webRequest API changes in m76 and OOR-CORS (previously mentioned as Network Service CORS in this group) thread. I'll also reach out to Takashi to get his eyes on this thread.

Simeon - @dotproto

Extensions Developer Advocate

On Wednesday, November 6, 2019 at 12:22:26 PM UTC-8, Hansen Qian wrote:

Not to pile on, but we've experienced the same issues you've described: Two of our Chrome extensions that were on the allowlist which were making cross-origin content script requests suddenly broke in v79 (but are still working in v80).

Based off of the testing that we've done internally (and reading Marcus and Chris's bug descriptions), it seems to me the most likely solution is that the allowlist was incorrectly removed in v79, but not yet in v80. Nothing to me points to the fact that CORS and CORB were successfully unified, since the origin header is still not being sent for requests sent from the content script. 

Correct - CORS and CORB are not yet unified.  This work is tracked under https://crbug.com/920638.  There is no ETA for this work yet, but I hope to remove blockers for this in M80 and M81 and give a heads-up on chromium-...@chromium.org before making this (potentially-breaking) change later.

As a result, we've had to push an immediate workaround for our many of our customers that are using Chrome Beta v79, in order to address the fact that our content scripts, which were previously able to make cross-origin requests without being blocked, were now displaying a "CORB blocked cross-origin response" error. 

(see my previous question in this thread https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/1hJtDYUAWf8/cqplIqtwAQAJ)

I have the same question as above: 

• Does Chrome v79 still respect the chrome extensions on the allowlist? 
• If so, could we get an an explanation as to what change started blocking cross-origin content script requests?
• If not, could we expect this change to be reverted? And some clarification on what the future plans of the CORB/CORS unification are?

I assume that this was caused by https://crbug.com/1017448.  My apologies for missing the XHR-specific code when working on https://crbug.com/940068 (which is a prerequisite for CORB/CORS allowlist unification).  This issue should be fixed in 80.0.3954.0+ and in 79.0.3945.23+.

Best,

Hansen

On Tuesday, November 5, 2019 at 6:30:22 PM UTC-8, Chris Cowan wrote:

+1, I'm in the same boat here with our Chrome extension that was on the allowlist. From https://bugs.chromium.org/p/chromium/issues/detail?id=920638 which was linked from https://www.chromium.org/Home/chromium-security/extension-content-script-fetches, I was under the impression that the CORB behavior wasn't changing until CORB and CORS were unified, and that this unification meant that cross-origin requests from content scripts would be treated as equivalent to CORS requests from the containing web page, which in our case worked, so I didn't believe our extension would need any changes. Chrome v78 removed or broke the --disable-features=BypassCorbOnlyForExtensionsAllowlist flag which broke our development builds, and the Chrome v79 Beta seems to have removed or broke the CORB extension allowlist which broke our production extension. We have workarounds ready, but I'm concerned that I may be misunderstanding Chrome's plans for extension CORB behavior.

On Tuesday, November 5, 2019 at 2:10:38 PM UTC-8, Marcus McLaughlin wrote:

Hi,

  If it's possible, I'd like some clarification on the CORB/CORS rule changes that extension developers should expect to see and when.

  In March, upon the release of CORB blocking, we had our extension added to the allowlist, and resumed business as usual.  We were planning to do more work to understand what was necessary in order to move all of our cross-origin requests to our background page.  However, shortly after that we found this comment and thread about the future unification of CORB and CORS [https://bugs.chromium.org/p/chromium/issues/detail?id=920638#c13].  Our understanding after reading this was that extensions would be allowed to continue to make cross-origin requests from their content scripts, as long as the requests were CORS-approved.  Additionally, I understood this thread to mean that no reputationally or functionality detrimental actions (publishing allow-list, or removing items from the allowlist) until CORS and CORB are unified.

This is correct - before CORB and CORS unification happens (i.e. before https://crbug.com/920638 is fixed and announced on chromium-...@chromium.org) we don't plan to make any changes to the CORB allowlist.  Any unintentional changes should be treated as bugs.

 

As a result, we didn't see a need to move our requests to the background page.

This is the right conclusion for extensions that can't be removed from the allowlist because they depend on CORS and CORB unification.  This dependency doesn't affect all the extensions on the allowlist.

That was our status until about a week ago.

On 10/30, with Chrome 78 reaching stable, the pre-production versions of our extensions stopped successfully making cross-origin requests due to the removal of the ability to disable the BypassCorbOnlyForExtensionsAllowlist flag.

I see.  That feature has been enabled by default since M73, so I thought that it should be safe to remove it from the code base (simplifying some code along the way and hopefully making it harder to introduce regressions due to the complexity of the code and the test matrix).  I am sorry for missing that disabling the feature might be useful for testing pre-release extension versions.  Please let me know by opening a bug here if your extension is already on the allowlist and you need to add a pre-release extension id to the allowlist.

 

Although this wasn't in direct conflict with any of the prior information received, it was surprising, and caused us to inspect v79 and v80 to see if there were any changes to this functionality in those versions.  We found that v79 did not work with our production extension which is on the allowlist, and v80 did.  Upon inspecting the changelog, it looks like this change: https://chromium.googlesource.com/chromium/src/+/3bc5ad98e0e835e86ad4f85f0401f72b471cd658, may be the difference, and mentions there being value in including it in v79 as well, which is consistent with our experience.  However, if this results in CORS-approved requests being immune from CORB, then it seems that it should also result in our pre-production extensions functioning as well.   However, it appears that our cross-origin requests from our pre-production extensions are still being blocked via CORB.  That leads to the conclusion that only those extensions on the allowlist can make CORB requests currently.

Lastly, I'd expect to see an 'origin' request header on XHRs from content scripts if CORB and CORS are unified, but haven't seen that on any of the versions of Chrome, regardless of whether OOR-CORS is enabled or disabled.

We have a few questions as a result:

• Is our understanding of what will happen under CORB and CORS unification correct, or did we misinterpret something and actually we do need to move all of our cross-origin requests to the background-page?
• Should we expect to find 'origin' headers on content-script XHRs?
• Has the plan changed in regards to not publishing the allow-list, or removing items from the allow-list until CORS and CORB are unified?

No change of plans here. 

• We've considered the possibility that CORB and CORS are not yet unified, and the allowlist is the only way to allow cross-origin requests from content-scripts to be completed until we reach that point.  If that's true, is the omission of 3bc5ad98e0e835e86ad4f85f0401f72b471cd658 a bug that we should expect to see resolved before v79 goes stable?

I'm happy to answer any questions that I can.

Thanks,

Marcus

--
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/6b368e35-62a0-4ea1-8bd0-1dced83f8af5%40chromium.org.

[Marcus McLaughlin]

Hi Lukasz,

   Thank you for your thorough response.  I'll open a bug for our pre-release extension.

Thanks,

Marcus

[nightpool]

Hey Łukasz,

Our users just started being affected by a wide-spread CORS issue on M78 stable, even with OOB-CORS disabled. We pushed out a change this morning that added a header to the content script codepath. For some chromium installs, users are seeing CORS preflight requests due to this header. However, for some installs, including my own, no CORS preflight requests are being generated. This inconsistency—and the fact that CORS preflight requests should never happen for content script code in the first place—makes me believe it might be due to a lurking chromium bug. Can you take a look? 

Details here, including netlog exports: https://bugs.chromium.org/p/chromium/issues/detail?id=1026462

Thanks!

On Mon, Nov 11, 2019 at 5:24 PM Łukasz Anforowicz <luk...@chromium.org> wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAA_NCUFUR5cXPgynFX5mzM9CdPtaM%2BsbR%2BvsH4S%3DLbNqkrscDw%40mail.gmail.com.

[PhistucK]

> and the fact that CORS preflight requests should never happen for content script code in the first place

If you are on the allow list, you mean? Otherwise, preflight requests should behave the same as in normal webpages.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAJY4u8G_OrQOxGsbitMRS73qwWjeaQJh2nybD6Ywfg9T4Fiujg%40mail.gmail.com.