- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Tue, 4 May 2010 17:09:01 +1200
- 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>
- Message-ID: <g2w11e306601005032209q62d3eff4u16f34b328a595c8b@mail.gmail.com>
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. > Yes! > 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. Rob -- "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 53:5-6]
Received on Tuesday, 4 May 2010 05:09:41 UTC