Heads-up on webRequest API changes in m76 and OOR-CORS (previously mentioned as Network Service CORS in this group)

[Takashi Toyoshima]

Hi Extensions developers,

Here is an update of OOR-CORS rollout status.

We rolled out OOR-CORS feature at m76, and introduced incompatible behaviors in webRequest API as the current developers' document explains.

Starting from Chrome 76, header modifications affect Cross-Origin Resource Sharing (CORS) checks. If modified headers for cross-origin requests do not meet the criteria, it will result in sending a CORS preflight to ask the server if such headers can be accepted. If you really need to modify headers in a way to violate the CORS protocol, you need to specify 'extraHeaders' in opt_extraInfoSpec.

Starting from Chrome 76, the following request header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

But for another reason, we temporarily rollback these behavior changes until the next Chrome 77, coming in about 10+ days.

If you already confirm your Extensions work well with Chrome 76, you do not need anything to do. But please do not revert Extensions side updates if you made some changes for Chrome 76. Your Extensions should continue to work as-is during the remaining Chrome 76 period and with new Chrome 77.

If you feel something is wrong on the Extensions compatibility, and need to file a new bug, you can specify following Components labels;

Blink>SecurityFeature>CORS

Platform>Extensions>API

Blink>Loader

NetLog will also provide useful information to understand detailed scenario for reproductions. So please consider to attach it if you can and are fine.

Thanks in advance,

--

Takashi Toyoshima
Software Engineer, Google

[PhistucK]

Adding the chromium-extensions Google group.

(I did not know extensions-dev existed)

Also, note that normal users cannot set more than one component (and only at report-time using the wizard) on issues.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "loading-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1%3DEKCwzsZqq8hu9LNRH675162v7KfiaCCDsjq0TAAEhKw%40mail.gmail.com.

[Takashi Toyoshima]

On Fri, Aug 30, 2019 at 4:41 PM PhistucK <phis...@gmail.com> wrote:

Adding the chromium-extensions Google group.

(I did not know extensions-dev existed)

Also, note that normal users cannot set more than one component (and only at report-time using the wizard) on issues.

Oh, I didn't notice that normal users did not have much controls on reporting bugs.

In such case, please send a mail to me with the filed crbug number so that you can ensure that the issue was recognized by me. I will triage it ASAP.

Thanks.

[Takashi Toyoshima]

OK, great! This link can be used for filing a bug with required components and cc: me.

These parameters are not visible while you are editing the bug, but once it is submitted, fields will be correctly set automatically.

On Fri, Aug 30, 2019 at 11:13 PM <wox...@gmail.com> wrote:

You can specify all those in a URL like it's done on chromestatus.com, see the "bug" button on an example page: link.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1%3DEKCwzsZqq8hu9LNRH675162v7KfiaCCDsjq0TAAEhKw%40mail.gmail.com.

--

Takashi Toyoshima
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "network-service-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to network-service...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/network-service-dev/3fce464c-88d9-46aa-be2f-b1d37750047c%40chromium.org.

[Takashi Toyoshima]

Hi, developers.

I need to share the schedule update.

Because of OOR-CORS's impact for enterprise uses, we decided to launch OOR-CORS based on the enterprise-friendly ship process.

This means we will have a "advance notice" period, and "providing a temporary policy escape hatch" period.

Thus, we do not ship it at 77.

At this moment, the most possible plan is starting the"providing a temporary policy escape hatch" period from m79 and finishing

the migration period around m83. We will start announcing more concrete plans in the enterprise release notes from the next time, Chrome 77 notes.

I will send heads-up mail here when we have an important plan change.

You can try the new OOR-CORS implementation with chrome://flags/#out-of-blink-cors at any time to prepare for the coming changes.

Thanks in advance,

[Takashi Toyoshima]

Hi everyone,

Now I announce the finalized plan for the OOR-CORS related webReqest API changes. The API document already reflect this plan.

Here is the excerpt on the coming changes.

Starting from Chrome 79, request header modifications affect Cross-Origin Resource Sharing (CORS) checks. If modified headers for cross-origin requests do not meet the criteria, it will result in sending a CORS preflight to ask the server if such headers can be accepted. If you really need to modify headers in a way to violate the CORS protocol, you need to specify 'extraHeaders' in opt_extraInfoSpec. On the other hand, response header modifications do not work to deceive CORS checks. If you need to deceive the CORS protocol, you also need to specify 'extraHeaders' for the response modifications.

Starting from Chrome 79, the following request header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

• Origin

Note that the current OOR-CORS does not support intercepting CORS preflight request yet. But we will add a support before shipping the feature at m79. That is only the unknown difference between the planned changes at the document, and the actual behavior of m76-78, and Canary 79.

If you find a problem, please file a bug from this link. The OOR-CORS is available from chrome://flags/#out-of-blink-cors at any current versions in all channels.

Thanks

[Takashi Toyoshima]

Sorry, I overlooked this mail.

On Sat, Sep 14, 2019 at 6:57 AM <eric.r...@gmail.com> wrote:

Thank you for the update.

I have a question about not being able to modify the origin header.  I think in Chrome 73 any request from the background.js page would set the Origin: chrome-extension://myextensionid even if the domain was listed in the permissions area of the manifest.  I can't tell if that was on purpose or was a bug because I found a few bug reports about it.  We've had to modify the origin headers using onBeforeSendHeaders because of this issue.

Is this crbug.com/966223? I think the origin does not appear on GET or HEAD. Manifest declaration makes the request assumed as a same-origin request. On the other hand, non-GET/HEAD requests need to have the Origin regardless of cross-origin or same-origin. As a result, e.g. POST request needs to have an Origin. I think sending chrome-extension origin for such case is the intended original behavior.

So my questions is will background.js requests set the origin to the actual domain of the request if the domain is listed in the permissions manifest, and if not how are we expected to make requests on behalf of the user if the origin is not correct?  

Yes, that's exactly what we planned as a future improvement. Please follow the 966223 to track the progress.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/network-service-dev/2ee1399e-aa65-4cd4-9578-705d1387e3a5%40chromium.org.

[Takashi Toyoshima]

Hi everyone,

Now I announce that all planned changes for Chrome 79 were done, and we finished to update webRequest API document to reflect recent changes.

It contains planned OOR-CORS related changes for Chrome 79, and undocumented NetworkService related changes for Chrome 72.

Regarding the CORS preflight interception, we decided to require the extraHeader option since it affects performance.

Here are finalized diffs:

Starting from Chrome 79, request header modifications affect Cross-Origin Resource Sharing (CORS) checks. If modified headers for cross-origin requests do not meet the criteria, it will result in sending a CORS preflight to ask the server if such headers can be accepted. If you really need to modify headers in a way to violate the CORS protocol, you need to specify 'extraHeaders' in opt_extraInfoSpec. On the other hand, response header modifications do not work to deceive CORS checks. If you need to deceive the CORS protocol, you also need to specify 'extraHeaders' for the response modifications.

Starting from Chrome 79, the webRequest API does not intercept CORS preflight requests and responses by default. A CORS preflight for a request URL is visible to an extension if there is a listener with 'extraHeaders' specified in opt_extraInfoSpec for the request URL. onBeforeRequest can also take 'extraHeaders' from Chrome 79.

Starting from Chrome 79, the following request header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

• Origin

Starting from Chrome 72, if you need to modify responses before Cross Origin Read Blocking (CORB) can block the response, you need to specify 'extraHeaders' in opt_extraInfpSpec.

Thanks,

[Takashi Toyoshima]

On Tue, Oct 29, 2019 at 12:49 AM <eric.r...@gmail.com> wrote:

Thank you for the update.

How do we test this upcoming change?

Oh, thanks. That's a good question.

Chrome 79.0.3945.8 or later version contains all planned changes, but need to set chrome://flags/#out-of-blink-cors to Enabled explicitly. Otherwise only 50% users will opt-in for a while.

At this moment, only Canary and Dev have versions that meet this requirement, but the next Beta 79 supporting this is also coming soon.

I should explain it in the previous mail.

Thank you for paying at

tentions.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/network-service-dev/cecda8e6-7a0f-459c-8c04-be7ab081b541%40chromium.org.

[Takashi Toyoshima]

+Łukasz Anforowicz since the error message is for CORB.

On Sat, Nov 2, 2019 at 7:02 AM 'Hansen Qian' via network-service-dev <network-s...@chromium.org> wrote:

Hello everyone!

We currently have two chrome extensions (dmgfneofbepinecipidiiogfamkfgjon and mnfkepfkbemjhmpijcepabfhkldegbga) that make cross-origin network requests from a content script (ie. when a user is visiting 8vc.com, the content script will make a $.ajax/XMLHttpRequest to affinity.co). We do not modify any requests that 8vc.com makes, and these two extensions do not have the webRequest or webRequestBlocking chrome extension permission. We were under the impression that since we did not use the webRequest API and that our two extensions are on the CORS whitelist (see https://bugs.chromium.org/p/chromium/issues/detail?id=935705 and https://bugs.chromium.org/p/chromium/issues/detail?id=935707), that we would not be susceptible to this change.

When Chrome Beta v79 was released earlier this week, our users on Chrome Beta started reporting that they were unable to use our chrome extension (we've confirmed that it still works in v78). We're currently debugging this issue and have been getting the following error message in the console, when making requests from our content script in v79:

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://affinity.affinity.co/api/delibird with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.

However, we're having trouble isolating this issue because when we explicitly set the flag chrome://flags/#out-of-blink-cors to Disabled in v79, the issue persists. 

What's also confusing is that when we try to reproduce the issue in Chrome Canary (v80), explicitly set the flag chrome://flags/#out-of-blink-cors to Enabled, our extension behaves as intended. 

Would you happen to know whether the issue we're currently debugging is related to this OOR-CORS change? Or if there are any other v79 updates that might be causing this issue?

Best,

Hansen

On Monday, October 28, 2019 at 10:31:29 PM UTC-7, Takashi Toyoshima wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/network-service-dev/f5f3399e-0db8-49db-b3d3-1a520da2854b%40chromium.org.

[Takashi Toyoshima]

cc: lukasza for double checking on CORB

cc: yhirano for extensions' POST Origin change.

On Tue, Nov 5, 2019 at 1:41 AM <eric.r...@gmail.com> wrote:

Thank you. I'm testing chrome beta 79.0.3945.16

Our extension (mhkhmbddkmdggbhaaaodilponhnccicb) does some cross-domain calls.  We moved all of our content script ajax calls the background.js to meet Cross-Origin Read Blocking (CORB) requirements.  In doing that we noticed requests origin headers were set to Origin: chrome-extension://myexensionid, which broke the calls.  We had to implement onBeforeSendHeaders.addListener to correct the Origin header.

My understanding was that if the manifest had permissions for the cross-domain target that the Origin header would not be set to Origin: chrome-extension://myexensionid, but the actual domain target.  

Reference 

https://bugs.chromium.org/p/chromium/issues/detail?id=966223#c17

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/AlpwfYIy25A

Can someone please shed some light on this issue?  Between the CORB changes, manifest v3, and background.js changes it's becoming very difficult to keep track of upcoming issues.

Thank you for the required change for CORB, and yes, unfortunately requests from the background.js will have the Origin chrome-extension://... if the method is POST.

See crbug.com/966223 for the background details. When an extension has a permission for the origin specified in the manist, request to the origin is assumed as a same-origin request. That results in not having the Origin header in the GET request, and does not perform CORS checks for the response. But for the POST case, HTTP requires to have the Origin header regardless of same-origin or cross-origin. So, we are sending chrome-extension:// as the Origin header intentionally.

Since some developers want to change this behavior, we are making a change to set the target origin to the Origin header. It will be introduced at m80.

It's unfortunate that we could not have this at the same m79. But OOR-CORS itself is a large change, and POST Origin header change is a compatibility breaking change. So we do not want to introduce both together.

 

On Monday, October 28, 2019 at 10:31:12 PM UTC-7, Takashi Toyoshima wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/dee2971d-3999-4f71-82d0-61d0ca1e4f71%40chromium.org.

[Takashi Toyoshima]

Heads-up, and detailed rollout plan is here!

As I announced, OOR-CORS will be rolled out at Chrome 79, and relevant Chrome Extensions' changes will start affecting.

But, we won't enable it by default from the first release date. This is because the Chrome 79 will be releasing around the holiday season and it may have a large impact for enterprise and education users.

We will automatically enable the OOR-CORS feature step by step from Jan/6/2020, and it will take a few weeks for everyone to have this feature enabled by default.

So, please don't panic even if you are seeing the legacy behaviors even in Chrome 79 at the first release date. If you want to try new behaviors from the first date to make sure your Extensions work as you expect, you can enable the feature manually by setting chrome://flags/#out-of-blink-cors to be Enabled.

Thanks in advance,