On Fri, 11 Dec 2009, Michal Zalewski wrote:
1) IFRAME semantics make it exceedingly cumbersome to sandbox short
snippets of text, and this task is perhaps the most common and pressing
XSS-related challenge. Unless the document is constructed on client side
by JavaScript, sites would need
On Sun, Jan 24, 2010 at 11:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Dec 2009, Michal Zalewski wrote:
2.1) The ability to disable loading of external resources (images,
scripts, etc) in the sandboxed document. The common usage scenario is
when you do not want the displayed document to
On Sun, 24 Jan 2010, Adam Barth wrote:
On Sun, Jan 24, 2010 at 11:52 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Dec 2009, Michal Zalewski wrote:
2.1) The ability to disable loading of external resources (images,
scripts, etc) in the sandboxed document. The common usage scenario is
On Sat, Jan 23, 2010 at 3:41 AM, Kit Grose k...@iqmultimedia.com.au wrote:
I agree with Aryeh in principle; when you're updating the suggestions on
every keypress, extra processing and DOM manipulation at the Javascript level
would be good to avoid.
I don't think this is a big issue. Users
On Sun, Jan 24, 2010 at 5:52 AM, Ian Hickson i...@hixie.ch wrote:
What would the sandbox do, other than require one level of escaping?
i.e. what is it protecting against?
span sandbox$something/sandbox was meant to be more or less the
same as iframe sandbox srcdoc=$something. The latter
