Re: Permission that spans browsing contexts

If there's value in splitting the powerful features bit out into a separate
spec, I'm happy to do it. It does feel a bit crammed into MIX just because
MIX was there. *shrug*

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

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.)

On Thu, Oct 30, 2014 at 1:56 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> The powerful features push is good. However, it does allow a TLS
> <iframe> to collaborate with non-TLS parent. This is how Netflix gets
> access to Web Crypto and therefore likely complains less about that
> than they complain about making EME a powerful feature.
>
> It might be a bit early, but it would be nice to start considering
> stricter models. Where the top-level browsing context needs to be TLS.
> Or where only the top-level browsing context gets access to a feature
> (proposed for e.g. first-party cookies).
>
> Since Make enjoys writing a lot of tiny specifications, perhaps we
> should have a "security permissions" document that other
> specifications can reference for the permission policy their feature
> enjoys and move the powerful feature stuff from Mixed Content there.
>
> Providing terminology for these various approaches hopefully makes the
> landscape and discourse somewhat less complicated.
>
>
> --
> https://annevankesteren.nl/
>
>