W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

Re: [powerful features] Secure Contexts and Framed Documents

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 13 Jan 2016 18:09:26 +0100
Message-ID: <CADnb78j0_dw0jB9HKdvwqPViOcHYTs68QnyqC2N=JCrepVvnMg@mail.gmail.com>
To: Rich Tibbett <rich.tibbett@gmail.com>
Cc: WebAppSec WG <public-webappsec@w3.org>
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?


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


-- 
https://annevankesteren.nl/
Received on Wednesday, 13 January 2016 17:09:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:17 UTC