Same origin policy for file:// scheme?

[Danyao Wang]

Hi blink-dev,

What is the same origin policy for file:// scheme? I'm trying to figure out whether replaceState and pushState can/should be used in a file scheme, but find little definitive information on this regard:

• WHATWG living spec doesn't mention file in the origin section at all
• An old version of W3C HTML spec from 2011 says it's UA-specific
• Chrome has an exception that tream files of the same path as same-origin in the context of History API, ignoring query and fragment differences: https://codereview.chromium.org/1632513002
• Very old MDN article says Gecko used to consider all file:// URLs same origin, but tightened it in Gecko 1.9. It seems to consider two file:// URLs same origin in context of History API (same as Chrome)
• Safari made all files unique origin by default (even for two identical file:// URLs) in https://trac.webkit.org/changeset/224609/webkit, which is based on this Chromium CL. This will be released in Safari 11.1 (with iOS 11.3 and macOS 10.13.4)

It seems that over time, all browsers are trending towards treating each file document as unique origin. I'd like to learn more about the history and rationale behind this.

I found a bit discussion in http://crbug.com/528681. The conclusion there seems to be that if the location only changes the ref, it's safe. That led to the Chromium exception above. My other question is, why would the exception only be applied to History.cpp instead of more broadly in SecurityOrigin.cpp?

Any comments will be appreciated!

Thanks,

Danyao

[Marijn Kruisselbrink]

On Thu, Feb 22, 2018 at 3:00 PM, Danyao Wang <dan...@chromium.org> wrote:

Hi blink-dev,

What is the same origin policy for file:// scheme? I'm trying to figure out whether replaceState and pushState can/should be used in a file scheme, but find little definitive information on this regard:

It's a mess...

 

• WHATWG living spec doesn't mention file in the origin section at all
• An old version of W3C HTML spec from 2011 says it's UA-specific

The whatwg URL spec (https://url.spec.whatwg.org/#origin) still says it is UA-specific "is left as an exercise to the reader".

 

• Chrome has an exception that tream files of the same path as same-origin in the context of History API, ignoring query and fragment differences: https://codereview.chromium.org/1632513002
• Very old MDN article says Gecko used to consider all file:// URLs same origin, but tightened it in Gecko 1.9. It seems to consider two file:// URLs same origin in context of History API (same as Chrome)
• Safari made all files unique origin by default (even for two identical file:// URLs) in https://trac.webkit.org/changeset/224609/webkit, which is based on this Chromium CL. This will be released in Safari 11.1 (with iOS 11.3 and macOS 10.13.4)

It seems that over time, all browsers are trending towards treating each file document as unique origin. I'd like to learn more about the history and rationale behind this.

I found a bit discussion in http://crbug.com/528681. The conclusion there seems to be that if the location only changes the ref, it's safe. That led to the Chromium exception above. My other question is, why would the exception only be applied to History.cpp instead of more broadly in SecurityOrigin.cpp? 

There is some more discussion around this issue in https://crbug.com/271996, with several attempts to make file:// URLs more like unique origins...

[Daniel Cheng]

Comments inline.

On Thu, Feb 22, 2018 at 5:07 PM Marijn Kruisselbrink <m...@chromium.org> wrote:

On Thu, Feb 22, 2018 at 3:00 PM, Danyao Wang <dan...@chromium.org> wrote:

Hi blink-dev,

What is the same origin policy for file:// scheme? I'm trying to figure out whether replaceState and pushState can/should be used in a file scheme, but find little definitive information on this regard:

It's a mess...

 

• WHATWG living spec doesn't mention file in the origin section at all
• An old version of W3C HTML spec from 2011 says it's UA-specific

The whatwg URL spec (https://url.spec.whatwg.org/#origin) still says it is UA-specific "is left as an exercise to the reader".

 

• Chrome has an exception that tream files of the same path as same-origin in the context of History API, ignoring query and fragment differences: https://codereview.chromium.org/1632513002
• Very old MDN article says Gecko used to consider all file:// URLs same origin, but tightened it in Gecko 1.9. It seems to consider two file:// URLs same origin in context of History API (same as Chrome)
• Safari made all files unique origin by default (even for two identical file:// URLs) in https://trac.webkit.org/changeset/224609/webkit, which is based on this Chromium CL. This will be released in Safari 11.1 (with iOS 11.3 and macOS 10.13.4)

It seems that over time, all browsers are trending towards treating each file document as unique origin. I'd like to learn more about the history and rationale behind this.

The reason is file URLs have been abused for a number of bugs in the past. One of the motivating bugs was https://bugs.chromium.org/p/chromium/issues/detail?id=429542, which is linked to the aforementioned Chromium CL: it turns out that even if two resources have the same file: URL, it's not actually safe to assume they should be same-origin.

 

I found a bit discussion in http://crbug.com/528681. The conclusion there seems to be that if the location only changes the ref, it's safe. That led to the Chromium exception above. My other question is, why would the exception only be applied to History.cpp instead of more broadly in SecurityOrigin.cpp? 

There is some more discussion around this issue in https://crbug.com/271996, with several attempts to make file:// URLs more like unique origins...

+mkwst should confirm, but I don't think we would have made the history exception if it hadn't broken things like jQuery. I suspect that any other exceptions we'll make will be for the same reason: in the original intent thread (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/--KjSROtcMQ), there was concern about making sure that things like localStorage still work. However, looking at the use counters on https://www.chromestatus.com/metrics/feature/popularity, I don't even see the counters for accessing localStorage or sessionStorage from file://... so I'm not even sure that's needed anymore.

Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVYpDR2zHNZZq6g1a_q4TZmHBGCwq3TgO_bdQH6UfH%2Bd%3DA%40mail.gmail.com.

[Ian Clelland]

There are probably WebView use cases for that (hybrid apps which load their UI from file://, for instance) which we'll never see any UMA data for, but may still be important.

Ian

[Daniel Cheng]

Sorry, it wasn't clear, but this was about file:// URLs with respect to the open web: I suspect we'd have to keep a Blink setting around to keep the legacy behavior for Android WebView =/

Daniel 

[Danyao Wang]

These are informative pointers. Thanks everyone!