- From: Glenn Adams <glenn@skynav.com>
- Date: Tue, 5 Jul 2011 10:50:57 -0600
- To: John Daggett <jdaggett@mozilla.com>, Bert Bos <bert@w3.org>, Jonathan Kew <jonathan@jfkew.plus.com>, "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
- Cc: W3C Style <www-style@w3.org>, public-webfonts-wg@w3.org, www-font@w3.org, liam@w3.org
- Message-ID: <CACQ=j+d63rtiXPZ9UkjXjqv4w1Tu8B6MKsWsKO_BSvgBOemfPA@mail.gmail.com>
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 >
Received on Tuesday, 5 July 2011 16:51:41 UTC