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

> From: Anne van Kesteren [mailto:annevk@opera.com]

 
> 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.

OK, so because CORS was not intended to address this specific use-case, the 
solution is to invent a new HTTP header that will essentially clone the relevant
subset of CORS (simple cross-domain requests, I think) and that header is only to 
be used in cases where information leakage is not involved. Right ? And that is both
consistent 'with the design principles that are used for the Web platform' and
preferable to using an existing, working, interoperable approach ?

And once we agree on said solution, browser vendors who have already written their 
web font code to use CORS will need to write new code and may have to support the
current solution for backward compatibility. That seems a very costly route to 
interop. What are the benefits of such a roadmap for authors ?

> Of course we can change the principles and make an exception, but I do
> not feel it is justified.

Well, we need to put feelings aside and keep our arguments concrete.
Beyond general design principles and feeling that a given approach is
uncalled for, are there either hard conformance requirement in CORS that 
make this non-conformant, or technical issues or scenarios that make CORS 
a poor practical choice for this purpose ?
 
> (It is probably not worth going further on the "fonts are like images"
> theme. I do not think you are right that I lack some kind of knowledge
> I could have acquired by participating more. I have studied the subject
> to quite some extent since the day David Hyatt implemented @font-face
> support in WebKit in a couple of days. I think we simply disagree.)

Given that I started in the same position you're in, I wouldn't be so
sure. Your position is coherent and consistent from a purely technical 
standpoint i.e. if the code should work that way, and if that is consistent 
with what's been done before then that's the way it should be. Which, as a 
former developer, I can relate with. Except this position has in practice 
limited authors to a world of incompatibility and limited choice. You and I 
could just decide to wait for all font and browser vendors to see the errors of 
their ways and admit the inherent righteousness of our preferred approach. 
Given how long we have been waiting for web fonts, I'd rather move to a world 
where web authors can choose any fonts they like, whether free, commercial or 
subscribed from a font service. 

And if all it takes to achieve that is per-table compression and SOR, I'd rather 
concede those and give authors and font vendors what they want and get beautiful 
typography everywhere vs. keep the code 'pure' and stick to the Verdana web for 
another decade or more. Or see web typography controlled by a few proprietary font
obfuscation services. Pick your poison.

That I support this does not imply that it is my technical preference. It is a 
reasoned pragmatic trade-off. I think most of us here have come to agree that 
the minor implementation and inconsistency costs are well worth the long-term 
benefits of solving this old problem once and for all. 

And if the one thing that seems 'uncalled for' is a result of trying to use 
an existing standard solution instead of making up something new and somewhat 
redundant, I feel pretty good.

Received on Tuesday, 4 May 2010 05:17:00 UTC