W3C home > Mailing lists > Public > www-style@w3.org > June 2009

Re: New work on fonts at W3C

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 22 Jun 2009 07:43:46 -0700
Cc: "www-style@w3.org" <www-style@w3.org>, whatwg@whatwg.org
Message-Id: <CAB18951-4B60-408C-A65F-219241B11711@gmail.com>
To: Mikko Rantalainen <mikko.rantalainen@peda.net>

On Jun 22, 2009, at 4:12 AM, Mikko Rantalainen wrote:

> Anne van Kesteren wrote:
>> On Sat, 20 Jun 2009 17:07:06 +0200, Brad Kemper <brad.kemper@gmail.com 
>> >
>> wrote:
>>> I didn't mean it should be restricted by default. Just that CORS  
>>> could
>>> restrict it like anything else if you told it to. And that the font
>>> could instruct the CORS mechanism.
>>
>> That's not how CORS works. CORS is not about restricting at all. It  
>> is
>> about lifting cross-origin restrictions if any are present. If  
>> there are
>> no restrictions to start with (which I think makes sense for  
>> consistency
>> as I pointed out though it seems not everyone agrees) CORS cannot  
>> impose
>> any.
>
> Perhaps CORS could further defined to use following rules:
>
> 1) without CORS same-origin restrictions may or may not apply  
> depending
> on the resource type or user agent (with XHR it does apply, with IMG  
> SRC
> attribute it does not apply)
>
> 2) with CORS, the same-origin restrictions always apply and in  
> addition
> to same-origin, any entity listed in CORS may use the resource
>
> This way CORS could be expanded to apply to XML, CSS, images, videos  
> and
> font files.
>
> This would change to status of CORS somewhat - it would still only  
> allow
> lifting cross-origin restrictions but a mere presence of it would
> suggest to user agent that same-origin checks should be done.
>
> If enough user agents started following the hints given with CORS it
> could be used as a pseudo-restriction (I would consider this a label  
> and
> fence as used in this font discussion.)

This makes sense to me. I was surprised and found it counter-intuitive  
to learn that CORS could be used to list the servers that are allowed  
access, but could not and would not restrict access to servers not on  
that list. Why not? If the header was added to an image file, it would  
seem to be a clear indication of what servers were allowed access or  
not.

I suppose in theory, this might make it more difficult if the headers  
were set on all content being served, instead of setting on a case-by- 
case basis, or on a file type basis. But that would mainly be a UI  
issue for the server software, and mainly effect those who wanted to  
be able to share some things and not others.
Received on Monday, 22 June 2009 14:56:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:18 GMT