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

> 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.

>  I think we can both agree
> that applying CSS is a safe operation.  The issue here is the safety of
> XSLT output allowing for Javascript execution, when the authoritative
> media type is text/xml.



> >
> > For example
> > 
> > http://www.w3.org/Math/XSL/mml2002-01.xml
> > 
> > which dates from 2002 worked at the time in IE [5.5], netscape [6],
> > mozilla and amaya, and obviously has worked in every version of
> > firefox that's been released since then which is derived from the
> > mozilla base.
> > 

> 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.

>   So I'm hesitant to
> assume that any browsers are an example of proper behavior, where
> they've copied IE, particularly where text/xml is allowed to execute
> Javascript.

> K-Meleon, also derived from the mozilla base, never implemented XSLT.
> So the fact that it applies CSS using XML PIs isn't relevant.  In
> K-Meleon, XML PIs don't result in text/xml executing Javascript.

As I say above, if a browser doesn't implement xslt, then obviously it won't
apply xslt via xml-stylesheet. What's your point?

> >
> > > I'm just a guy who had gotten used to using text/xml for files I
> > > intended to be opened in an editor, or displayed raw.  Without xml-
> > > stylesheet PIs, IE displays text/xml as a collapsible tree.  Other
> > > browsers used to just treat all elements as unknown in-line, while
> > > others displayed it as plain text.  Aside from one aberrant
> > > browser, no user-agent would ever have reason to start executing
> > > scripts.  Or so I thought, anyway.
> > 
> > For a long time, other browsers, eg firefox, opera etc have followed
> > IE's lead in applying a default stylesheet to text/xml files to
> > display a "syntax-highlighted" version of the file if no
> > xml-stylesheet provides an explict style. This is different to the
> > behaviour if the same file is served as text/plain.
> > 

> 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.

> >
> > > What I do not expect to see when I dereference a text/xml URL with a
> > > browser, is an HTML page where tables, forms, links and Javascript
> > > work.
> > 
> > If the xml file has an xml-stylesheet processing instruction
> > referencing a stylesheet that generates html or xhtml, that is
> > exactly what you should see. Being able to style xml in this way is
> > after all the whole point of having an xml-stylesheet recommendation.
> > 

> 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.


> 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? 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.

>   There's at
> least one library, sarissa.js, that's devoted to this approach.  The
> XSLT transformation called can use document() to include any number of
> other sources as well.

> Media types, and media type identifiers, are separate things with
> separate purpose.  The text/html media type identifier describes a
> security mode to intermediaries and clients -- one which allows
> Javascript.  The text/xml media type identifier describes a security
> mode to intermediaries and clients which does not allow Javascript.

> > 
> > > 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.

David

Received on Friday, 8 January 2010 23:30:47 UTC