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

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.

G.

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
>