W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

RE: WOFF and extended metadata

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Wed, 26 May 2010 23:43:50 +0000
To: Jonathan Kew <jfkthame@googlemail.com>
CC: "www-font@w3.org" <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2149472E@TK5EX14MBXC120.redmond.corp.microsoft.com>
> From: Jonathan Kew [mailto:jfkthame@googlemail.com]


> I'm assuming all current browsers that might implement such a feature
> already have XSLT processing facilities, and can display a simple panel
> containing the tiny subset of HTML that this generates. As such, the
> cost of implementing this should be minimal: extract the XML metadata;
> call an existing function to apply an XSL transform to it; call another
> existing function to display the resulting HTML in a UI widget.

And if I don't want to use XSLT ? And if I don't want to use HTML to
render this ? What happened to not creating specific UI requirements ?
 
Why does the input for font metadata have to be open-ended and 
arbitrarily complex ? Why should a browser be able to render any XML
it finds in an optional font metadata block ? Just because XSLT exists
and theoretically can produce something readable ? 

> I'm inclined to think that existing XSLT processors, which are already
> exposed to arbitrary content (both XML input and XSL stylesheets)

Precisely. The less often arbitrary content needs not just parsing but
processing - for rendering or any other purpose - the better.

> ...the Web, should be at least as robust against malicious attackers as
> some piece of newly-written code 

XML parsers are not newly-written code. Depending on XML parsing represents
a smaller dependency and exposure than depending on XML *and* XSLT *and* the 
HTML it produces. This is read-only metadata. How much of the XML-* alphabet 
soup should we need to show it to the user, realistically ? 

I'm of the opinion this stuff should be parsable by a Perl or Python script without
any XML parser dependency but that ship has apparently sailed. I'm fine with that. 
I am not fine with saying that because this is XML then we can also depend on XSLT
to make HTML and therefore everything is great. We're now way past the point where 
all I'm going to give users is a View Raw Source. At best.

> If that's not the case -- if we have XSLT capabilities in our browsers,
> but they're vulnerable to potentially malicious content that people
> might be trying to feed into them -- then we have a pretty serious
> problem on our hands already.

Well, browser vendors do have a lot of pretty serious problems and concerns
on their hands when it comes to security already. I'm not interested in extending 
their scope to places where they're totally unnecessary and add no value.
Received on Wednesday, 26 May 2010 23:44:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC