[whatwg] Should scripts and plugins in contenteditable content be enabled or disabled?

[Ojan Vafai]

On Fri, Apr 23, 2010 at 2:34 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Apr 23, 2010 at 6:52 PM, Simon Pieters <simonp at opera.com> wrote:
>
>> It seems Hixie has decided to go back to the WebKit behavior in the spec
>> for designMode.
>>
>> http://html5.org/tools/web-apps-tracker?from=2817&to=2818
>>
>
>  It's certainly the easiest to implement, but you can see feedback in
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928 that this makes life
> difficult for people writing editors.
>
> Thanks for the links.
>

The webkit behavior of allowing all scripts makes the most sense to me. It
should be possible to disable scripts, but that capability shouldn't be tied
to editability. The clean solution for the CKEditor developer is to use a
sandboxed iframe.

I don't see a security benefit for disabling script as you'd have all the
same issues with loading any user-content in a non-editable area. The only
catch is that you *do* need to disable script from pasted and drag-dropped
content (see http://trac.webkit.org/changeset/53442). Basically, any site
serving user-content will already need to mitigate XSS some other way, so
disabling script in editable areas is not necessary, but paste/drag-drop
can't reasonably rely on server-side solutions, so must be done by the UA.

Putting my developer hat on, trying to make Google Gadgets work in Google's
rich text editor inside Firefox designMode was awful due to
https://bugzilla.mozilla.org/show_bug.cgi?id=519928. A large percentage of
Google Gadgets load as iframes and require javascript onload. We had to play
tricks with turning off designMode, appending the iframe and turning
designMode back on. It was an awful solution that never worked very well.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100518/0bf4f109/attachment-0001.htm>