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

Re: css3-fonts: should not dictate usage policy with respect to origin

From: Glenn Adams <glenn@skynav.com>
Date: Mon, 20 Jun 2011 12:12:00 -0600
Message-ID: <BANLkTi=X1qAATCetxKumCTfZ_x46DW7=MA@mail.gmail.com>
To: John Hudson <tiro@tiro.com>
Cc: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>, Florian Rivoal <florianr@opera.com>, Martin J. Dürst <duerst@it.aoyama.ac.jp>, Jonathan Kew <jonathan@jfkew.plus.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, W3C Style <www-style@w3.org>, 3668 FONT <public-webfonts-wg@w3.org>, www-font@w3.org
I believe Samsung could agree to making an authorial opt-in mechanism a
mandatory feature on UAs that access WOFF; however, I believe we will not be
able to agree with a policy that requires use of a restrictive opt-out
mechanism which by default would prevent access.


2011/6/20 John Hudson <tiro@tiro.com>

> Vladimir wrote:
>  I believe there may be a need for clarification here: From-Origin (as
>> proposed by Anne) or CORS (as it exists today) are both access control
>> mechanisms - From-Origin offers a generic way for authors to opt-in for
>> origin restrictions for any resource type, while CORS allows to relax (i.e.
>> opt-out from) the restriction that is imposed by default. They are not
>> alternative solutions to same origin restriction - they both complement it
>> by offering a way to relax it.
> That statement is true *if* the default state is same origin restriction.
> That clearly is not the case in today's UAs with regard to many resource
> types. So such a default either must be webfont specific or must involve
> overhaul of how all resource types are currently handled, which seems to me
> very unlikely.
> From-Origin is a resource-agnostic mechanism, so it seems to me that the
> default same origin status of a particular resource type would have to be
> defined elsewhere. From-Origin per se is not a mechanism to relax a default
> same origin restriction or a mechanism to restrict a default cross origin
> permission: it is a mechanism for an author to define specific restrictions
> or permissions for individual resources. As such, I think it provides the
> essential characteristics that we've been seeking in a same origin mechanism
> for webfonts: it provides an easy and reliable means for authors to comply
> with license terms. I too would prefer the default status of webfont
> resources to be same origin restricted, but I think we need to be clear that
> there are two different sets of issues to be resolved:
> 1. publication of From-Origin as a W3C recommendation with, I would argue,
> an obligation that UAs MUST respect From-Origin headers when present;
> 2. publication of a Webfonts Conformance Specification that defines, among
> other things, appropriate same origin restrictions for webfonts.
> It is this second issue around which I can see most debate taking place,
> specifically with regard to a) whether the default status of webfont
> resources should be same origin restricted or not, and b) whether this
> should be a SHOULD or a MUST statement.
> In other words, I think the From-Origin mechanism itself should not be
> optional, and I don't see any value in having such a mechanism be optional.
> But I'm happy to have the debate about whether making the default status of
> webfont resources same origin restricted may be optional.
> From-Origin can function as either opt-in or opt-out, and an author
> wouldn't even need to know which way it is being used for a given resource:
> all he or she cares about is that the header setting be respected. Having
> webfonts be, by default, same origin restricted, best solves the case of
> sites that fail to set a From-Origin header, or that set one that cannot be
> resolved because of e.g. a typo, in terms of preventing unlicensed
> crosslinking or info leakage (which is why I prefer it), but directing
> licensees to set 'From-Origin:same' seems to me desirable regardless of the
> default as it makes them conscious of protection of their investment.
> JH
Received on Monday, 20 June 2011 18:12:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:47 UTC