W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Re: What constitutes protection [was: About using CORS]

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 4 May 2010 17:09:01 +1200
Message-ID: <g2w11e306601005032209q62d3eff4u16f34b328a595c8b@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: John Hudson <tiro@tiro.com>, Sylvain Galineau <sylvaing@microsoft.com>, www-font@w3.org, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
On Tue, May 4, 2010 at 4:25 PM, Anne van Kesteren <annevk@opera.com> wrote:

> Resending to www-font@w3.org so others can participate more easily. I
> suggest follow-up email is also posted there. The suggestion from John in
> http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Apr/0067.html
> makes perfect sense.


> I explained before that to date we only have had same-origin protection to
> prevent information leakage. This is consistent across XMLHttpRequest,
> <img>, <form>, <video>, <audio>, <script>, <iframe>, etc. While if we
> could do things all over again this would likely have been done
> differently, we cannot. Since there is no information leakage restricting
> requests to be same-origin is uncalled for and inconsistent with the
> design principles that are used for the Web platform.

I don't think it's a "design principle" of the Web platform that "preventing
information leakage" is the only legitimate purpose for same-origin checks.

Using same-origin checks only to prevent information leakage may be "the way
things have been done so far", but calling it a "design principle" makes it
sound like some kind of intentional policy with supporting arguments that it
generally leads to desirable outcomes. I don't believe it. We all know that
it has led to highly undesirable outcomes and if we could do the Web over,
we wouldn't do things this way.

I think all you can say is that imposing a same-origin check when not needed
to control information leakage is inconsistent with past practice for other
resource types. IMHO that's a pretty weak argument if there are good
benefits to be obtained by imposing it.

You raised the idea of sending a "From-Origin" HTTP header with fonts (and
other resources) to instruct the browser not to use the font if the load is
cross-origin --- essentially letting authors opt into a same-origin
restriction, instead having the same-origin restriction be the default and
letting authors opt out of it. I think the same-origin restriction should be
the default for fonts, for several reasons:

-- Probably most authors will not care whether there is a same-origin
restriction or not. For those that do care, probably the majority of authors
will want a same-origin restriction in order to comply with font licensing.

-- Sites that serve fonts to be used by many other sites are likely to be a
small number of large font repositories. It seems better to burden a small
number of large sites with responsibility for sending special headers, than
to burden a larger number of smaller sites.

-- If the From-Origin header is stripped en route, for example by a
firewall, the browser will use fonts against the will of the site serving
the fonts. On the other hand if Access-Control-Allow-Origin is stripped, the
browser will simply not use the font. The latter seems less obnoxious.

I would also like to observe that when we proposed imposing a same-origin
restriction on loading videos there was a huge author outcry and we backed
away from it. On the other hand we have implemented and shipped same-origin
restrictions for fonts in Firefox and there has been no author outcry at
all. This is evidence that different resource types are, in fact, subject to
different expectations and can be treated differently.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
Received on Tuesday, 4 May 2010 05:09:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC