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

Sylvain,

> 
>> Protection from that leakage is only needed because of some fonts
>> licenses.
> 
> Font licenses were not the main reason but it was a useful side effect.
> 

Great, what are some pointers describing the main technical advantages protections as a standard?

> 
>> Sure, I'm new here - but it seems awkward that we're working towards a
>> specifying protective checks for all fonts - when not all fonts have a
>> license that discourages leakage.
> 
> The awkwardness already exists. Firefox has limited fonts to the same
> origin since the beginning. It sounds like no one has complained.


Yes - and the day I upgraded, it broke a significant portion of my work. 

> 
>> If we're going to design a ruleset for all fonts based on the
>> characteristics of some of them - what's the downside of no 'protection
>> against leakage' ?
> 
> Higher vulnerability exposure in the short term. And, if licensing terms do
> not change, you may reduce author choice by losing a large chunk of the new 
> fonts you wanted to access. It could mean you're back to using the exact
> same set of fonts you have access to today, but with built-in compression.
> 

Short term?!?!?!?! @font-face was barely adopted in it's 10 years of existence - partially because of frigid licensing terms. Now the conversation is around recommending a single technical solution to accommodate the thousands of different licensing terms? It is conceivable that a license exists that would be violated because of this recommendation.

Lastly, given how easy it is to externally compress I don't find built-in compression advantageous. In some ways, it's more problematic.


Is this helpful?

-----------------------
Garrick Van Buren
612 325 9110
garrick@kernest.com
-----------------------
Kernest.com
Free, Subscription, and Web Native fonts.
-----------------------

Received on Tuesday, 4 May 2010 14:13:38 UTC