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

Re: WebAppSec re-charter status

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 12 Feb 2015 21:07:20 +0100
Message-ID: <CADnb78iTDB4ETCoo8kixy=bv9HGB1Znk-0MmiK2bEEmDVHoZMg@mail.gmail.com>
To: David Ross <drx@google.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Deian Stefan <deian@cs.stanford.edu>, 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>, Dan Veditz <dveditz@mozilla.com>, Mounir Lamouri <mlamouri@google.com>, David Baron <dbaron@dbaron.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Feb 12, 2015 at 8:01 PM, David Ross <drx@google.com> wrote:
>> Why does the intended audience of the feature matter? What matters is
>> what it does and how it can be used, no?
> I'll assume that the primary concern is with apps / sites that
> unintentionally block deep links due to legitimate EPR usage.  In this case
> the intended audience matters because it's targeted.

I'm not sure what the primary concern is. Making it impossible to
navigate to (or embed?) resources without going through a front door,
legitimate or not, is a concern.

>> There are other ways we could limit some of these too I think. E.g. by
>> introducing first-party and/or same-origin cookies.
> I think that would address XSRF but not XSS.  (?)

Well, that's one down, one to go.

So XSS is still a concern, but CSP helps with that. E.g. you could
have very restrictive CSP on all but a few pages that you control
carefully. That would be much less damaging to the web I think.

Received on Thursday, 12 February 2015 20:07:43 UTC

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