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

On Thu, 2011-06-23 at 13:58 -0600, Glenn Adams wrote:
> Samsung supports your suggestion below if it is expressed either as "should"
> or made conditionally mandatory, where the condition is expressed as follows
> or an equivalent:
> 
> "If the use of WOFF occurs in a context where same origin access constraints
> are *already* present/supported, then that mechanism *must* be used to limit
> access to WOFF fonts; otherwise, such a mechanism *should* be provided for
> such use."

Thank you for responding.

> 
> We do not want the use of WOFF by itself, or css3-fonts, by itself, to
> trigger a mandatory requirement for same origin processing in contexts that
> don't already support such constraints.

Of course, existing older code doesn't support WOFF. So it's not really
about CSS3 or HTML 5, I see your point there.

However, if someone implements WOFF for use with HTML 4 or XHTML 1.1
(say), or for XSL-FO 1.1, they need to consider implementing some sort
of access control.  But that's simply because of the business needs of
the font community.

The goal (of course) is to try to create an infrastructure that helps to
discourage accidental or unknowing infringement by making wilful
infringement more obvious and more obviously unacceptable, while at the
same time not impeding legitimate usage e.g. of Libre/Free fonts.

Achieving this goal has been considerably complicated by the history of
the font industry.


> We note that the @font-face rule has been defined in css3-fonts since 31
> July 2001, and that a variety of UAs have been fielded in the non-desktop
> environment (e.g., mobile, television, etc), which employ @font-face for
> accessing other non-WOFF fonts, and do so without same origin restrictions.

A closed system has inherent access restrictions, of course.  A mobile
device starting to use woff will indeed need new code - at the very
least it'll need code to extract the actual font.

The lesson from XPath was that you can indeed add conformance
requirements on something that's embedded and/or refnced by other specs,
but that the requirements can be as vague as "provide a mechanism to
meet such-and-such a business requirement and say how you did it" and
still be useful.

Hope this helps - I should go back to letting others try to build
agreement :-)

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

Received on Thursday, 23 June 2011 21:51:50 UTC