Re: ACTION-308 (part 2) Updates to 'The Self-Describing Web'

David Carlisle wrote:
> 
> > The xml-stylesheet PI can be used to apply CSS, sure, that goes
> > back a long way.  What's recent is XSLT transformation support in
> > Opera 9.5+, Safari 3+ and Chrome (definitely recent). 
> 
> Clearly a system could not support xslt via the xml-stylesheet PI
> until it supported XSLT which ruled out old versions of opera, but
> every browser I know of that has supported xslt at all has supported
> xml-stylesheet in text/xml, including IE from 5.5 onwards, Mozilla
> from a similar period, netscape from version 6, all versions of
> firefox, all versions of Chrome and recent versions of opera and
> safari.
> 

Yes, and I'm questioning the logic behind it all, just as others are
questioning the logic behind allowing text/plain to execute Javascript.

> 
> > Firefox copied a lot of IE-specific behavior, like XHR, that wasn't
> > standardized at the time.  So did the others.
> 
> Support for xml-stylesheet though isn't just following IE it is
> implementing a w3c rec.
> 

OK.  The issue still remains the execution of Javascript when the
authoritative media type doesn't support it.

> 
> > Applying a stylesheet doesn't escalate privilege.  Allowing
> > Javascript to execute does -- it's no more appropriate for text/xml
> > than it is for text/plain.
> 
> XSLT and javascript are both programming languages with security
> implications and sometimes it makes sense to restrict them but I can't
> see any case where it makes sense to do what you appear to suggest,
> allow xslt to generate html but not allow javascript to run in that
> html. In any case the default style applied in the absence of an
> explicit xml-stylesheet in some browsers at least also invokes
> javascript, to display a folding tree view of the xml.
> 

Yes, but their security implications are completely different.  If we
agree that text/xml allows XSLT via XML PI, then there's implied
consent from users to execute XSLT if it's enabled in their browsers.
That implied consent covers a functional programming language based on
immutable data, with no author capability to write to memory or disk.

Javascript has different, and far more serious, security implications.
These are reflected in the media type identifiers for (X)HTML.  There
is nothing in text/xml or application/xml about Javascript DOM
bindings, so there's every reason to assume that using (t|a)/xml won't
result in the execution of Javascript as silent error correction.

> 
> > The user-agent should not perform silent error correction.  The
> > user- agent can inform the user, asking permission to continue, and
> > even offering a checkbox giving explicit consent for XSLT output to
> > execute scripts in the future.  This social burden should apply to
> > text/xml documents whose XSLT transformations result in the browser
> > escalating privilege when it shifts to text/html for rendering the
> > composed document.
> 
> 
> It makes sense to offer the users a configuration option of disabling
> xslt just as they can disable javascript,  but if they choose to allow
> xslt to run, and they allow javascript to run it would be pretty odd
> to say that javascript can't run from the generated html.
> 

Implied consent to execute XSLT doesn't imply consent to execute
Javascript.  I'm not suggesting a configuration opton to disable XSLT
(those already exist anyway), I'm saying that, absent an authoritative
media type that allows Javscript execution, the user agent should warn
the user (and allow for the warning to be disabled) before proceeding
with Javascript execution.

Using application/xhtml+xml or text/html implies consent to execute
both Javascript and XSLT if they're both enabled.  So this whole issue
is avoided by using the proper media type to begin with, IMNSHO.

> 
> > There's no reason you can't use text/html to serve an XHTML document
> > that uses Javascript to call the browser's XSLT engine.
> 
> Why use a browser specific imperative programming API when there is a
> cross platform declarative API for initiating the transform which has
> been standardised by the W3C and implemented by all browsers that
> implement XSLT?
>

Because one of those browsers steadfastly refuses to acknowledge the
existence, or even right to exist, of application/xhtml+xml, which
would have mooted this entire debate.  The standard does exist for
using XSLT to generate XHTML, and all but one XSLT browser vendor
supports it.  Which is easy enough to conneg around.

>
> Sometimes it is necessary to initiate the transform
> from javascript, in particular if you need to pass parameters to the
> transform, but it is a much less satisfactory than using
> xml-stylesheet in most cases.
> 

I agree entirely.  Which is why I'm disheartened that IE 9 will
continue to lead us down an architecturally-incorrect path, instead of
allowing XHTML to be rendered as XML cross-browser.

> 
> > > 
> > > > I use application/xhtml+xml (with xml-stylesheet PI to call
> > > > XSLT) or text/html (with Javascript to call XSLT) as media
> > > > types, when I'm ultimately providing an XHTML interface to the
> > > > user.
> > > 
> > > If the document being served is not xhtml then it is wrong to
> > > serve it using the application/xhtml+xml media type. The fact
> > > that some applications supporting the xml-stylesheet
> > > recommendation may transform the document into xhtml and some
> > > (such as wget) will not, should have no bearing on the media type
> > > to be used for the source document.
> > > 
> 
> > Then make it XHTML.  I serve valid XHTML 1.1 documents whose pre-
> > transformation <body> content contains brief instructions and a link
> 
> As noted above using a processor specific programming API (even if the
> processor specific details are hidden by a library such as sarissa)
> has its uses but doesn't really compare with use of the standard
> xml-stylesheet mechanism.
> 

As I noted above, that's why my XHTML 1.1 source files use xml-
stylesheet to initiate XSLT transformation, and I'm only using
Javascript to call XSLT in IE, because it doesn't support the more
correct media type for my purpose -- delivering XHTML to users.  Only
application/xhtml+xml enables me to deliver an XHTML-as-XML solution to
browsers with implied Javascript consent, so I use it where I can.

Using text/xml delivers an XHTML as text/html solution, as does calling
XSLT from Javascript in IE, so I see those two methods as a wash --
equally inferior to using application/xhtml+xml as the authoritative
media type for transforming content of any format into XHTML +
Javascript in browsers.  Only application/xhtml+xml and text/html come
with implied consent to execute Javascript (unless SVG defines
Javascript bindings, I don't know offhand), though.

-Eric

Received on Saturday, 9 January 2010 00:59:36 UTC