- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 13 Jan 2016 18:09:26 +0100
- 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