W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: CSP XML Data with tokens

From: <sird@rckc.at>
Date: Sun, 30 Jan 2011 18:50:11 -0600
Message-ID: <AANLkTi=M6B+8yUzcR54avpfYvdG-NokJwSRM_tnfHbKC@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: Giorgio Maone <g.maone@informaction.com>, Adam Barth <w3c@adambarth.com>, Gareth Heyes <gazheyes@gmail.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Brandon Sterne <bsterne@mozilla.com>, "public-web-security@w3.org" <public-web-security@w3.org>
It is backwards compatible, it's html encoded.. which makes it a no-op
on old UAs.

Either way, given that there are viable alternatives, which are
already defined and were discussed at length at the HTML WG (and were
changed a few times already to fit more use cases). Is it really worth
creating yet another one just because UAs may consume more CPU? I
think the answer is no.

> The whole discussion here started with a discussion over a variety of
> "simple XSS" prevention mechanisms (and I'm not entirely sure why we
> drifted toward sandboxed frames, which I think aren't a very good
> fit).

Because sandbox iframes are supposed to solve XSS by providing authors
the tools to sandbox HTML correctly.

Greetings

-- Eduardo




On Sun, Jan 30, 2011 at 1:31 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>> Anyways, there's not need to argue about this.. you can actually
>> create a javascript snippet of code that automatically transforms all
>> occurrences of:
>>
>> <sandbox start="$nonce">
>> $user_content
>> <sandbox end="$nonce">
>
> Well, that's not backward compatible, dependent on JS, and given the
> limitations of sandboxed frames, just slow.
>
> I think the only realistic way we can eventually have this is to have
> a method for delivering DOM tree directly to the browser, without the
> need to parse it on every client (which, if you come think about it,
> is a remarkable waste of CPU resources);  this would give a lot more
> freedom to simple web frameworks to tackle XSS.
>
> It's not entirely outlandish, too - after all, we have SPDY to do
> roughly the same for HTTP.
>
> /mz
>
Received on Monday, 31 January 2011 00:51:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 31 January 2011 00:51:07 GMT