W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: WebAppSec re-charter status

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 9 Feb 2015 11:23:53 +1100
Message-ID: <CABkgnnXffpR9C8tKThkuzhFC4AB7S9_9t6n8xcWedZcOa--2=g@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC