Re: WebKit feedback on ISSUE-100 (remove srcdoc)

(Correcting Sam's email address to his Apple one, so his mail doesn't bounce if he replies.)

Thanks for the input. Authors of the relevant Change Proposals should feel free to make revisions taking this information into account.

It would also be useful to hear from other implementors about their thoughts on @srcdoc, as well as the related @sandbox and @seamless features.

Regards,
Maciej

On Jul 17, 2010, at 3:37 PM, Adam Barth wrote:

> There seems to be some question as to the level of implementor
> interest in iframe@srcdoc.  As with Mozilla, there's rarely a single
> "WebKit position" because the WebKit project encompasses a large
> number of folks with diverse interests, but I did talk the issue over
> with Sam Weinig, one of the project's security experts.  Here's our
> feedback:
> 
> 1) @srcdoc seems useful, especially in conjunction with @seamless and
> @sandbox.  As many of you know, we've already implemented @sandbox.
> There's a lot of interested in implementing @seamless.  Having @srcdoc
> completes many use cases.
> 
> 2) Although iframe's are more expensive than DOM nodes today, we hope
> to reduce their cost in the future.  Currently, iframes require
> coordination between several abstraction layers whereas DOM nodes are
> contained in one or two layers.  As part of WebKit2, we're reducing
> the cost of iframes by removing the need to interact with the
> platform's windowing toolkit.  The cheaper iframes are, the more
> attractive @srcdoc is, both compared to network fetches and compared
> to other solutions for isolating untrusted regions of the document.
> 
> 3) As long as user agents don't implement @srcdoc before @sandbox,
> authors can use @srcdoc as a way of providing content that's only
> visible to @sandbox-aware user agents.  This is a bit of a "one-trick"
> pony, but it's a nice trick.  Hopefully other user agent implements
> will maintain this invariant.
> 
> 4) One important advantage of @srcdoc relative to @src=data is that
> the data passes through few transformations before being presented to
> the parser.  In both cases, the content passes through
> charset-decoding and HTML de-entification before going through the
> iframe's parsing pipeline.  In the case of @src=data, the content also
> goes through URL-unescaping, which adds complexity.  When accessed via
> the DOM, @srcdoc provides a cleaner API than @src=data.  When accessed
> via the DOM, @srcdoc (conceptually) delivers the characters directly
> from JavaScript to the HTML parser, skipping the URL-unescaping
> middleman.
> 
> 5) The implementation burden for @srcdoc is very light.  We estimate
> that an experienced WebKit engineer could implement the feature in
> about a day.  Also, ongoing maintenance seems minimal.
> 
> Bottom line: @srcdoc seems useful (especially in conjunction with
> @seamless and @sandbox) and we'll probably implement it.
> 
> Patches welcome: https://bugs.webkit.org/show_bug.cgi?id=42507
> 
> Adam
>

Received on Sunday, 18 July 2010 01:10:14 UTC