- From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- Date: Wed, 04 Feb 2015 12:18:24 -0500
- To: Mike West <mkwst@google.com>
- Cc: Crispin Cowan <crispin@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Deian Stefan <deian@cs.stanford.edu>, Joel Weinberger <jww@chromium.org>, Boris Chen <boris@tcell.io>, Dmitry Polyakov <dpolyakov@google.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
On Wed 2015-02-04 10:50:06 -0500, Mike West wrote:
> I don't think "one URL for the whole app" is what we're talking about.
> Consider https://github.com/w3c/webappsec. Clicking on `specs/` in the
> folder list "navigates" to that directory:
> https://github.com/w3c/webappsec/tree/master/specs. The URL is altered via
> `pushState()`, and the new data is loaded via XHR. Since the execution
> context remains the same, the CSP remains the same as well.
Ah, i see what you're saying, thanks. That removes the other weaknesses
of the model i'd raised (linkability, reporting, and debugging).
Still, the way for webapp design to achieve these goals with systems in
place today is to deliberately change the execution context when the app
needs to alter CSP.
Is it worth injecting potential vulnerabilities in CSP (allowing the
page to change its own policy) just to enable retaining the single
execution state?
--dkg
Received on Wednesday, 4 February 2015 17:18:49 UTC