Intent to Implement and Ship: Treat file:// URLS as having unique origin

[Daniel Cheng]

Contact emails ale...@chromium.org,dch...@chromium.org,mk...@chromium.org Spec https://tools.ietf.org/html/rfc6454#section-4 Summary Similar to sandboxed iframes and data: URLs, treat file:// URLs as having unique origin. Motivation

The rationale behind this proposal is that using a filename as the security principal can be dangerous. There is no guarantee from an OS filesystem that a given filename always points to a unique object.

Compatibility Risk Firefox: No public signals Internet Explorer: No public signals Safari: No public signals Web developers: No signals

Today, this is already an area where behavior varies widely across browsers. The RFC notes that the origin may be an implemention-defined value, and explicitly allows user agents to treat file:// URLs as having globally unique origins.

Internet Explorer: Two file:// URLs are always same origin. Certain operations (like XHRing other files) is forbidden though.

Firefox:

old versions: two file:// URLs are always same origin.

new versions: "a file can read another file only if the parent directory of the originating file is an ancestor directory of the target file. Directories cannot be loaded this way, however." (from https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs)

Safari/Chrome: Two file:// URLs are considered same origin if the path matches.

Describe the degree of compatibility risk you believe this change poses

There will be some visible side effects when opening documents via a file:// URL. For example - a file:// URL will no longer be able to XHR itself - two subframes navigated to the same file:// URL will no longer be able to script each other synchronously.

This could also complicate local development. However, given that Chrome/Safari already considered file:// URLs with different paths to be cross-origin, the compatibility risk should not be particularly high.

Ongoing technical constraints

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

Yes. OWP launch tracking bug https://crbug.com/455882 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5755326842273792 Requesting approval to ship?

Yes.

[Philip Jägenstedt]

LGTM, the impact of this seems pretty limited if it only affects self-referencing resources.

Philip

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

[PhistucK]

What is the migration plan, by the way?

Say, I have a few file:// URLs to which I frequently enter and they store localStorage data. Will I lose the data, or will you copy the initial, formerly global, storage to each origin?

☆PhistucK

[Jochen Eisinger]

LGTM2

[Dimitri Glazkov]

LGTM3

[Rik Cabanier]

This change is causing some problems when trying to read fonts from the local file system.

If we have a font in a subdirectory and the HTML is trying to reference it, we see the following warning on the console:

Font from origin 'file://' has been blocked from loading by Cross-Origin Resource Sharing policy: Invalid response. Origin 'null' is therefore not allowed access. 

Was this an intended change or should I file a bug?

[Kunihiko Sakamoto]

2015-08-12 7:32 GMT+09:00 Rik Cabanier <caba...@gmail.com>:

This change is causing some problems when trying to read fonts from the local file system.

If we have a font in a subdirectory and the HTML is trying to reference it, we see the following warning on the console:

Font from origin 'file://' has been blocked from loading by Cross-Origin Resource Sharing policy: Invalid response. Origin 'null' is therefore not allowed access. 

Was this an intended change or should I file a bug?

That was not an intended change. The tracking bug is here: https://code.google.com/p/chromium/issues/detail?id=517819

[Domenic Denicola]

[+annevk]

From: ksak...@google.com [mailto:ksak...@google.com] On Behalf Of Kunihiko Sakamoto

> That was not an intended change. The tracking bug is here: https://code.google.com/p/chromium/issues/detail?id=517819

I am very confused by this (and by the bug contents and resulting CL). Straightforwardly, this should have been an intended change: font resources are subject to CORS, as they can cause information leakage. File URLs are being made cross-origin to each other, so you should not be able to load a font from them. This seems like solid logic, backed by good security concerns: imagine e.g. a clever way of using the errors generated by `src: url("../../../../../../../../etc/passwd")` in a @font-face declaration. (Note: let's not nitpick the attack I thought up in 30 seconds; I'm sure cleverer/eviler people can find better ones.)

However, https://src.chromium.org/viewvc/blink?view=revision&revision=200313 reverts the change (for fonts, by making them no longer use CORS), calling it a regression. I don't see why this is more a regression for fonts than it is for XHRs. And the rationale is very troubling as well: "Since this broke a common way of testing content locally..." If the goal is to allow local content testing from file:, then the whole program of making file URLs cross-origin is doomed, as you're breaking XHR/Fetch/everything else that respects CORS.

I think we should revert 200313 and continue to block font loading. The spec is very clear that if file URLs are considered cross-origin, then fonts should be blocked; turning off CORS for file URL requests made in a web font context seems like a bad exception to add to the platform, and a potential insecurity vector.

[Rik Cabanier]

On Sun, Aug 16, 2015 at 6:29 AM, Domenic Denicola <d...@domenic.me> wrote:

[+annevk]

From: ksak...@google.com [mailto:ksak...@google.com] On Behalf Of Kunihiko Sakamoto

> That was not an intended change. The tracking bug is here: https://code.google.com/p/chromium/issues/detail?id=517819

I am very confused by this (and by the bug contents and resulting CL). Straightforwardly, this should have been an intended change: font resources are subject to CORS, as they can cause information leakage. File URLs are being made cross-origin to each other, so you should not be able to load a font from them. This seems like solid logic, backed by good security concerns: imagine e.g. a clever way of using the errors generated by `src: url("../../../../../../../../etc/passwd")` in a @font-face declaration. (Note: let's not nitpick the attack I thought up in 30 seconds; I'm sure cleverer/eviler people can find better ones.)

How would that be different from script or an image source? Hopefully Chrome's font engine is secure enough that such attacks are safe.

AFAIK this policy only exists for font licensing.

 

However, https://src.chromium.org/viewvc/blink?view=revision&revision=200313 reverts the change (for fonts, by making them no longer use CORS), calling it a regression. I don't see why this is more a regression for fonts than it is for XHRs. And the rationale is very troubling as well: "Since this broke a common way of testing content locally..." If the goal is to allow local content testing from file:, then the whole program of making file URLs cross-origin is doomed, as you're breaking XHR/Fetch/everything else that respects CORS.

There are a lot of authors that are loading fonts this way including Google (per the bug), Android apps and authoring tools.  

 

I think we should revert 200313 and continue to block font loading. The spec is very clear that if file URLs are considered cross-origin, then fonts should be blocked; turning off CORS for file URL requests made in a web font context seems like a bad exception to add to the platform, and a potential insecurity vector.

The bug I saw was that font were no longer loaded from file even though the page was also loaded from file.

I tried to find the spec that says that this should not be allowed, but got lost in hard to read documents such as fetch, cors, csp, etc.

Can you point out where this is defined?

[Domenic Denicola]

From: Rik Cabanier [mailto:caba...@gmail.com]

> The bug I saw was that font were no longer loaded from file even though the page was also loaded from file.
> I tried to find the spec that says that this should not be allowed, but got lost in hard to read documents such as fetch, cors, csp, etc.
> Can you point out where this is defined?

CSS Fonts is very clear that CORS fetch is applied.

Fetch is very clear that CORS fetches need the header for cross-origin fetches. It's also clear, I hope, that you cannot apply headers to fetches to file URLs.

What is not clear from the specs is whether two file URLs are same-origin. This is currently awaiting browser vendor decision.

However, Blink has decided in favor of making all file URLs different-origin. So with this as the premise, and the former two as lemmas, it falls out that all font loads from files should always fail, similar to all XHR loads from files.

[Rik Cabanier]

On Sun, Aug 16, 2015 at 8:51 PM, Domenic Denicola <d...@domenic.me> wrote:

From: Rik Cabanier [mailto:caba...@gmail.com]

> The bug I saw was that font were no longer loaded from file even though the page was also loaded from file.
> I tried to find the spec that says that this should not be allowed, but got lost in hard to read documents such as fetch, cors, csp, etc.
> Can you point out where this is defined?

CSS Fonts is very clear that CORS fetch is applied.

yes: http://www.w3.org/TR/css3-fonts/#font-fetching-requirements

 

Fetch is very clear that CORS fetches need the header for cross-origin fetches. It's also clear, I hope, that you cannot apply headers to fetches to file URLs.

What is not clear from the specs is whether two file URLs are same-origin. This is currently awaiting browser vendor decision.

However, Blink has decided in favor of making all file URLs different-origin. So with this as the premise, and the former two as lemmas, it falls out that all font loads from files should always fail, similar to all XHR loads from files.

Sure, I think everyone agreed that an XHR to your local file system is bad. 

However, people didn't realize that this was going to impact fonts (and maybe other commonly used features?).

For instance the lgtm from Philip:

LGTM, the impact of this seems pretty limited if it only affects self-referencing resources.

It's clear that not all information was known when this decision was made by the owners. The intent to ship doesn't mention it and the implementers reverted their patch when they realized its impact.

At the very least, there should be an exception that font loads are allowed from the local file system.

[Anne van Kesteren]

On Mon, Aug 17, 2015 at 4:20 AM, Rik Cabanier <caba...@gmail.com> wrote:
> How would that be different from script or an image source? Hopefully
> Chrome's font engine is secure enough that such attacks are safe.
> AFAIK this policy only exists for font licensing.

Actually, no. Fonts leak way more bits of data than images or video.
If the problem here is web development, we should really make it
easier for developers to load files from http://localhost/ or
something similar. File URLs have all kinds of quirks that won't help.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

In the original compat section was "a file:// URL will no longer be able to XHR itself" but it sounds like there isn't actually anything special about self-referencing resources here, as no file:// URL will be able to XHR any other file:// URL, right?

[Jochen Eisinger]

I agree that file:// access for testing purposes should not be a reason to disable CORS - we have command line flags that developers can use for that.

For the Android/WebView case, I think the way to go is to convert the font resources to data urls and load them that way. Since the WebView can be used to display arbitrary web content, we shouldn't add exceptions that allow for loading file:// URLs.

[PhistucK]

While you should not, there is the backwards compatibility issue. How can you tell how many applications rely on this hack?

Does WebView have use counters?

So you may be breaking Android 5 applications that use WebView. This is a problem...

☆PhistucK

[Torne (Richard Coles)]

Various replies inline:

On Mon, 17 Aug 2015 at 11:41 PhistucK <phis...@gmail.com> wrote:

While you should not, there is the backwards compatibility issue. How can you tell how many applications rely on this hack?

A large number of webview apps rely completely on file:// URLs, unfortunately, because the easiest way to put static web content into the app is to store it in the APK as an asset, which WebView exposes under the virtual URL file://android_assets/ - so file:// usage is *much* higher on webview.

 

Does WebView have use counters?

Not currently.

 

So you may be breaking Android 5 applications that use WebView. This is a problem...

☆PhistucK

On Mon, Aug 17, 2015 at 11:57 AM, Jochen Eisinger <joc...@chromium.org> wrote:

I agree that file:// access for testing purposes should not be a reason to disable CORS - we have command line flags that developers can use for that.

For the Android/WebView case, I think the way to go is to convert the font resources to data urls and load them that way. Since the WebView can be used to display arbitrary web content, we shouldn't add exceptions that allow for loading file:// URLs.

This is probably a significant compatibility risk.

 

On Mon, Aug 17, 2015 at 10:55 AM Philip Jägenstedt <phi...@opera.com> wrote:

In the original compat section was "a file:// URL will no longer be able to XHR itself" but it sounds like there isn't actually anything special about self-referencing resources here, as no file:// URL will be able to XHR any other file:// URL, right?

The issue with webfonts is nothing to do with this change in this thread at all; it's just a coincidence that it happened around the same time. The change that broke loading webfonts from file:// URLs was https://codereview.chromium.org/1250793008 which was about fixing a bug with how webfonts handles CORS in cases that involve redirection - it *inadvertantly* also fixed an inconsistency where webfonts were allowed to be used between file:// URLs even though the normal CORS rules should already have prevented this (this should have been prevented back in whichever chrome release made webfonts respect CORS, which was a long time ago, but did not because of this inconsistency in the webfonts code).

The change to make self-referencing file:// links no longer same-origin (i.e. the subject of this thread) is not related at all :)

So talking about the "decision" here is somewhat confusing. At the time CORS was enforced for webfonts it did not impact file:// URLs but it seems like nobody was aware of that and it was a bug/oversight, which got accidentally fixed recently while addressing some other problem.

[Rik Cabanier]

On Mon, Aug 17, 2015 at 12:47 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Mon, Aug 17, 2015 at 4:20 AM, Rik Cabanier <caba...@gmail.com> wrote:
> How would that be different from script or an image source? Hopefully
> Chrome's font engine is secure enough that such attacks are safe.
> AFAIK this policy only exists for font licensing.

Actually, no. Fonts leak way more bits of data than images or video.

Can you explain why they leak more information? Or, more specifically, how would CORS help to stop the leakage?

CORS for webfonts was always about licensing; not security.

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Also https://lists.w3.org/Archives/Public/www-style/2011Jun/0500.html:

Crucially, it avoided any notion of DRM, while providing what was variously
characterised as a 'garden fence' or 'bulkhead' in terms of some very
minimal mechanisms to protect fonts from casual or ignorant unlicensed
use

[Anne van Kesteren]

On Mon, Aug 17, 2015 at 6:43 PM, Rik Cabanier <caba...@gmail.com> wrote:
> Can you explain why they leak more information?

Font metrics.

> Or, more specifically, how
> would CORS help to stop the leakage?

By requiring the other origin to opt into sharing the font and its details.

> CORS for webfonts was always about licensing; not security.

It's not black-and-white.


--
https://annevankesteren.nl/