- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 16 Feb 2011 13:05:19 -0800
- To: Tab Atkins <tabatkins@google.com>
- Cc: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>, Sylvain Galineau <sylvaing@microsoft.com>, Håkon Wium Lie <howcome@opera.com>, John Daggett <jdaggett@mozilla.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, Anne van Kesteren <annevk@opera.com>
On Feb 16, 2011, at 12:54 PM, Tab Atkins wrote: > On Wed, Feb 16, 2011 at 12:39 PM, Levantovsky, Vladimir > <Vladimir.Levantovsky@monotypeimaging.com> wrote: >> On Wednesday, February 16, 2011 2:32 PM Maciej Stachowiak wrote: >>> >>> Previously, it was argued that CORS to opt into sharing is a low >>> burden, since adding a fixed request header is much easier than >>> checking an incoming response header. If it is indeed easy for content >>> authors to add fixed response headers (and I do believe that is the >>> case), then it is not an undue burden to do this to restrict font >>> hotlinking. >> >> I guess we should also take into consideration how often something would have to be done, and the level of knowledge and skills of the person doing it. I agree that adding a fixed response header would be considered a low burden for a small number of professional, highly-skilled web developers who may have a need to relax SOR restriction. However, requiring the same to be done by *everyone* to put SOR in place seems like a much higher burden. > > FWIW, I'm planning to add 'From-Origin' support to Webkit this week or > next, and make it so that if no From-Origin header was sent in > response to a @font-face request the effect is as if > 'From-Origin:same' had been sent. > > (I'll do the second in such a way that Safari can turn it off if they > want, at least until we have consensus.) Can we wait until we have consensus on the name of the header and the restriction model before rushing to implement? Thanks, Maciej
Received on Wednesday, 16 February 2011 22:23:03 UTC