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

David Carlisle wrote:
> 
> > Until recently, the Web had worked this way for a long time, which
> > reinforced my interpretation of RFC 3023 as saying that text/xml
> > isn't scriptable, if you need to execute scripts for the user, go
> > with application/xml.
> 
> All browsers that have supported xml-stylesheet have supported it in
> the text/xml media type since the beginning, so I don't know what you
> mean by "recently".
> 

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

> 
> > I see that as sniffing, unless the media type is application/xml.
> 
> I don't believe there is any reason to see this as sniffing, or expect
> text/xml or application/xml to differ here. The only reason for
> preferring application/xml over text/xml is a clearer story re
> character encodings. 
> 

RFC 3023 does describe a clearer story re:  character encodings between
text/xml and application/xml, true.  But does it not also describe a
clearer story re:  end-user intent?

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

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

If the discussion were about applying stylesheets, that would be one
thing.  But the issue is allowing Javascript to execute.  I'm not
saying this isn't allowed, I'm saying the case for XSLT is no different
than the case for XInclude discussed in [AuthMeta]:

"
Note, however, that this functionality imposes a social burden on
XInclude processors to be sure that the resulting composed document
does not violate the user's security constraints.
"

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.

>
> > HTML doesn't list text/xml as an allowed media type.  The text/xml
> > media type says nothing about processing tables, forms, links or
> > javascript DOM bindings. 
> 
> Nor should they. The text/xml (or application/xml) media type
> describes the document that is being served. the text/html media type
> describes (in this case) the document that is being rendered which is
> the result of a transformation triggered by the initial xml file but
> may include (via document()) any number of other sources as well.
> 

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.  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
for clients to follow to the server-transformed variant, in case the
transformation fails.  If the transformation is successful, the <body>
content is replaced with Atom source content transformed via document().

It would be just as improper, if I were to use Atom source documents
with XML PIs calling XSLT transformations resulting in an (X)HTML
document.  The authoritative media type, application/atom+xml, is
ignored while the browser switches to text/html and starts executing
Javascript.  There's nothing in the application/atom+xml media type
identifier that even suggests to intermediaries or clients that
Javascript may start executing, so it's a privilege escalation.

This is not an insoluble problem.  I've described alternative solutions
using both text/html and application/xhtml+xml which avoid the issue of
Javascript privilege escalation altogether.  What I'm trying to
understand is where the difference lies between my approach and yours,
David.  Is my approach standard practice, or merely the best practice
described by [AuthMeta] (use the media type which matches the root
element of the document the user manipulates), REST dogma, or just my
way of doing things?

You asked why I did things my way instead of your way, and I answered
-- privilege escalation.  I just don't think it's any more proper, if
the authoritative media type is (text|application)/{*+}xml (except of
course application/xhtml+xml), for Javascript to start executing than
it is for text/plain.  Only HTML media types describe Javascript DOM
bindings, so if the user is manipulating an (X)HTML document that uses
Javascript, the authoritative media type shouldn't be anything but
text/html or application/xhtml+xml.

As I explained on the other list, what I know is directly proportional
to what I've gotten wrong.  I remain unconvinced that using text/xml or
application/xml as authoritative media types for (X)HTML is in any way
proper practice.  In the event someone convinces me, I'd still do it my
way, even if I'm further convinced that my way is just that and not
REST dogma either.  But, I wouldn't point to your implementation and
call it "wrong" again, if that's any consolation...  ;-)

-Eric

Received on Friday, 8 January 2010 22:34:08 UTC