WebKit feedback on ISSUE-100 (remove srcdoc)

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 Saturday, 17 July 2010 22:38:32 UTC