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 22:43:33 -0800
Message-ID: <CAPfop_3qxBBzdnr6jNxJ0HVh5OqPJaA22+7p2RsjNjdFbe89-w@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>
I think asking browsers to implement any distributed information flow
system is a big ask and to make it a deliverable for this WG an even
bigger ask. I think creating confined containers (workers or iframes)
that then allow some JS script to create simple information flow based
policies is a simpler first step and a more concrete deliverable. Note
that this in itself is not easy and it is not clear it can even be
done---see Martin's notes about side-channels.


On 8 February 2015 at 19:26, Deian Stefan <deian@cs.stanford.edu> wrote:
> Hi Dev,
> Devdatta Akhawe <dev.akhawe@gmail.com> writes:
>> 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?
> I was trying to use language similar to the other deliverables, but I'm
> happy to expand and clarify further.
> The plan is to provide APIs for specifying policy in terms of (DC)
> labels and extend browsing contexts with labels (and APIs for changing
> this label). The context label dictates with whom the context can
> communicate, for example, by mapping the label to an underlying CSP
> policy and sandbox-flags and checking labels when sending messages.
> An alternative (to DIFC) way of thinking about this is in terms of CSP:
> when communicating with a party COWL ensures that the target's CSP is at
> least as restricting as the sender's.
>> 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.
> I think that the light-weight worker deliverable is pretty
> straightforward. And it can also be separately from the first part. I do
> think that different components can be defined modularly as you
> suggest. But, it is not enough to just define the workers to do
> confinement. (I am not sure if that's what you meant by "With that".)
> Thanks,
> Deian
Received on Monday, 9 February 2015 06:44:20 UTC

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