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

Re: WebAppSec re-charter status

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sun, 8 Feb 2015 18:13:46 -0800
Message-ID: <CAPfop_20_QP9-uP8vYmi_W2Gdrg9EwxgzpjpqD4K2CO17NvqiA@mail.gmail.com>
To: Deian Stefan <deian@cs.stanford.edu>
Cc: Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>, 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>
The paragraph on "robust confinement mechanism" doesn't seem as
concrete a deliverable as most other things in the charter. What
exactly are we planning to do? DIFC or DC labels in a browser? Is
there consensus from browser vendors that they are interested in
implementing this.

I think the second paragraph on light-weight workers is a clear
deliverable and will be difficult enough. With that, a large part of
the goals of the first paragraph on confinement can be achieved in an
extensible manner, imo.


On 8 February 2015 at 17:49, Deian Stefan <deian@cs.stanford.edu> wrote:
> 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 02:14:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC