- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 9 Feb 2015 11:23:53 +1100
- To: Brad Hill <hillbrad@gmail.com>
- Cc: Jeffrey Yasskin <jyasskin@google.com>, Mike West <mkwst@google.com>, Wendy Seltzer <wseltzer@w3.org>, Deian Stefan <deian@cs.stanford.edu>, David Ross <drx@google.com>, Dan Veditz <dveditz@mozilla.com>, Mounir Lamouri <mlamouri@google.com>, David Baron <dbaron@dbaron.org>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 9 February 2015 at 09:58, Brad Hill <hillbrad@gmail.com> wrote: > > https://github.com/w3c/webappsec/commit/433dcc996c092309b88c4e1ecad425ea80a49aed > > What do folks think? Thanks for doing that Brad, this is better. Now that this is clearer, I think that I can identify the problem, here: > This would allow Web application authors and server operators to share data with untrusted code (e.g., in a mashup scenario, cross-origin iframes) yet impose restrictions on how the code can further share the sensitive data. This is, as I understand it, a problem for which there is currently no good solution. The papers I've read on this acknowledge the existence of the side channels that are available, but don't have good answers on how to address the problem. For instance, no solution has been offered to deal with the fact that the sandboxed code could peg the CPU in order to exfiltrate data.
Received on Monday, 9 February 2015 00:24:20 UTC