After further discussion, Samsung has decided to drop the FO expressed in
our prior communication [1] and the subsequent thread. Notwithstanding this,
we believe that:
- mandating SOR in css3-fonts (and woff) introduces an inconsistency in
CSS related technology, since none of the other CSS related specifications
requires SOR for CSS derived resource fetches derived from, e.g., resolving
url() references in CSS property values, resolving @import rule, etc.
- mandating SOR in css3-fonts (and woff) is not sufficiently motivated
from documented requirements or use cases; for example, that the primary
motivation for SOR is the enablement of content owner licensing restrictions
is not disclosed;
- if there are intrinsic security issues related to the decoding and
rendering of font resources, then such issues are similarly not disclosed or
discussed; indeed, it is not clear that there is any more security risk in
decoding and rendering fonts than there is in decoding and rendering images;
- if there is to be a transition from a pre-SOR world to an
SOR-everywhere world, then there should be a coordinated approach to such a
transition, with participation from a wider group of stake holders; doing
this on a piecemeal basis starting with fonts is not a coordinated approach
and will likely lead to inconsistencies in implementations and community
buy-in;
Finally, Samsung continues to believe that the best place to define
requirements on fetch policies is in those specifications that actually
define or use fetch algorithms. We believe that css3-fonts and woff
specifications do not fall into this category. In particular, we do not
consider that the semantics of @font-face implies the use of any particular
fetch algorithm, but merely defines a mechanism to provide an author defined
binding between a font specification and a resource locator.
Regards,
Glenn Adams
[1] http://lists.w3.org/Archives/Public/www-style/2011Jun/0476.html
On Fri, Jun 17, 2011 at 3:33 PM, Glenn Adams <glenn@skynav.com> wrote:
> In [1], section 4.8, are specified constraints on use of css 3 fonts
> features, and, in particular, mandate cross origin reference constraints and
> the use of CORS.
>
> Such constraints constitute policy requirements that are unrelated to the
> definition of the underlying mechanisms defined by css3-fonts. Furthermore,
> effective use of the defined mechanisms does not depend on such a policy.
> Therefore, these policy requirements should be removed.
>
> If a specification defining UA behavior makes reference to css3-fonts and
> wishes to impose such a policy, then it may do so independently, and without
> affecting the functionality of the css3-fonts mechanism itself. Note that
> under a heading of "Security Issues", it may be indicated that such a policy
> may need to be defined and enforced by an external mechanism, defined
> outside of this specification.
>
> Please consider this a formal comment (and objection) from Samsung to
> imposing such policy constraints in this specification.
>
> Regards,
> Glenn Adams (for Samsung)
>
> [1] http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction
>