- From: Andrew Sutherland <asutherland@asutherland.org>
- Date: Sat, 23 Jan 2016 16:48:12 -0500
- To: public-webappsec@w3.org
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 Saturday, 23 January 2016 21:48:37 UTC