RE: SOR: CORS or From-Origin?

I believe that bandwidth savings and, more importantly, the end-user security were the primary consideration for implementing SOR for fonts, regardless of the file format served. As far as the security is concerned, we’ve already seen what font exploits are capable of: http://news.cnet.com/8301-31021_3-20012511-260.html. The fact that SOR also helps authors satisfy font license requirements without actually doing any work is just a happy coincidence that both authors and font vendors like very much.

The solution you propose would not protect authors from bandwidth leak since a font would always have to be downloaded first, its content would have to be analyzed to determine special bit settings. As proposed, it would be WOFF-specific solution – currently SOR is applied for any font resource downloaded via @font-face. Plus, having a special bit set that browsers have to check and act accordingly would be similar to how EOT embedding restrictions work, which was also wildly opposed.

Regards,
Vlad


From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-request@w3.org] On Behalf Of Behdad Esfahbod
Sent: Thursday, February 10, 2011 5:25 PM
To: Tab Atkins
Cc: liam@w3.org; public-webfonts-wg@w3.org
Subject: Re: SOR: CORS or From-Origin?

On Thu, Feb 10, 2011 at 5:20 PM, Tab Atkins <tabatkins@google.com<mailto:tabatkins@google.com>> wrote:
On Thu, Feb 10, 2011 at 2:17 PM, Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>> wrote:
> On Thu, Feb 10, 2011 at 5:05 PM, Tab Atkins <tabatkins@google.com<mailto:tabatkins@google.com>> wrote:
>> On Thu, Feb 10, 2011 at 1:51 PM, Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>>
>> wrote:
>> > On Thu, Feb 10, 2011 at 4:32 PM, Liam R E Quin <liam@w3.org<mailto:liam@w3.org>> wrote:
>> >>
>> >> On Thu, 2011-02-10 at 16:16 -0500, Behdad Esfahbod wrote:
>> >> > Given the discussion going on, I wonder, has it been considered to
>> >> > include a
>> >> > SOR flag in the WOFF file itself?
>> >>
>> >> By the time you've got the font in order to check the flag, it's too
>> >> late for the server to refuse to send it, no?
>> >
>> > No.  This is exactly like the current proposed SOR, which is also
>> > client-side.  This is not about the server refusing to serve.  You can
>> > always download the font using "wget", and the current SOR mechanism
>> > would
>> > help there either.  It's about the font not working on other people's
>> > website.
>>
>> You must be misunderstanding something in the proposal, because you're
>> incorrect here.
>
> Ok, let me correct myself: what I propose is *functionally* equivalent to
> the current SOR.  In that in both cases, another domain linking to the font
> will NOT work.  In both cases, people can download the font still, because
> SOR does not restrict the server from serving.
Indeed, it's the same in those contexts.  But it doesn't save any
bandwidth for the original author, which is one of the nice benefits
of preventing hot-linking through SOR.  This is a significant
difference.

But if it doesn't work, one would hope that people are not going to use it.

Lets not mix (hypothetical) bandwidth savings with the license requirements.  Reading the thread it looks like the SOR requirement is necessary for license enforcement reasons.

behdad

~TJ