- From: Deian Stefan <deian@cs.stanford.edu>
- Date: Sun, 08 Feb 2015 17:49:40 -0800
- To: Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>
- Cc: Jeffrey Yasskin <jyasskin@google.com>, Mike West <mkwst@google.com>, Wendy Seltzer <wseltzer@w3.org>, 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>
Hi Martin, Martin Thomson <martin.thomson@gmail.com> writes: > 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. You're right, COWL would not prevent malicious code from leaking sensitive information via covert channels. But, today, when you share data with untrusted code you have no control over what it can do with the data---all you can do is decide whether or not you *completely* trust the code. You're not only trusting it to not be malicious, but you are trusting it (and the code it relies on) to not have bugs that can lead to leaks. COWL adds another layer of protection to existing security model (it is strictly more restricting than the SOP and CSP) to address this. If an attacker has to resort to using covert channels to leak data then we've improved the current state, in my opinion. We've previously discussed exfiltration via covert channels in the context of CSP [1] and I think the general consensus has been to try to at least address leaks through _overt_ channels. Would changing the language address some of your concerns? I would be happy to use a word other than "untrusted." Or at least tone it down to say "untrusted, but not malicious." (We should avoid giving people the impression that they can share sensitive data without any concern.) Thanks, Deian [1] https://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0047.html
Received on Monday, 9 February 2015 01:50:09 UTC