Re: Line numbers in Content Security Policy reports

Hey Ian, response inline.

On Tue, Dec 18, 2012 at 9:45 AM, Ian Melven <imelven@mozilla.com> wrote:

> at the moment our CSP implementation sends the name of the source file, a
> sample
> of the content (as Neil has outlined) and the line number. The line number
> and name
> of source file are not always available, but are sent whenever they are.
>

When would a line-number not be available? In theory it should be possible
to grab a line number from script executing inline on a page, or of the
call to `eval` that triggered whatever code violated the policy.

I'm a little wary of grabbing text of the JavaScript file and passing it
on, especially in the context of JS injected by addons, which generally
tend to think of their code as private, and often aren't shy about
hardcoding tokens and other secrets.

How much value is there in getting some number of characters above and
beyond a line number or function name/stack?


> Is the concern around being able to identify addons a user has installed
> mainly
> around fingerprinting using the set of addons or more that the presence of
> the addon
> itself may be 'incriminating' in some way ?
>

Both, plus the question of hard-coded secrets above. To whatever extent
reasonable, CSP should get out of the way of user-installed extensions and
addons.

This isn't a problem specific to sampling the script, of course. It's a
general concern.


> We also currently (not per spec) restrict reports to being send to TLD+1
> as a
> small mitigation wrt the concerns around privacy or providing useful
> information to an attackers.
> I have heard complaints about this from sites who have deployed CSP,
> particularly since
> this restriction is specific to Gecko AFAIK.


Interesting. Are you seeing implementers with external report collection
servers, or just running their own servers on external domains?

-mike