To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Font from origin 'file://' has been blocked from loading by Cross-Origin Resource Sharing policy: Invalid response. Origin 'null' is therefore not allowed access.
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?
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.
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.
LGTM, the impact of this seems pretty limited if it only affects self-referencing resources.
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...☆PhistucKOn 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.
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?
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.
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