- From: <sird@rckc.at>
- Date: Sun, 30 Jan 2011 18:50:11 -0600
- 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 UTC