W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

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

From: Garrick Van Buren <garrick@kernest.com>
Date: Tue, 4 May 2010 09:12:46 -0500
Message-Id: <015E1F77-535E-413A-9B0F-4E54E0C65AB4@kernest.com>
To: www-font@w3.org

>> 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
Free, Subscription, and Web Native fonts.
Received on Tuesday, 4 May 2010 14:13:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC