Re: In-browser sanitization vs. a “Safe Node” in the DOM

IFRAMEs require significant engineering work to implement in many
cases, and aren't particularly flexible in some ways.  They're square
and styles from the outer page don't affect them.  Scrollbars might
appear or content may be obscured if it isn't quite the right size.
That can be handled but it increases complexity.  These issues should
fixed by seamless though, as you point out.

But seamless isn't a particularly good solution out of the box...
You'd need to pick the right CSP and pick the right policy for the
IFRAME sandbox, which can be tricky.  You can do all sorts of fancy
things with postMessage, which is tempting but adds a ton of
complexity.  But then also postMessage doesn't work if you've disabled
script on the inner page, which you'd need to do if the IFRAME was
same-origin to its container.  You need to make navigation target the
top level if you want to allow navigation.  Finally, last time I
checked, the outer frame has no way of taking action when links within
the sandboxed frame have been clicked, hovered over, etc. (reference
https://bugs.webkit.org/show_bug.cgi?id=98951)  This would be an
important consideration for the mail client scenario, as an example.

In contrast, it should be possible to create Safe Nodes on-the-fly
whenever you want to safely render a little snippet of untrusted
markup.  You mostly don't need to think through all these
considerations, just create a Safe Node and add it into the DOM.
Configuration options are available, but they're tuned to the use
cases you might care about and they don't create much of an
opportunity for shooting yourself in the foot.

Though I would agree that in a world with seamless IFRAMEs, it should
be possible to build a decent Safe Node polyfill.

> Like, will form elements and others impact the global scope?
Per above, form elements wouldn't function.  Input elements would
still be available though.  Presumably with a sandboxed frame you'd
disable allow-forms so the behavior would be the same.

Dave

On Sat, Jan 23, 2016 at 1:48 PM, Andrew Sutherland
<asutherland@asutherland.org> wrote:
> Could you elaborate on the specific use-cases motivating this proposal?
>
> As an email app developer (currently on the Firefox OS Gaia email app,
> previously on Thunderbird) whose app sanitizes HTML mail messages[1], it
> seems like the following largely meet our needs and potentially eliminate
> much of our need for sanitizing:
> - iframes
> - The iframe sandbox attribute
> - CSP2 in the iframe by way of an injected meta element
>
> The motivating goals for this are:
> - Privacy: Ensure that no network accesses occur as a by-product of the user
> reading an email message unless they specifically choose "show images".  I
> think CSP2 now may provide a sufficient means of accomplishing this.
> - Anti-annoyance.  It's generally accepted that HTML emails do not have the
> full fidelity of the web open to them, and so it's appropriate for us to
> ensure the user's expectations of an inert (non-singing, non-dancing)
> message.
>
> If the above mechanisms are insufficient, I'd think I'd consider some
> combination of:
> - requesting new fanciness for CSP
> - using service workers and their ability to decide how to fulfill requests
> from within my origin
> - requesting an enhancement to service-workers to allow them programmatic
> access to extra context information in order to deny fetch requests.  For
> example, Thunderbird makes use of Gecko's nsIContentPolicy mechanism[2] to
> forbid remote network access from mail messages.  (And I think this is
> generally in line with how your proposal would work under the hood.)
>
> This proposal seems to discard iframes quite quickly, so maybe there's
> something about your use case where this makes sense?  I do agree it's
> majorly unfortunate that we don't have a way for an iframe to self-size
> itself to be displayed in its entirety.  I feel like I've read off-hand
> comments that a solution might be more feasible once CSS Containment happens
> (https://drafts.csswg.org/css-containment/) but I really may be
> misremembering/misinterpreting.  But it seems like if what we really want is
> seamless iframes, it's simpler and saner for everyone if we just ask for
> seamless iframes rather than introducing a new concept with its own new
> semantics to the world[3].
>
> Andrew
>
> 1: Using a white-list based mechanism using
> https://github.com/mozilla-b2g/bleach.js.  We did, however, discuss creating
> an HTML API before going with a pure JS library. See
> https://groups.google.com/d/msg/mozilla.dev.webapi/wDFM_T9v7Tc/_yTofMrjBk4J
>
> 2: See
> https://dxr.mozilla.org/mozilla-central/source/dom/base/nsIContentPolicyBase.idl
> and
> https://dxr.mozilla.org/mozilla-central/source/dom/base/nsIContentPolicy.idl
> for the interface.  Thunderbird's usage is at
> https://dxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgContentPolicy.cpp#431
>
> 3: Like, will form elements and others impact the global scope?  It doesn't
> seem safe to let them do that, but you're changing their behavior if you
> don't.
>

Received on Monday, 25 January 2016 08:05:59 UTC