Re: iframe sandbox for third-party widgets and ads (was Re: [CSP] Clarifications on nonces)

Before diving back into the details, what would you actually like to
achieve by sandboxing ads? That is, of the current set of sandboxing flags,
which do you think should be turned on for these kinds of widgets?

It seems like most (all?) of them would need to be enabled for one use-case
or another, and it also seems like most of the benefit you've been talking
about is achieved with normal, unsandboxed iframes. In fact, when talking
about things like "allow-overlay" or "allow-reposition", we're really
talking about _expanding_ the power of normal iframes, while maintaining
the clear DOM-level boundary.

In short, does sandboxing matter for this use case? If so, why? :)

On Wed, Feb 11, 2015 at 11:21 PM, Brian Smith <brian@briansmith.org> wrote:
> This is the old issue
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13032. Presumably, the
> only plugin people care about in third-party widgets is Adobe Flash.
> It would be great if somebody from Google could comment about the
> feasibility of enforcing iframe sandbox for the Adobe Flash plugin via
> the Pepper Plugin API and/or via iframe isolation. Do you know who
> from Google could provide such a response?

My vague understanding of Flash, pepper or otherwise, is that it still has
a terrible shared-process model where Flash executing on one site isn't
cleanly sandboxed from Flash executing on another site.

That said, there has certainly been some discussion of an `allow-plugins`
sandbox flag (https://code.google.com/p/chromium/issues/detail?id=285301#c6
is the last mention I can find on Chrome's bugtracker) now that we're more
solidly on PPAPI and off of NPAPI, but no one I know is actively working on
it, and I believe it would require changes to Flash to support unique
origins.

> Also, there are lots of ads that don't use Flash and the percentage of
> non-Flash ads is likely to increase over time to 100%. So, even
> without allow-plugins, there's value in making iframe sandbox work for
> non-Flash ads/widgets, which will increase over time.

Yup, totally agree.

>> 2. Some widgets and advertisements offer interactions that break out of
the
>> bounds of an IFrame. This can range from boxes that expand when you
>> mouseover up through excitingly interactive bits that overlay a page's
>> content.
>
> These types of ads don't require access to the page content or to the
> embedding origin's cookies and whatnot. Adding something like
> "allow-overlay" and/or "allow-reposition" would still be a win, even
> though it increases the chances of some attacks succeeding like
> clickjacking.

They do require mechanisms of escaping from an iframe's boundary, though.
We've traditionally made that very difficult indeed, but I agree with you
that it might be reasonable to allow the embedder to opt-into some
different behavior. I have no idea what that would look like from an API
perspective, but it's certainly an avenue well worth exploring.

Note though, that this probably doesn't work well as a "sandbox" attribute,
as it's really about expanding the powers of iframes in general to cover
new use cases.

>> It would be good to determine how we can best solicit feedback from
>> advertisers and widget creators, as I suspect that most folks meeting
that
>> description aren't participating in the WG. :/
>
> I agree that more communication is needed here. Detailed feedback from
> Google and Facebook would go a long way, and luckily there are very
> active WG participants from both of those companies who may be able to
> help facilitate the dialog.

I seem to keep making proposals to our ads teams that they don't like very
much. Maybe this is a good opportunity to give them something they might
actually use. :)

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)