Intent to Implement and Ship: CSS: Use the response URL for base URL and response type for security decisions

[Matt Falkenhagen]

Contact emails

fal...@chromium.org, yhi...@chromium.org

Explainer

None: this is a minor change to an existing feature.

Design doc/Spec

The relevant specs are CSSOM, Fetch, and HTML. Specifically, see Fetch #146, #737, and #834.

The TAG review is being skipped because this is a minor change that doesn’t require review.

Summary

This changes the behavior of stylesheets in certain cases. There are three changes included in this intent:

Change #1:

Use the response URL rather than the last request URL as the base URL of the stylesheet. This aligns with the standard. See https://github.com/whatwg/fetch/pull/146. WPT results indicate Firefox, Edge, and Safari use the response URL. This only matters if the response came from a service worker, as the URLs only differ when the service worker intercepts the request and responds with a different URL via respondWith(fetch(other_url)).

This is covered by the WPT:

service-workers/service-worker/fetch-request-css-base-url.https.html

Change #2:

Consider A->B->A redirects, which redirect from cross-origin back to same-origin, to be cross-origin. Chrome and Firefox currently consider A->B->A to be same-origin. Discussion at https://github.com/whatwg/fetch/issues/737 is in favor of changing this to be cross-origin, and Chrome already changed it to be cross-origin for resource types other than stylesheets.

This is covered by the WPT:

css/cssom/stylesheet-same-origin.sub.html

Change #3:

Consider stylesheets that failed to load to be cross-origin. That is, accessing |styleSheet.rules| throws a SecurityError if the load failed. This aligns with the specification:

cssRules checks the `origin-clean` flag:

https://drafts.csswg.org/cssom/#dom-cssstylesheet-cssrules

This is set to true iff CORS-same-origin:

https://html.spec.whatwg.org/multipage/links.html#link-type-stylesheet

CORS-same-origin is false for “error” responses:

https://html.spec.whatwg.org/multipage/urls-and-fetching.html#cors-same-origin

Chrome and Firefox currently consider this to be same-origin if the request was same-origin.

This is covered by the WPT:

css/cssom/stylesheet-same-origin.sub.html

It also is covered by http tests when SRI or CSP causes a load to fail:

register-bypassing-scheme-partial.html

require-sri-for-style-blocked.php

Motivation

The primary motivation is to use the response URL as the base URL (Change #1 above) in order to match other implementations and align with the specification. In doing so, I found it convenient to make the other two changes to preserve SOP in our implementation. See the CL at https://chromium-review.googlesource.com/c/chromium/src/+/1367331.

Risks

Interoperability and Compatibility

Change #1 has some compatibility risk because it affects how the base URL is determined, which affects the behavior of stylesheets that request subresources using relative paths. However it has minimal interoperability risk because it aligns with the behavior of other browsers.

Change #2 and #3 have some compatibility and interoperability risk. But I consider the risk low since they are edge cases: A->B->A redirects seem low risk because Chrome already changed that behavior for other resources, and it’s unlikely the change on load failure will meaningfully affect sites.

Edge: Shipped for Change #1, No Signals for #2 and #3

Firefox: Shipped for Change #1, Support for #2, No Signals for #3

Safari: Shipped for Change #1, Support for #2, No Signals for #3

Web / Framework developers: No signals

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

No.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

No.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Yes, service-workers/service-worker/fetch-request-css-base-url.https.html and css/cssom/stylesheet-same-origin.sub.html

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5642183499579392 (needs to be updated to include Change #2 and #3)

Requesting approval to ship?

Yes.

[Daniel Bratell]

#2, about treating A -> B -> A as cross domain, sounds like a risky change. Do you have any indication about how common it is? I could imagine it being triggered by url shortening services and others. I do see the point, where a different site could otherwise replace bank.url/main.css with with bank.url/demo-malicious.css and cause all kind of problems. But how web compatible is it?

#1, seems good to me. So respondWith() different than a redirect?

#3, not sure I understand this one. Why is a network error a security error?

/Daniel

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

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Matt Falkenhagen]

Thanks!

On Tue, Dec 11, 2018 at 10:36 PM Daniel Bratell <bra...@opera.com> wrote:

#2, about treating A -> B -> A as cross domain, sounds like a risky change. Do you have any indication about how common it is? I could imagine it being triggered by url shortening services and others. I do see the point, where a different site could otherwise replace bank.url/main.css with with bank.url/demo-malicious.css and cause all kind of problems. But how web compatible is it?

We don't have metrics, but according to Yutaka's post we've already changed image, script, fetch, media to have this behavior in Chrome 71 and it seems like it's gone okay.

 

#1, seems good to me. So respondWith() different than a redirect?

Correct, it doesn't alter the request URL like a redirect but alters the response URL.

 

#3, not sure I understand this one. Why is a network error a security error?

I'll see if I can find an answer to this. According to the specs, a network error (response type "error") is neither CORS-same-origin nor CORS-cross-origin, and CSS's "origin clean" flag is set iff CORS-same-origin. I'll ask if that was an intentional decision (cc Anne).

[Yutaka Hirano]

On Tue, Dec 11, 2018 at 10:54 PM Matt Falkenhagen <fal...@chromium.org> wrote:

Thanks!

On Tue, Dec 11, 2018 at 10:36 PM Daniel Bratell <bra...@opera.com> wrote:

#2, about treating A -> B -> A as cross domain, sounds like a risky change. Do you have any indication about how common it is? I could imagine it being triggered by url shortening services and others. I do see the point, where a different site could otherwise replace bank.url/main.css with with bank.url/demo-malicious.css and cause all kind of problems. But how web compatible is it?

We don't have metrics, but according to Yutaka's post we've already changed image, script, fetch, media to have this behavior in Chrome 71 and it seems like it's gone okay.

 

Correction: fetch and media has had the behavior for a long time. We changed the behavior for image and script in Chrome 71.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_xCineKeMKMDPj6Z%3DFtvkif%3D30SX%2B_URR0wbEWoyGdEs_A7A%40mail.gmail.com.

[Matt Falkenhagen]

On Tue, Dec 11, 2018 at 10:54 PM Matt Falkenhagen <fal...@chromium.org> wrote:

Thanks!

On Tue, Dec 11, 2018 at 10:36 PM Daniel Bratell <bra...@opera.com> wrote:

#2, about treating A -> B -> A as cross domain, sounds like a risky change. Do you have any indication about how common it is? I could imagine it being triggered by url shortening services and others. I do see the point, where a different site could otherwise replace bank.url/main.css with with bank.url/demo-malicious.css and cause all kind of problems. But how web compatible is it?

We don't have metrics, but according to Yutaka's post we've already changed image, script, fetch, media to have this behavior in Chrome 71 and it seems like it's gone okay.

 

#1, seems good to me. So respondWith() different than a redirect?

Correct, it doesn't alter the request URL like a redirect but alters the response URL.

 

#3, not sure I understand this one. Why is a network error a security error?

I'll see if I can find an answer to this. According to the specs, a network error (response type "error") is neither CORS-same-origin nor CORS-cross-origin, and CSS's "origin clean" flag is set iff CORS-same-origin. I'll ask if that was an intentional decision (cc Anne).

Anne responded on the GitHub issue: https://github.com/whatwg/fetch/issues/848#issuecomment-446249290

[Rick Byers]

Matt, it's only developers writing service workers who might need to be aware of this change, right? And even then, the vast majority of them (perhaps even all) are unlikely to notice any of these three changes, is that right? Are you aware of any sites / shipping code which will break as a result of these changes?

Together these feel somewhere between bug fixes and an intentional breaking change to me, but I don't have the context to have good judgement on where on the spectrum it falls. Certainly we have lots of bug fixes on edge cases in every Chrome release without going through the overhead of breaking change analysis and intent process for every one. If SW experts (you, +Jake, Ben) feel comfortable saying these are tweaks / bug fixes which probably nobody will be hurt by, I'm happy to just try shipping the changes and worst case disable (block on further analysis) at the first sign of any significant breakage in dev/beta.

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_xCikb-McvJaGixOpBSsA7Y4wpLkT_kwBR3yBqzdB%3D-Z7t2Q%40mail.gmail.com.

[Mike West]

I approved the patch before Matt brought it to blink-dev@; it felt like a bug fix to me, and not a large-enough change to run through the intent process.

Given our success at fixing this bug for other resource types, and my impression that there's agreement among folks about the "right" behavior in the specs and tests, I'd LGTM1 this to ship.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-SFQcJVAnOmQW3pgpC-1VtNJihqmkoYrm1oD2mcycYuA%40mail.gmail.com.

[Daniel Bratell]

LGTM2

[Matt Falkenhagen]

Thanks Rick. Yes, my original plan was to simply land this. Mike approved the patch as he mentioned, but it was before Change #2 and #3 were added to the CL (I didn't know at the time they were necessary), and since he had a Gerrit away status I added a new reviewer (Rune) who also approved it but asked about the Intent to Ship. Given that and Yutaka's earlier post about Change #2, I decided to just send the Intent to Ship.

[Matt Falkenhagen]

To answer your questions directly:

On Wed, Dec 12, 2018 at 1:21 AM Rick Byers <rby...@chromium.org> wrote:

Matt, it's only developers writing service workers who might need to be aware of this change, right?

That's definitely correct for Change #1. For #2 and #3, the change is observable without service workers.

 

And even then, the vast majority of them (perhaps even all) are unlikely to notice any of these three changes, is that right?

Agreed.

 

Are you aware of any sites / shipping code which will break as a result of these changes?

No.

[Rick Byers]

Ok, thanks. LGTM3. Just go for it, but let us know if you hit any non-trivial breakage.