Re: [powerful features] Secure Contexts and Framed Documents

On Wed, Jan 13, 2016 at 9:11 AM Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jan 13, 2016 at 5:59 PM, Rich Tibbett <rich.tibbett@gmail.com>
> wrote:
> > In addition, no 'escape hatch' for an iframe that does everything right
> > other than having 'bad' parents has been discussed AFAICT. Could a
> > potentially non-HTTPS parent opt-in an HTTPS-based iframe to access
> certain
> > powerful features somehow?
>
> No, this is the specific scenario we are trying to avoid. I.e.,
> Netflix worked around the HTTPS restriction on to crypto API by using
> an <iframe> and postMessage().
>
>
> > Alternatively, could an HTTPS iframe be suitably
> > sandboxed from its non-secure parent(s) so it can continue to gain
> access to
> > powerful APIs?
>
> No postMessage()? What did you have in mind?
>
Part of the issue is that even if a frame does 'everything' right (and I
don't really know what 'everything' would mean, so as Anne requested, it
would be good to make that clear), it would be extremely difficult to
present permission decisions to the user in a meaningful way. Origins are
already hard enough to present, and if you have a secure origin requesting
a permission within a secure frame, how would the user agent present this
in a way to meaningfully convey the weird security layering going on?

>
>
> > Could it be a further permission option we obtain from users,
> > potentially at the same time they authorize a powerful feature on our own
> > site, so they can then also access it in an iframe on a third-party site?
>
> This doesn't seem like something you can reasonably ask users.
>
>
> > Really I'm asking what we should do if/when these framed document
> > restrictions ship. We have no control over the industry content
> distribution
> > networks we need to use and simply find ourselves in a difficult
> situation
> > we need to resolve in any way other than 'it is impossible'.
>
> Recommend folks to adopt HTTPS.
>
Use a new window/tab for your feature?

>
>
> --
> https://annevankesteren.nl/
>
>

Received on Wednesday, 13 January 2016 17:22:10 UTC