W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

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

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 19 May 2010 16:57:25 -0700
Message-ID: <AANLkTim-A0_Aa3Bt4DJMQusJ8LA2mPOBkehQiQezEcti@mail.gmail.com>
On Wed, May 19, 2010 at 4:32 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Wed, May 19, 2010 at 5:35 AM, Ojan Vafai <ojan at chromium.org> wrote:
>>
>> 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.
>
> Discussion led to the point that there's a fundamental conflict between
> sandboxed iframes and JS-based framebusting techniques. The point of
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928 is that Web sites using
> JS-based techniques to prevent clickjacking can be thwarted if the
> containing page has a way to disable JS in the child document. Currently
> 'designmode' is usable that way in Gecko, but 'sandbox' would work even
> better.
>
> Maybe sites should all move to declarative techniques such as CSP or
> X-Frame-Options (although there are suggestions that maybe they don't want
> to for some reason --- see
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928#c5 ). But there are
> still issues with existing sites. Should we care?

Virtually none of the JavaScript framebusting scripts used by web
sites are effective.  You can build one that is effective, but you
need to build it with the idea that JavaScript might be disabled, and,
in that case, it will play nice with @sandbox.  I'd recommend that
sites use something declarative, such as X-Frame-Options or
Content-Security-Policy.

Adam
Received on Wednesday, 19 May 2010 16:57:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC