- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 13 Jan 2016 18:29:28 +0100
- To: Rich Tibbett <rich.tibbett@gmail.com>
- Cc: WebAppSec WG <public-webappsec@w3.org>
On Wed, Jan 13, 2016 at 6:23 PM, Rich Tibbett <rich.tibbett@gmail.com> wrote: > On Wed, Jan 13, 2016 at 6:09 PM, 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(). > > At the point of obtaining access to sensor APIs there is no network access. > What am I missing here? All I'm saying is that there's no escape hatch, because that previously failed to get the desired effect. I'm not sure what that has to do with network access. >>> 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? > > Why could browsers not ship a properly secure sandbox and why should that > not be proposed in this group / mailing list? Hence my questions, what does a suitably/properly secure sandbox mean? > So impossible then unless the whole web adopts HTTPS before this ships? If the whole web is to embed you, I suppose. -- https://annevankesteren.nl/
Received on Wednesday, 13 January 2016 17:29:55 UTC