Re: WebAppSec re-charter status

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.

cheers
Dev

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