Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

[L. David Baron]

The W3C is proposing a revised charter for:

Web Application Security Working Group
http://www.w3.org/2014/12/webappsec-charter-2015.html
https://lists.w3.org/Archives/Public/public-new-work/2014Dec/0008.html

Mozilla has the opportunity to send comments, objections, or support
through Friday January 30.

Mozilla is involved in this working group; see membership at
https://www.w3.org/2000/09/dbwg/details?group=49309&public=1&order=org .

Please reply to this thread if you think there's something else we
should say, or if you think we should support the charter.

I'd note that the charter doesn't say anything about asynchronous
decision making, which is a bit unusual.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Anne van Kesteren]

On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron <dba...@dbaron.org> wrote:
> Please reply to this thread if you think there's something else we
> should say, or if you think we should support the charter.

I think in general it's fine, but there's a couple things:

* "Confinement with Origin Web Labels" the description does not make
it clear what this actually is.

* "Entry Point Regulation for Web Applications" in a way this is nice
for defense-in-depth, but also seems to allow a site to completely
isolate itself from the rest of the web.

* "Permissions API" this has been tried several times before. Given
that there's hardly any involvement from UX in standards, it's not
clear that this is a good idea. See also
http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html

Also, can we request that they adopt a public asynchronous decision
policy? I think we should start making that request from any WG.


--
https://annevankesteren.nl/

[Martin Thomson]

On Fri, Jan 16, 2015 at 12:58 AM, Anne van Kesteren <ann...@annevk.nl>
wrote:

> * "Permissions API" this has been tried several times before. Given
> that there's hardly any involvement from UX in standards, it's not
> clear that this is a good idea. See also
>
> http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html
>

I share this reservation. I also think that this could undermine the work
that has been done with respect to user consent in other areas.
Specifically the Media Capture task force and the Geolocation working
group. I'd expect statements in the charter regarding liaison with
affected groups at a minimum, if not actual prior consultation (and I've
seen no evidence of that).

[Eric Rescorla]

Indeed: more generally, there's a certain flavor in this charter of setting
up
WebAppSec as the decider for how security features should be implemented
in other W3C WGs (for instance, Powerful Features). I don't think
that that's very helpful or really matches WebAppSec's historical role.

-Ekr

[Jonas Sicking]

On Fri, Jan 16, 2015 at 12:58 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> * "Permissions API" this has been tried several times before. Given
> that there's hardly any involvement from UX in standards, it's not
> clear that this is a good idea. See also
> http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html

Note that the scope of this spec is very narrow (which sadly isn't
reflected in the name).

The scope *only* covers querying if a given API will be automatically
denied, automatically granted or if UI will be displayed.

So it's not attempting to solve permissions in general. Nor does it
allow even asking for permission to use a particular API.

This might not seem like terribly important functionality, but it's
something that web developers ask for a lot.

With this API they can do things like hide "turn on camera" buttons if
the user has permanently forbidden a website from using camera. Or
they can inform the user that a security dialog is about to be
displayed.

Right now well-meaning websites see a lot of dropoff whenever they
cause a security dialog to be displayed because many people don't
understand the dialog and (wisely) choose "no". Obviously a lot of
users also choose "yes" even when they don't understand a security
dialog, but far from all do.

By enabling websites to check if a dialog will be displayed, the "good
guys" will have the ability to educate the user.

I don't think there are any security risks with enabling websites to
do this education. The bad guys can simply always put up text which
tries to trick the user that a dialog is harmless.

There could be some privacy concerns with this API. If we add the
ability to set blanket policies like "forbid camera for all websites
except for X.com and Y.com", then websites could use the fact that
they see a "access will be automatically denied" as extra
fingerprinting bits.

However there are ways to implement such policies without leaking
additional information. We can simply make the permissions API lie and
return whatever the default behavior is until the website actually
tries to use the given API. At that point we could automatically deny
and then make the permissions API reflect the real behavior.

/ Jonas

[David Illsley]

On Fri, Jan 16, 2015, at 08:58 AM, Anne van Kesteren wrote:
> On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron <dba...@dbaron.org>
> wrote:
> > Please reply to this thread if you think there's something else we
> > should say, or if you think we should support the charter.
>
> I think in general it's fine, but there's a couple things:
>
> * "Confinement with Origin Web Labels" the description does not make
> it clear what this actually is.
>
> * "Entry Point Regulation for Web Applications" in a way this is nice
> for defense-in-depth, but also seems to allow a site to completely
> isolate itself from the rest of the web.

Indeed. It reads to me to allow sites to trivially get a browser to
prevent deep linking, which doesn't seem desirable.

David

[Brian Smith]

L. David Baron <dba...@dbaron.org> wrote:

> The W3C is proposing a revised charter for:
>
> Web Application Security Working Group
> http://www.w3.org/2014/12/webappsec-charter-2015.html
> https://lists.w3.org/Archives/Public/public-new-work/2014Dec/0008.html
>
> Mozilla has the opportunity to send comments, objections, or support
> through Friday January 30.
>
> Mozilla is involved in this working group; see membership at
> https://www.w3.org/2000/09/dbwg/details?group=49309&public=1&order=org .
>

> Please reply to this thread if you think there's something else we
> should say, or if you think we should support the charter.

Please see the threads at

[1] https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0179.html
[2] https://groups.google.com/d/topic/mozilla.dev.privacy/Rbm1XdfXX6k/discussion

In particular, although I think the sub-origin work is potentially
very useful, it seems to have some pretty negative unintended
consequences. Even if you don't share my specific concerns about the
potential negative interaction between the sub-origin part of the
proposed charter with respect to Mozilla's Tracking Protection work,
it is still a good idea for Mozilla to spend some time to fully
understand all the intended and unintended consequences of the
sub-origin concept and the specific design being proposed for it.

Cheers,
Brian

[L. David Baron]

On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote:

> On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron <dba...@dbaron.org> wrote:
> > Please reply to this thread if you think there's something else we
> > should say, or if you think we should support the charter.
>

> I think in general it's fine, but there's a couple things:
>
> * "Confinement with Origin Web Labels" the description does not make
> it clear what this actually is.

I suppose I can ask that the description be made clearer. Is there
something in particular that you think it should say?

> * "Entry Point Regulation for Web Applications" in a way this is nice
> for defense-in-depth, but also seems to allow a site to completely
> isolate itself from the rest of the web.

I don't see what feedback you want me to give here.

> * "Permissions API" this has been tried several times before. Given
> that there's hardly any involvement from UX in standards, it's not
> clear that this is a good idea. See also
> http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html

Are you ok with sicking's response to this?

> Also, can we request that they adopt a public asynchronous decision
> policy? I think we should start making that request from any WG.

What do the Mozillians involved in the WG think about this?

[Eric Rescorla]

On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron <dba...@dbaron.org> wrote:

> On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote:
> > On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron <dba...@dbaron.org>
> wrote:
> > > Please reply to this thread if you think there's something else we
> > > should say, or if you think we should support the charter.
> >
> > I think in general it's fine, but there's a couple things:
> >
> > * "Confinement with Origin Web Labels" the description does not make
> > it clear what this actually is.
>
> I suppose I can ask that the description be made clearer. Is there
> something in particular that you think it should say?
>
> > * "Entry Point Regulation for Web Applications" in a way this is nice
> > for defense-in-depth, but also seems to allow a site to completely
> > isolate itself from the rest of the web.
>
> I don't see what feedback you want me to give here.

Is this arguably a violation of the priority of constituencies principle?
It seems like it may serve the site more than the user.

> > * "Permissions API" this has been tried several times before. Given
> > that there's hardly any involvement from UX in standards, it's not
> > clear that this is a good idea. See also
> >
> http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html
>
> Are you ok with sicking's response to this?
>
> > Also, can we request that they adopt a public asynchronous decision
> > policy? I think we should start making that request from any WG.
>
> What do the Mozillians involved in the WG think about this?

It depends what this means. If it means that decisions have to be confirmed
on the list then fine. If it means that they can't be made F2F or on calls
and then confirmed the list, then not so fine.

-Ekr

-David
>
> --
> 𝄞 L. David Baron http://dbaron.org/ 𝄂
> 𝄢 Mozilla https://www.mozilla.org/ 𝄂
> Before I built a wall I'd ask to know
> What I was walling in or walling out,
> And to whom I was like to give offense.
> - Robert Frost, Mending Wall (1914)
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>

[L. David Baron]

On Thursday 2015-01-29 13:27 -0800, Eric Rescorla wrote:
> On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron <dba...@dbaron.org> wrote:
>
> > On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote:
> > > On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron <dba...@dbaron.org>
> > wrote:
> > > > Please reply to this thread if you think there's something else we
> > > > should say, or if you think we should support the charter.
> > >
> > > I think in general it's fine, but there's a couple things:
> > >
> > > * "Confinement with Origin Web Labels" the description does not make
> > > it clear what this actually is.
> >
> > I suppose I can ask that the description be made clearer. Is there
> > something in particular that you think it should say?
> >
> > > * "Entry Point Regulation for Web Applications" in a way this is nice
> > > for defense-in-depth, but also seems to allow a site to completely
> > > isolate itself from the rest of the web.
> >
> > I don't see what feedback you want me to give here.
>
>
> Is this arguably a violation of the priority of constituencies principle?
> It seems like it may serve the site more than the user.

Do you want to insist that it be removed from the charter, or is
this something you think should be addressed during the development
of the spec (perhaps via some requirement that should be added to
the charter)?

[Martin Thomson]

On Thu, Jan 29, 2015 at 1:59 PM, L. David Baron <dba...@dbaron.org> wrote:

> > Is this arguably a violation of the priority of constituencies principle?
> > It seems like it may serve the site more than the user.
>
> Do you want to insist that it be removed from the charter, or is
> this something you think should be addressed during the development
> of the spec (perhaps via some requirement that should be added to
> the charter)?

In my experience, it's customary for controversial issues like this to be
discussed more in detail before entering them onto an official work plan.
I'm only casually following the working group mailing list, is there a
proposal (or proposals) that outlines a direction for this work?

As for the permissions work, I'm not enthused by its presence, and would
prefer if it were stricken.

I realize at this point that might be unrealistic. Currently, there is no
requirement to engage with the groups that might be affected by this work.
That must be fixed by adding to the liaison section: a trivial change.

Ultimately though, I have serious reservations about the viability of the
effort - permissions grants are contextual, and the proposed API fails to
address that requirement - but I am happy to engage in discussion to that
effect. I don't know what expectations are with respect to chartered
items, but if listing on a charter implies some inevitability: a commitment
to complete the listed work, I think that I would rather object to its
inclusion.

[L. David Baron]

On Sunday 2015-01-18 21:00 -0800, Brian Smith wrote:
> L. David Baron <dba...@dbaron.org> wrote:

> > http://www.w3.org/2014/12/webappsec-charter-2015.html

>
> Please see the threads at
>
> [1] https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0179.html
> [2] https://groups.google.com/d/topic/mozilla.dev.privacy/Rbm1XdfXX6k/discussion
>
> In particular, although I think the sub-origin work is potentially
> very useful, it seems to have some pretty negative unintended
> consequences. Even if you don't share my specific concerns about the
> potential negative interaction between the sub-origin part of the
> proposed charter with respect to Mozilla's Tracking Protection work,

I'm having trouble understanding those concerns.

Is the argument you're making that if the site can serve the ads
from the same hostname rather than having to use a different
hostname to get same-origin protection, then ad-blocking (or
tracking-blocking) tools will no longer be able to block the ads?

I suppose I can see that it could make some forms of ad-blocking
(network-level rather than URI-level) more difficult. But it's not
clear to me what the additional tracking potential is in this case.
I don't see where it introduces vectors for sharing cookies (or
other similar data) between sites that don't already exist.

[L. David Baron]

Here are the comments I have so far on this charter, based on the
thread. I'd note that this is a relatively large set of demands to make
in the charter review stage at the AC, especially for a recharter of a
WG that we're involved in. So it may come across to W3C staff as
somewhat demanding.

I'm particularly interested in review of point (3) in what I've written;
I feel that the argument I've written so far is weak, I think because I
don't particularly understand the concerns about the powerfulfeatures
draft.

I also haven't included anything about Brian's objection to the
suborigin namespaces work because I don't understand the objection, and
I don't see how to extract any actionable charter feedback directly from
Brian's message. (Or is it that the deliverable should be removed from
the charter? If so, I could use an explanation as to why.)

In any case, here's the feedback I have so far. Comments are
welcome through roughly 5pm California time on Friday --
particularly actionable ones that suggest how to revise this
feedback or at least say how the charter should be different!

(Sorry for not getting this gathered together sooner.)

-David


There are a number of problematic aspects to this charter to which
we object:

(1) The "Confinement with Origin Web Labels" deliverable is described
in a way that makes it unclear what the deliverable would do. It
should be clearer. Furthermore, the lack of clarity means we
couldn't evaluate whether we are comfortable with it being in the
charter.

(2) The "Entry Point Regulation for Web Applications" deliverable seems
to have serious risks of breaking the ability to link. It's not
clear that the security benefits of this specification outweigh the
risks to the abilities of Web users.

(3) In the scope section, the item "Application awareness of powerful
features which may require explicit user permission to enable."
It's not clear whether this part of the scope is intended to
allow https://w3c.github.io/permissions/ to be a document in the
working group (which may be comfortable with, although some of us
have serious concerns about whether it is actually workable), or
whether it's intended to put
https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope
of the working group, which we believe should not be, because we
don't believe the WebAppSec WG should be in the role of policing the
specifications of other groups (which is not the role it has
historically held), and we believe that in general specifications
about how to write other specifications have not been successful,
particularly if they attempt to have any mandatory status.

At a minimum, it would be good to rephrase this item so that it
doesn't use the term "powerful features". It would probably be
preferable to explicitly state that work like the powerfulfeatures
draft is not in the scope of the working group.

(4) We believe the charter should have provision for asynchronous
decision making, perhaps as in
http://www.w3.org/2012/webapps/charter/#decisions .

[Anne van Kesteren]

On Thu, Jan 29, 2015 at 10:27 PM, Eric Rescorla <e...@rtfm.com> wrote:
> On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron <dba...@dbaron.org> wrote:
>> On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote:

>>> Also, can we request that they adopt a public asynchronous decision
>>> policy? I think we should start making that request from any WG.
>>
>> What do the Mozillians involved in the WG think about this?
>
> It depends what this means. If it means that decisions have to be confirmed
> on the list then fine. If it means that they can't be made F2F or on calls
> and then confirmed the list, then not so fine.

I would phrase the latter as the people at the F2F or call proposing a
decision and the list asynchronously deciding on it. So I think we are
in agreement. I would not want to preclude discussion outside of the
list, that seems unworkable and also impossible.


--
https://annevankesteren.nl/

[Anne van Kesteren]

Thanks David!

On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron <dba...@dbaron.org> wrote:
> I'm particularly interested in review of point (3) in what I've written;
> I feel that the argument I've written so far is weak, I think because I
> don't particularly understand the concerns about the powerfulfeatures
> draft.

So for what it's worth, I think I'm in disagreement with Eric about
what WebAppSec's role should/could be. Groups at the W3C that go at it
alone often make questionable choices when it comes to a number of
things that are not their expertise so having some amount of informal
oversight is definitely warranted. And the group of people that make
up WebAppSec definitely appears to have the competence.

I don't really see where else "powerful features" would go and we do
need it. (Now permissions API is another matter as that requires UX
expertise.)


--
https://annevankesteren.nl/

[Daniel Veditz]

On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron <dba...@dbaron.org> wrote:

> There are a number of problematic aspects to this charter to which
> we object:
>
> (1) The "Confinement with Origin Web Labels" deliverable is described
> in a way that makes it unclear what the deliverable would do. It
> should be clearer. Furthermore, the lack of clarity means we
> couldn't evaluate whether we are comfortable with it being in the
> charter.
>
> (2) The "Entry Point Regulation for Web Applications" deliverable seems
> to have serious risks of breaking the ability to link. It's not
> clear that the security benefits of this specification outweigh the
> risks to the abilities of Web users.
>

​If something is in the charter and there's an initial draft spec, that
doesn't mean the final spec will be the same or that the WG has to
ultimately approve the spec at all, does it? Both of these ideas are
promising attempts to address particular security issues that are prevalent
on the web. They also both raise issues that may or may not be addressable
as the WG refines the specs. As long as we can object to the final specs if
they go off the rails these concepts are worth exploring.

-Dan Veditz​

[L. David Baron]

Regarding (1), it sounds like you know what it is and perhaps could
explain it?

Regarding (2), does it make sense for the charter to say that it's a
potential deliverable, but that the working group may choose not to
proceed depending on tradeoffs?

-David

[Eric Rescorla]

This seems satisfactory to me.

On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron <dba...@dbaron.org> wrote:

> Here are the comments I have so far on this charter, based on the
> thread. I'd note that this is a relatively large set of demands to make
> in the charter review stage at the AC, especially for a recharter of a
> WG that we're involved in. So it may come across to W3C staff as
> somewhat demanding.
>

> I'm particularly interested in review of point (3) in what I've written;
> I feel that the argument I've written so far is weak, I think because I
> don't particularly understand the concerns about the powerfulfeatures
> draft.
>

> I also haven't included anything about Brian's objection to the
> suborigin namespaces work because I don't understand the objection, and
> I don't see how to extract any actionable charter feedback directly from
> Brian's message. (Or is it that the deliverable should be removed from
> the charter? If so, I could use an explanation as to why.)
>
> In any case, here's the feedback I have so far. Comments are
> welcome through roughly 5pm California time on Friday --
> particularly actionable ones that suggest how to revise this
> feedback or at least say how the charter should be different!
>
> (Sorry for not getting this gathered together sooner.)
>
> -David
>
>

> There are a number of problematic aspects to this charter to which
> we object:
>
> (1) The "Confinement with Origin Web Labels" deliverable is described
> in a way that makes it unclear what the deliverable would do. It
> should be clearer. Furthermore, the lack of clarity means we
> couldn't evaluate whether we are comfortable with it being in the
> charter.
>
> (2) The "Entry Point Regulation for Web Applications" deliverable seems
> to have serious risks of breaking the ability to link. It's not
> clear that the security benefits of this specification outweigh the
> risks to the abilities of Web users.
>

> (3) In the scope section, the item "Application awareness of powerful
> features which may require explicit user permission to enable."
> It's not clear whether this part of the scope is intended to
> allow https://w3c.github.io/permissions/ to be a document in the
> working group (which may be comfortable with, although some of us
> have serious concerns about whether it is actually workable), or
> whether it's intended to put
> https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope
> of the working group, which we believe should not be, because we
> don't believe the WebAppSec WG should be in the role of policing the
> specifications of other groups (which is not the role it has
> historically held), and we believe that in general specifications
> about how to write other specifications have not been successful,
> particularly if they attempt to have any mandatory status.
>
> At a minimum, it would be good to rephrase this item so that it
> doesn't use the term "powerful features". It would probably be
> preferable to explicitly state that work like the powerfulfeatures
> draft is not in the scope of the working group.
>
> (4) We believe the charter should have provision for asynchronous
> decision making, perhaps as in
> http://www.w3.org/2012/webapps/charter/#decisions .
>

[Eric Rescorla]

On Fri, Jan 30, 2015 at 2:14 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> Thanks David!
>

> On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron <dba...@dbaron.org> wrote:
> > I'm particularly interested in review of point (3) in what I've written;
> > I feel that the argument I've written so far is weak, I think because I
> > don't particularly understand the concerns about the powerfulfeatures
> > draft.
>

> So for what it's worth, I think I'm in disagreement with Eric about
> what WebAppSec's role should/could be. Groups at the W3C that go at it
> alone often make questionable choices when it comes to a number of
> things that are not their expertise so having some amount of informal
> oversight is definitely warranted. And the group of people that make
> up WebAppSec definitely appears to have the competence.
>

I think there's some competence there, certainly, but I'm not convinced
it represents a balanced set of the views on this topic. If there is to
be oversight, it should probably be at that TAG level, IMHO.

-Ekr

[L. David Baron]

On Friday 2015-01-30 10:18 -0800, Eric Rescorla wrote:
> I think there's some competence there, certainly, but I'm not convinced
> it represents a balanced set of the views on this topic. If there is to
> be oversight, it should probably be at that TAG level, IMHO.

For many topics, oversight from the TAG can mean oversight from the
one person on the TAG who's interested in the topic, which may be
less likely to be balanced...

-David

[L. David Baron]

On Friday 2015-01-30 11:14 +0100, Anne van Kesteren wrote:
> On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron <dba...@dbaron.org> wrote:
> > I'm particularly interested in review of point (3) in what I've written;
> > I feel that the argument I've written so far is weak, I think because I
> > don't particularly understand the concerns about the powerfulfeatures
> > draft.
>
> So for what it's worth, I think I'm in disagreement with Eric about
> what WebAppSec's role should/could be. Groups at the W3C that go at it
> alone often make questionable choices when it comes to a number of
> things that are not their expertise so having some amount of informal
> oversight is definitely warranted. And the group of people that make
> up WebAppSec definitely appears to have the competence.
>

> I don't really see where else "powerful features" would go and we do
> need it. (Now permissions API is another matter as that requires UX
> expertise.)

My understanding is that the objections to powerfulfeatures are over
the possibility of powerfulfeatures defining what is and isn't a
powerful feature, because that should be decided primarily by the
group developing the feature.

Is that the part you think is important, or is the part that you
think is important the part that defines algorithms for whether a
context/origin is sufficiently secure or trustworthy?

[L. David Baron]

Here's a revised set of comments, mainly changing:

- describes the objection to powerfulfeatures (part of objection (3))
more clearly, but also, I think, scopes the objection a bit more
narrowly

- makes objection (2) more explicit about being satisfied by an
option not to complete the work

-David

There are a number of problematic aspects to this charter to which
we object:

(1) The "Confinement with Origin Web Labels" deliverable is described
in a way that makes it unclear what the deliverable would do. It
should be clearer. Furthermore, the lack of clarity means we
couldn't evaluate whether we are comfortable with it being in the
charter.

(2) The "Entry Point Regulation for Web Applications" deliverable seems
to have serious risks of breaking the ability to link. It's not
clear that the security benefits of this specification outweigh the
risks to the abilities of Web users.

At the very least, the charter should be explicit that the group
may decide not to complete this item because of these tradeoffs.

(3) In the scope section, the item "Application awareness of powerful
features which may require explicit user permission to enable." It's
not clear whether this part of the scope is intended to allow
https://w3c.github.io/permissions/ to be a document in the working

group, or whether it's intended to put

https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope

of the working group. (I've heard separately that the powerfeatures
draft was intended to be in the charter as a deliverable but was
accidentally omitted.) It seems like this probably refers to the
Permissions API spec, and if it does, it would probably be best to
avoid the use of the term "powerful features" to avoid confusion.

We may be comfortable with the Permissions API spec, although some
of us have concerns about it, and for that perhaps the charter
should be explicit about potentially abandoning the work as in point
(2).

We have more serious concerns about the scope of the
powerfulfeatures spec. In particular, we don't believe the

WebAppSec WG should be in the role of policing the specifications of

other groups (which is not the role it has historically held) or
defining general (and likely overly-broad) rules to determine when a
feature has an important effect on a user's privacy or security.

Therefore, we would like to see producing enforceable definitions of
what is a powerful feature as explicitly out of scope for the Web
Application Security WG, since that determination should be made
primarily by the working group developing the feature, perhaps in
consultation with the Web Application Security WG.

(4) We believe the charter should have provision for asynchronous
decision making, perhaps as in

http://www.w3.org/2014/06/webapps-charter.html#decisions .

[Eric Rescorla]

This seems good to me.

[Martin Thomson]

Please note the need to liaise with the groups that are affected by the
permissions work. Otherwise, this is good.

[Brian Smith]

L. David Baron <dba...@dbaron.org> wrote:

> Is the argument you're making that if the site can serve the ads
> from the same hostname rather than having to use a different
> hostname to get same-origin protection, then ad-blocking (or
> tracking-blocking) tools will no longer be able to block the ads?

Yes.

Anyway, my point isn't to suggest that Mozilla should ask for this
item to be removed from the charter. Rather, my point is that this
item has some pretty big, non-obvious ramifications (not just related
to tracking) that Mozilla should understand. I think what you said
about it being described in an unclear way is a good response. Joel
Weinberger from the Chrome Security Team already explained a lot of it
to me privately. I recommend talking to him about it, if you want to
understand it better.

Cheers,
Brian

[Anne van Kesteren]

On Sat, Jan 31, 2015 at 12:15 AM, L. David Baron <dba...@dbaron.org> wrote:
> My understanding is that the objections to powerfulfeatures are over
> the possibility of powerfulfeatures defining what is and isn't a
> powerful feature, because that should be decided primarily by the
> group developing the feature.

It's not clear to me that other groups have done a good job of that,
historically. Delegating this to the TAG instead could be done I
suppose, except that a) the TAG has no security experts (although one
is elected now) and b) the TAG has endorsed this approach already.


--
https://annevankesteren.nl/

[Martin Thomson]

On Fri, Jan 30, 2015 at 10:40 PM, Brian Smith <br...@briansmith.org> wrote:

> Anyway, my point isn't to suggest that Mozilla should ask for this
> item to be removed from the charter. Rather, my point is that this
> item has some pretty big, non-obvious ramifications (not just related
> to tracking) that Mozilla should understand. I think what you said
> about it being described in an unclear way is a good response. Joel
> Weinberger from the Chrome Security Team already explained a lot of it
> to me privately. I recommend talking to him about it, if you want to
> understand it better.
>

Perhaps I don't understand very well either, but from your emails at least,
<script src="some://other/origin.js"/> isn't materially different from a
same-origin perspective as <script src="the://same/origin.js"/> given that
scripts adopt the including origin. So there isn't any advantage to the
site for this specific case.

Iframes are different of course, but I don't see how this materially
changes the game. After all, those tools would be able to use sub-origin
information to aid in identification in the same way that the site might
use them against them.

This all comes down to the information that the blocking tools have
available for use in identifying unwanted material. Those tools are
already far more sophisticated and granular than origin. If you think that
artificially impeding the escalation of this "arms race" is worthwhile, I
guess that's a fine position to hold, but I just can't see this particular
non-obvious ramification to be especially dangerous from this perspective.

The only thing that concerns me here is that it creates a division that
only advantages a small few. Sites big enough to have a need for multiple
distinct isolation zones. And what *won't* be partitioned. Will we also
ensure that permissions (geolocation, user media, etc...) are similarly
partitioned? Or will a large provider be able to share information that is
of advantage to it, while benefiting from isolation on what it wants
isolated.

I don't have a fundamental objection to that level of control, but it seems
like a lot of work. And I wonder who benefits.

[Eric Rescorla]

On Fri, Jan 30, 2015 at 3:15 PM, L. David Baron <dba...@dbaron.org> wrote:

> On Friday 2015-01-30 11:14 +0100, Anne van Kesteren wrote:

> > On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron <dba...@dbaron.org>
> wrote:
> > > I'm particularly interested in review of point (3) in what I've
> written;
> > > I feel that the argument I've written so far is weak, I think because I
> > > don't particularly understand the concerns about the powerfulfeatures
> > > draft.
> >
> > So for what it's worth, I think I'm in disagreement with Eric about
> > what WebAppSec's role should/could be. Groups at the W3C that go at it
> > alone often make questionable choices when it comes to a number of
> > things that are not their expertise so having some amount of informal
> > oversight is definitely warranted. And the group of people that make
> > up WebAppSec definitely appears to have the competence.
> >
> > I don't really see where else "powerful features" would go and we do
> > need it. (Now permissions API is another matter as that requires UX
> > expertise.)
>

> My understanding is that the objections to powerfulfeatures are over
> the possibility of powerfulfeatures defining what is and isn't a
> powerful feature, because that should be decided primarily by the
> group developing the feature.
>

That and the attempt by WebAppSec to mandate particular comsec
treatment for said features.

Is that the part you think is important, or is the part that you
> think is important the part that defines algorithms for whether a
> context/origin is sufficiently secure or trustworthy?

I'm fine with a taxonomy of the security level of contexts/origins.

-Ekr


>
> -David

>
> --
> 𝄞 L. David Baron http://dbaron.org/ 𝄂
> 𝄢 Mozilla https://www.mozilla.org/ 𝄂
> Before I built a wall I'd ask to know
> What I was walling in or walling out,
> And to whom I was like to give offense.
> - Robert Frost, Mending Wall (1914)
>

[Daniel Veditz]

A new version of the charter has been uploaded that hopefully addresses
these objections

On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron <dba...@dbaron.org> wrote:

> (1) The "Confinement with Origin Web Labels" deliverable is described
> in a way that makes it unclear what the deliverable would do. It
> should be clearer. Furthermore, the lack of clarity means we
> couldn't evaluate whether we are comfortable with it being in the
> charter.
>

​Brian's objections seem to be to a different "sub-origin" proposal from
Joel Weinberger of Google. COWL is essentially a data-tainting proposal
that builds on the capabilities of CSP to make it safer to use 3rd party
libraries and mashups. Having it in the charter is not a commitment that
Mozilla will implement this, but it's a promising idea and having it in the
charter means it's in scope for WASWG to discuss it.

Here's a slide deck explaining COWL: http://cowl.ws/talks/cowl-w3c.pdf
A more detailed paper (co-authored by Mozilla's own Dave Herman):
http://www.scs.stanford.edu/~deian/pubs/stefan:2014:protecting.pdf

​

(2) The "Entry Point Regulation for Web Applications" deliverable seems

> to have serious risks of breaking the ability to link. It's not
> clear that the security benefits of this specification outweigh the
> risks to the abilities of Web users.
>

The Working Group is also concerned that we not break the ability to do
links on the web. We have added that as an explicit requirement in the
charter. This work item is the most nebulous item in the charter. It has
some promising ideas that could help prevent CSRF type attacks; it might
also turn out to be completely unworkable and be dropped. We'd like it to
be in the charter so we can explore these concepts under the W3 IPR​
commitments of the WG members.


> (3)
> ​[...] It's not clear whether this part of the scope is intended to put
> [...]

> https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope

> of the working group, which we believe should not be, because we

> don't believe the WebAppSec WG should be in the role of policing the
> specifications of other groups (which is not the role it has

> historically held), and we believe that in general specifications
> about how to write other specifications have not been successful,
> particularly if they attempt to have any mandatory status.
>

​This item was indeed a reference to the Powerful Features spec, which has
been explicitly added to the deliverables section. The Web Application
Security WG has been directed by the TAG to "document best practices" on
this (http://www.w3.org/2001/tag/doc/web-https). The charter has been
clarified to note that only the "algorithm for determining if a given
context is sufficiently secure" will be normative, and advice on when a
feature might designate itself as requiring a secure context will be
non-normative.

(4) We believe the charter should have provision for asynchronous

> decision making, perhaps as in

> http://www.w3.org/2012/webapps/charter/#decisions .
>

​The charter was amended to add this. It's no change in practice but it's
nice to have it documented.

Updated charter:
https://w3c.github.io/webappsec/admin/webappsec-charter-2015.html​
Diffs:
https://github.com/w3c/webappsec/commit/433dcc996c092309b88c4e1ecad425ea80a49aed

-Dan Veditz

[Jonas Sicking]

On Wed, Feb 11, 2015 at 12:47 AM, Daniel Veditz <dve...@mozilla.com> wrote:
> (2) The "Entry Point Regulation for Web Applications" deliverable seems
>>
>> to have serious risks of breaking the ability to link. It's not
>> clear that the security benefits of this specification outweigh the
>> risks to the abilities of Web users.
>
> The Working Group is also concerned that we not break the ability to do
> links on the web. We have added that as an explicit requirement in the
> charter. This work item is the most nebulous item in the charter. It has
> some promising ideas that could help prevent CSRF type attacks; it might
> also turn out to be completely unworkable and be dropped. We'd like it to be
> in the charter so we can explore these concepts under the W3 IPR commitments
> of the WG members.

Has the group looked at expanding the feature set of cookies to allow
better CSRF protection?

I.e. it seems like it would be useful to be able to set a cookie but
declare that it should only be sent along with same-origin requests.
Or even allow even more stringent requirements such as "only send with
same-origin POST requests coming from pages under /foo/bar"?

That seems like it could provide the same type of CSRF protection
without breaking links.

Is that something that would fit in this new charter?

Another thing that would be very useful is page-specific or
tab-specific cookies. So that websites like gmail could keep you
logged in using different accounts in different tabs. Right now that
essentially require the website to add a user identifier to the URL of
all requests that are coming from a page, which is quite a demanding
task.

Note that I'm not talking about a UA feature which would allow the
user to use different cookie jars in different tabs. That can already
be built without any needed changes to the cookie spec.

/ Jonas

[Anne van Kesteren]

On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> Has the group looked at expanding the feature set of cookies to allow
> better CSRF protection?

Mike has:

https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html
https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html

Not many people are interested thus far is my understanding. Copied
Mike if he has anything to add.

> Another thing that would be very useful is page-specific or
> tab-specific cookies. So that websites like gmail could keep you
> logged in using different accounts in different tabs. Right now that
> essentially require the website to add a user identifier to the URL of
> all requests that are coming from a page, which is quite a demanding
> task.

I thought sessionStorage addressed this. (Although of course it's a
poor API since it's synchronous.)


--
https://annevankesteren.nl/

[Mike West]

On Wed, Feb 11, 2015 at 10:52 AM, Anne van Kesteren <ann...@annevk.nl>
wrote:

> On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> > Has the group looked at expanding the feature set of cookies to allow
> > better CSRF protection?
>

This doesn't seem like a good fit for WebAppSec. Various IETF groups have
generally been responsible for cookies.

> Mike has:
>
>
> https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html
>
> https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html
>
> Not many people are interested thus far is my understanding. Copied
> Mike if he has anything to add.

Some folks on the HTTP WG list (Martin in particular) had some interesting
feedback, but my general impression was that I was the only one excited
about it. I don't intend to let either spec die, as I think they're
potentially important, but I haven't prioritized building a prototype to
play with.

Coincidentally, I talked to a colleague just this morning who might have
some spare cycles coming up, so who knows. Maybe he'll build a prototype
for us. :)

-mike

--
Mike West <mk...@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Jonas Sicking]

On Wed, Feb 11, 2015 at 1:52 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>> Has the group looked at expanding the feature set of cookies to allow
>> better CSRF protection?
>

> Mike has:
>
> https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html
> https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html
>
> Not many people are interested thus far is my understanding. Copied
> Mike if he has anything to add.

I haven't ready the above proposals, so won't comment on those
specifically. But I'm certainly interested in seeing mozilla implement
something in this space.

Fixing cross-site cookies would remove one of the big security
advantages that other platforms have over the web.

>> Another thing that would be very useful is page-specific or
>> tab-specific cookies. So that websites like gmail could keep you
>> logged in using different accounts in different tabs. Right now that
>> essentially require the website to add a user identifier to the URL of
>> all requests that are coming from a page, which is quite a demanding
>> task.
>
> I thought sessionStorage addressed this. (Although of course it's a
> poor API since it's synchronous.)

That still requires that you manually adjust the URL all network
requests that you do through any API. I.e. all img.src, all <link
rel=stylesheet href=...>, all XHR requests, all WebSocket constructors
need to manually append an account identifier to the URL.

SessionStorage doesn't help there at all. Not any more than JS variables do.

/ Jonas

[Mike West]

On Wed, Feb 11, 2015 at 11:20 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> On Wed, Feb 11, 2015 at 1:52 AM, Anne van Kesteren <ann...@annevk.nl>
> wrote:
> > On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking <jo...@sicking.cc>
> wrote:
> >> Has the group looked at expanding the feature set of cookies to allow
> >> better CSRF protection?
> >
> > Mike has:
> >
> >
> https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html
> >
> https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html
> >
> > Not many people are interested thus far is my understanding. Copied
> > Mike if he has anything to add.
>
> I haven't ready the above proposals, so won't comment on those
> specifically. But I'm certainly interested in seeing mozilla implement
> something in this space.
>
> Fixing cross-site cookies would remove one of the big security
> advantages that other platforms have over the web.
>

Talk to Mozilla's own Mark Goodwin (CC'd. Hi, Mark!) who had similar ideas
(see http://people.mozilla.org/~mgoodwin/SameDomain/samedomain-latest.txt),
and who might be interested in prototyping.

[Eric Rescorla]

On Wed, Feb 11, 2015 at 12:47 AM, Daniel Veditz <dve...@mozilla.com> wrote:

> A new version of the charter has been uploaded that hopefully addresses
> these objections
>
> On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron <dba...@dbaron.org>
> wrote:
>
>> (1) The "Confinement with Origin Web Labels" deliverable is described
>> in a way that makes it unclear what the deliverable would do. It
>> should be clearer. Furthermore, the lack of clarity means we
>> couldn't evaluate whether we are comfortable with it being in the
>> charter.
>>
>
> ​Brian's objections seem to be to a different "sub-origin" proposal from
> Joel Weinberger of Google. COWL is essentially a data-tainting proposal
> that builds on the capabilities of CSP to make it safer to use 3rd party
> libraries and mashups. Having it in the charter is not a commitment that
> Mozilla will implement this, but it's a promising idea and having it in the
> charter means it's in scope for WASWG to discuss it.
>

My concern (as raised on the list) is that as phrased it appears to be an
open
research question how to actually "share data with untrusted code", for the
reasons that have been raised already. Presumably we shouldn't be proposing
standardization of things we don't actually know how to do. Were this IETF
I would suggest that this go to IRTF.

I'm fine with this being phrased as a belt-and-suspenders thing (along the
usual
lines of CSP) where you are just trying to prevent accidental leaks by the
confined
code.

-Ekr

[Brian Smith]

Daniel Veditz <dve...@mozilla.com> wrote:
> On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron <dba...@dbaron.org> wrote:
>>
>> (1) The "Confinement with Origin Web Labels" deliverable is described
>> in a way that makes it unclear what the deliverable would do. It
>> should be clearer. Furthermore, the lack of clarity means we
>> couldn't evaluate whether we are comfortable with it being in the
>> charter.
>
> Brian's objections seem to be to a different "sub-origin" proposal from Joel
> Weinberger of Google. COWL is essentially a data-tainting proposal that
> builds on the capabilities of CSP to make it safer to use 3rd party
> libraries and mashups. Having it in the charter is not a commitment that
> Mozilla will implement this, but it's a promising idea and having it in the
> charter means it's in scope for WASWG to discuss it.

Yes, I agree I was mistaken. You can read more about COWL at
http://cowl.ws/. Note, in particular, that the prototype is a
modification of Firefox. Also note this acknowledgement from the
second COWL paper: "We thank Bobby Holley, Blake Kaplan, Ian Melven,
Garret Robinson, Brian Smith, and Boris Zbarsky for helpful
discussions of the design and implementation of COWL."

> (2) The "Entry Point Regulation for Web Applications" deliverable seems
>>
>> to have serious risks of breaking the ability to link. It's not
>> clear that the security benefits of this specification outweigh the
>> risks to the abilities of Web users.
>
> The Working Group is also concerned that we not break the ability to do
> links on the web. We have added that as an explicit requirement in the
> charter. This work item is the most nebulous item in the charter. It has
> some promising ideas that could help prevent CSRF type attacks; it might
> also turn out to be completely unworkable and be dropped. We'd like it to be
> in the charter so we can explore these concepts under the W3 IPR commitments
> of the WG members.

I think it would be good to work out how much of the problem is solved
by same-origin cookies and related things, and how much is left over
for EPR to solve, before the working group dives into EPR. EPR and CSP
pinning look like they have a lot of overlap with app manifests.

> This item was indeed a reference to the Powerful Features spec, which has
> been explicitly added to the deliverables section. The Web Application
> Security WG has been directed by the TAG to "document best practices" on
> this (http://www.w3.org/2001/tag/doc/web-https). The charter has been
> clarified to note that only the "algorithm for determining if a given
> context is sufficiently secure" will be normative, and advice on when a
> feature might designate itself as requiring a secure context will be
> non-normative.

I think that "Powerful Features" is a terrible name, but I support the
webappsec work on it.

Cheers,
Brian

[Daniel Veditz]

On Wed, Feb 11, 2015 at 2:02 AM, Mike West <mk...@google.com> wrote:

>
>
>> https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html
>>
>> https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html
>>
>> Not many people are interested thus far is my understanding. Copied
>> Mike if he has anything to add.
>
>

> Some folks on the HTTP WG list (Martin in particular) had some interesting
> feedback, but my general impression was that I was the only one excited
> about it. I don't intend to let either spec die, as I think they're
> potentially important, but I haven't prioritized building a prototype to
> play with.
>

​A Mozilla colleague, Mark Goodwin, ​has worked on a nearly identical
proposal ("SameDomain" rather than "first-party") and tested a patch. Given
all the existing cookie specs live in the IETF I don't think WASWG is the
right place for it, but I'd dearly love to see it come to life.

https://github.com/mozmark/SameDomain-cookies/blob/master/samedomain.txt
https://bugzilla.mozilla.org/show_bug.cgi?id=795346

-
​Dan Veditz​