Re: CSP 1.1: Paths in source list definitions.

Emailed Mike with some concerns, and Mike responded.  Sharing this with 
the list.


-------- Original Message --------
Subject: 	Re: CSP 1.1: Paths in source list definitions.
Date: 	Tue, 25 Sep 2012 07:03:15 +0200
From: 	Mike West <mkwst@google.com>
To: 	Tanvi Vyas <tanvi@mozilla.com>
CC: 	dveditz@mozilla.com <dveditz@mozilla.com>



Hey Tanvi, Dan! Thanks for reaching out. Responses inline.

On Tue, Sep 25, 2012 at 12:11 AM, Tanvi Vyas <tanvi@mozilla.com 
<mailto:tanvi@mozilla.com>> wrote:

    I'm a little concerned that it doesn't allow file level restrictions
    , since the developer implementing the policy may not have control
    of the server that hosts a file included in his/her website. 
    Assumestartup.com <http://startup.com/> wants to include
    newanalytics.com/js/analytics.js
    <http://newanalytics.com/js/analytics.js>, but nothing else from
    newanalytics.com/js <http://newanalytics.com/js>. With the below
    proposal, startup.com <http://startup.com/> wouldn't be able to
    write a Content Security Policy that allows only analytics.js.

I see the current text as a starting point that captures more or less 
what I thought the group solidly agreed to, but I do hope it's clear 
that none of the edits I've made are final in any way. I'm putting out 
strawmen in the hopes of generating conversations like this one. :)

I'd like to do something along these lines. My initial pass at the 
feature behaved more or less like this, and I think it's a good option. 
We really only ran with a directory-level implementation because it was 
simple, was fairly clearly accepted by the group, and we knew we could 
always increase the granularity later.

    Perhaps we could distinguish between directories and filenames by
    looking for a trailing slash followed by a star, so that startup.com
    <http://startup.com> has an option to choose between
    newanalytics.com/js/analytics.js
    <http://newanalytics.com/js/analytics.js> or newanalytics.com/js/*
    <http://newanalytics.com/js/*>.


On the one hand, I like having an explicit wildcard at the end, as it 
makes it quite clear what's meant. On the other, a trailing '/' is 
probably just as explicit, and doesn't get us into weird discussions 
about supporting files named '*'. :)

I'd suggest that:
* newanalytics.com/js <http://newanalytics.com/js> match a file named "js"
* newanalytics.com/js/ <http://newanalytics.com/js/> match all files 
under a directory named "js", and
* newanalytics.com/js/analytics.js 
<http://newanalytics.com/js/analytics.js> match the specific file 
"analytics.js" under the directory named "js".

Does that make sense?

    On another note, for query parameters and fragments at the end of
    source expressions, perhaps we should just truncate that part of the
    source expression instead of ignoring the source.


This makes good sense. Looking back at the discussion Adam and I had 
while working through the experimental implementation[1], this is 
actually what we'd agreed on. It somehow morphed into a stricter check 
during the review process.

Note, however, that if we support individual files, we'll likely want to 
support query parameters as well, since those specify a variant of a 
file in a way that anchors don't.

    Wanted to get your thoughts (and Dan's, cc'ed) before I replied to
    the list.  Thanks!


Generally, I'd encourage you to post your concerns to the list. The more 
people we can get involved in the discussion, the more likely it is that 
the end result will actually be implemented. :)

[1]: https://bugs.webkit.org/show_bug.cgi?id=89750#c4

--
Mike West <mkwst@google.com <mailto:mkwst@google.com>>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91