Honoring the CSS Fonts spec same-origin directive?

[Tab Atkins Jr.]

The CSS Fonts spec defines that @font-face rules must be
same-origin-restricted, with CORS used to loosen the origin rules.
Mozilla and Opera have honored this for a long time (I'm unsure of
IE), but WebKit has always ignored it.

Last time I tried to get us to change to honoring it, my attempt was
shot down by several Apple engineers. Now that we're split, I'm
wondering if we could revisit this decision, and apply SOR as the spec
requires.

A relevant Mozilla bug with discussion on the issue is
<https://bugzilla.mozilla.org/show_bug.cgi?id=604421>. Note in
particular the comments at the end from Boris.

Thoughts?

~TJ

[Dimitri Glazkov]

What's the compat impact of this change?

:DG<

[Tab Atkins Jr.]

On Sat, Apr 13, 2013 at 11:59 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:
> What's the compat impact of this change?

Unsure, but I suspect smaller than some might think.

The fact that Moz applies SOR means that all font-serving services
must already be sending appropriate CORS headers, or else the fonts
wouldn't work. Same with any individual sites that shard font
resources across non-SO origins, and expect their sites to work on
Moz.

The only compat impact I imagine we'd run into would be small
mobile-only sites that optimized for WebKit-only, that use @font-face
to point to fonts they serve themselves out of a CDN that doesn't
specialize in fonts, and so doesn't send CORS headers. This group is
definitely non-zero, but I'd offhand expect it to be not large.

~TJ

[Tab Atkins Jr.]

And, of course, ultimately it's just a font. If a site is relying on
us not to apply SOR, then when we do, it'll just get a fallback font
instead. Reasonably-designed sites already use font fallback to deal
with this kind of thing, and for ones that don't, the site'll just be
slightly less pretty.

Very little, if any, will "break" - the only breakage would be if they
were strongly relying on the font metrics for sizing to work out, and
the fallback font is sufficiently different to make something overflow
when they didn't expect it to do so, and their layout is sufficiently
fragile that this messes something up. Modern layout techniques tend
to be reasonably robust to these kinds of things anyway (and again,
decently-designed sites accept the possibility of someone using
font-size boosting, which'll have a worse effect).

~TJ

[PhistucK]

People have been encoraging using fonts for icons and other graphics.

A website that uses this method and ignores the cross origin restriction can be much less comprehensible after this change.

I guess we need some statistics, actual numbers... otherwise any decision on the matter is really based on a hunch and nothing more (which is bad, of course).

With that said, I support this change anyway. Sometimes violations must be fixed, which in turn breaks little features and the developers would just have to re-code according to the standard, which, in this case, seems to have a very reasonable restriction.

If we want to minimize the (yet unknown) breakage, we can restirct WOFF fonts and leave others intact. WOFF is a relatively new thing and if developers have been using it, I would expect them to adhere to this restriction.

But I do not think we should do that.

☆PhistucK

[Tab Atkins Jr.]

On Sat, Apr 13, 2013 at 12:35 PM, PhistucK <phis...@gmail.com> wrote:
> People have been encoraging using fonts for icons and other graphics.
> A website that uses this method and ignores the cross origin restriction can
> be much less comprehensible after this change.

Yes, but as I said, this would only happen to sites that are *already*
broken in Firefox.

(Plus, good icon fonts use ligatures for their icons, so in the
absence of the font you still get a usable word in the fallback font.
See, for example, Stately <http://intridea.github.io/stately/>, which
uses the state abbreviations as ligatures for the state glyphs. This
is far from a universal practice, but it's reasonable common.)

> I guess we need some statistics, actual numbers... otherwise any decision on
> the matter is really based on a hunch and nothing more (which is bad, of
> course).
>
> With that said, I support this change anyway. Sometimes violations must be
> fixed, which in turn breaks little features and the developers would just
> have to re-code according to the standard, which, in this case, seems to
> have a very reasonable restriction.
>
> If we want to minimize the (yet unknown) breakage, we can restirct WOFF
> fonts and leave others intact. WOFF is a relatively new thing and if
> developers have been using it, I would expect them to adhere to this
> restriction.
> But I do not think we should do that.

Agreed - this idea has been floated in the past, and seems to be very
unattractive. It requires weird contortions in the loader that nobody
wants.

~TJ

[Adam Barth]

Perhaps we should start by using FeatureObserver to see how often we'd block a font load with this change.

Adam

[Eric Seidel]

I don't have a lot of worry about this change. You noted Apple
engineers previously expressed concerns about this change? I'd be
interested to see the bug link if you have it.

If we have evidence that IE (in addition to FF) already does this than
this is a no-brainer. LGTM.

If IE does not respect CORS for Font loads then I think this has a
small, but real, compatibility risk. In that case I would suggest we
do a bit more investigation before taking this risk, e.g. add a
feature FeatureObserver like Adam suggested.

[Masataka Yakura]

On Sun, Apr 14, 2013 at 10:49 AM, Eric Seidel <ese...@chromium.org> wrote:

I don't have a lot of worry about this change.  You noted Apple
engineers previously expressed concerns about this change?  I'd be
interested to see the bug link if you have it.

It was discussed on webkit-dev.

https://lists.webkit.org/pipermail/webkit-dev/2011-January/thread.html#15790

 

If we have evidence that IE (in addition to FF) already does this than
this is a no-brainer.  LGTM.

Last time I tested with IE9 it blocked cross-origin font loading.

http://msdn.microsoft.com/library/gg699339.aspx says “Internet Explorer 9 only accepts relative links to font resources by default. To use fonts from a different domain, the server on which the fonts reside must send access control headers” so I believe IE does require CORS for cross-origin web fonts.

--
Masataka Yakura
<myaku...@gmail.com>

[Eric Seidel]

After reading the WebKit thread, I feel that I don't have context to
advise this decision well enough, and would retract my former LGTM.

The argument that we're the odd-man-out is a strong one. But it's not
clear to me what is/isn't restricted by CORS and if WebFonts is just
the odd man out here. I clearly need to learn more about CORS.

I'll do some more research.

[Masataka Yakura]

Ah, I remember that there were discussions in WebFonts WG too.

http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Jan/thread.html#msg15

http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/thread.html#msg26

And Maciej sent a message to clarify his thoughts on web fonts and cross-origin restriction.

http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0066.html

sidenotes:

* at that time SOR was defined in the WOFF spec, not the CSS Fonts spec)

* Anne objected using CORS for fonts and tried to standardize a response header called From-Origin, which ended up as a W3C Note http://www.w3.org/TR/from-origin/

[PhistucK]

After going through the posted threads, I can also see the rationale for not restricting. So while I think the specification should be changed, we (or others) should still end up matching its instruction.

☆PhistucK

[Tab Atkins Jr.]

On Sat, Apr 13, 2013 at 10:19 PM, Eric Seidel <ese...@chromium.org> wrote:
> After reading the WebKit thread, I feel that I don't have context to
> advise this decision well enough, and would retract my former LGTM.
>
> The argument that we're the odd-man-out is a strong one. But it's not
> clear to me what is/isn't restricted by CORS and if WebFonts is just
> the odd man out here. I clearly need to learn more about CORS.
>
> I'll do some more research.

You want to also read some context from Roc
<http://robert.ocallahan.org/2011/02/distinguishing-versus-web-resources_02.html>,
where he argues that SOR is all about wiping out the distinction
between "embedding" versus "viewing", because in practice there *is*
no distinction - anything that can be embedded can eventually be read.

We have a lot of legacy types that we can't SOR. We *tried* with
<video>/<audio>, but barely missed the timing boat, with not quite
enough people recognizing the value in time (and I suspect that
WebKit's mild hostility to it from some Apple engineers didn't help).
But the ideal is, from now on, you *always* SOR by default when you
introduce a new type of linking. It's just the right thing to do,
because it lets us avoid having to care about a whole annoying class
of security issues.

For example, you've hopefully heard about the timing-channel attacks
that mean merely tainting a canvas with a cross-origin image painted
into it isn't enough. You can do the same thing with fonts, and
actually recover pixelated outlines in a reasonable amount of time.
(I've seen it live - you can hit a 10x10 grid fairly instantaneously.)
If cross-origin fonts are SOR, and have to be freed up explicitly
with CORS, though, then everything's fine!

This should be the new reality. Old media types distinguish between
"reading" and "embedding", with only the latter allowed for
cross-origin things. But in reality, there's only "reading" and
"reading, with somewhat more difficulty", and we, the browser
developers, have to work very hard to keep that "somewhat more" as
high as possible. If we just wipe out the category altogether, and
block cross-origin from being used at all, we get to avoid a lot of
annoying effort that's ultimately futile anyway.

~TJ

[John Daggett]

Masataka Yakura wrote:

> > I don't have a lot of worry about this change. You noted Apple
> > engineers previously expressed concerns about this change? I'd be
> > interested to see the bug link if you have it.
>
> It was discussed on webkit-dev.
> https://lists.webkit.org/pipermail/webkit-dev/2011-January/thread.html#15790

The discussion in early 2011 on the Webkit list regarding the same
origin restriction on fonts predates the discussion and resolution of
this topic at the W3C TPAC meeting in fall 2011. In a joint meeting
of the CSS and Webapps working groups it was resolved, with Apple
representatives present, to require a same-origin restriction for
fonts [1], [2]. I don't think they were terribly happy with the
resolution but they did tacitly agree not to object.

Masa, I seem to recall you were there, no? It was a big meeting I
guess, maybe I'm not recalling correctly... ;)

IE9+ applies the same origin restriction, with CORS to relax, to font
loading of TrueType/WOFF fonts. EOT loading is based on older code
which predates the CSS3 Fonts spec and doesn't apply the same origin
restriction.

I think you'd need to ping Maciej or Ted to find out what their
current thinking is but I'm guessing the Apple folks are just going to
ignore this rather than object to it being in the spec.

Cheers,

John Daggett
CSS3 Fonts editor

[1] http://lists.w3.org/Archives/Public/www-style/2011Nov/0711.html
[2] http://www.w3.org/2011/10/31-webapps-minutes.html#item02

[Masataka Yakura]

On Mon, Apr 15, 2013 at 8:53 AM, John Daggett <jdag...@mozilla.com> wrote:

Masataka Yakura wrote:

> > I don't have a lot of worry about this change. You noted Apple
> > engineers previously expressed concerns about this change? I'd be
> > interested to see the bug link if you have it.
>
> It was discussed on webkit-dev.
> https://lists.webkit.org/pipermail/webkit-dev/2011-January/thread.html#15790

The discussion in early 2011 on the Webkit list regarding the same
origin restriction on fonts predates the discussion and resolution of
this topic at the W3C TPAC meeting in fall 2011.  In a joint meeting
of the CSS and Webapps working groups it was resolved, with Apple
representatives present, to require a same-origin restriction for
fonts [1], [2].  I don't think they were terribly happy with the
resolution but they did tacitly agree not to object.

Masa, I seem to recall you were there, no?  It was a big meeting I
guess, maybe I'm not recalling correctly... ;)

Yes I was there. I just forgot to point the TPAC minutes in my previous message. My apologies.

 

IE9+ applies the same origin restriction, with CORS to relax, to font
loading of TrueType/WOFF fonts.  EOT loading is based on older code
which predates the CSS3 Fonts spec and doesn't apply the same origin
restriction.

I think you'd need to ping Maciej or Ted to find out what their
current thinking is but I'm guessing the Apple folks are just going to
ignore this rather than object to it being in the spec.

Cheers,

John Daggett
CSS3 Fonts editor

[1] http://lists.w3.org/Archives/Public/www-style/2011Nov/0711.html
[2] http://www.w3.org/2011/10/31-webapps-minutes.html#item02

--
Masataka Yakura
<myaku...@gmail.com>