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: Fri, 17 Jun 2011 19:47:42 -0600
Message-ID: <BANLkTimk8tnO2j=yaD3Y-cxBfBnPkuoQ4A@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: John Hudson <tiro@tiro.com>, W3C Style <www-style@w3.org>, 3668 FONT <public-webfonts-wg@w3.org>, "www-font@w3.org" <www-font@w3.org>
I interpret the prevention of "leakage" as a form of content protection,
albeit a weak one.

In any case, a font file format (WOFF) and a font referencing system
(@font-face) do not need to have a security story. Describing fonts (the
format) and referring to them (the referencing system) does not require them
to be accessed. Access is part of the UA regime, and if there is policy and
controls on access, it should be defined at the UA layer, not the file
format or reference layer.


On Fri, Jun 17, 2011 at 5:31 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Fri, Jun 17, 2011 at 4:17 PM, Glenn Adams <glenn@skynav.com> wrote:
> > I will take a close look at that proposal and respond further. Samsung's
> > primary concern is that this type of requirement (as presently written)
> > delves into the domain of content protection or the enforcement of
> business
> > terms. It is one thing to define a mechanism that can be used by those
> who
> > wish to control content use and dissemination; it is an entirely
> different
> > matter to mandate use of such a mechanism within a content format
> definition
> > or referencing scheme.
> Same-origin restrictions have nothing to do with content protection,
> as you can trivially just download the font yourself (assuming it's
> publically accessible) and host it on your own server.  It's about two
> things:
> 1. A consistent security story.  There shouldn't be a distinction
> between embedding and reading (in practice, they end up being the same
> due to info leaks).  Applying same-origin at the embedding level lets
> us prevent info leaks more directly than just preventing reading and
> then hoping we plug the leaks that come from embedding.
> 2. As a lesser point, protecting server owners from hotlinking is a
> nice benefit.  As I stated above, a third party can always just grab
> the file and host it themselves; there's never any reason to directly
> hotlink it.
> ~TJ
Received on Saturday, 18 June 2011 01:48:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:02 UTC