W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

Re: CSP and web analytics

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 8 Jun 2011 11:35:14 -0700
Message-ID: <BANLkTi=t0N3v7uDcW2r0j0oMzyVLcQmSZg@mail.gmail.com>
To: "sird@rckc.at" <sird@rckc.at>
Cc: John Wilander <john.wilander@owasp.org>, public-web-security@w3.org
On Wed, Jun 8, 2011 at 11:30 AM, sird@rckc.at <sird@rckc.at> wrote:
> The reason is because the Google Analytics team probably doesn't know about CSP.
>
> Anyway, CSP is a showstopper for people that use Analytics, event
> tracking for example uses HTML event handlers to trigger "events",
> which would be really boring to implement without inline event
> handlers.
>
> For example:
>
> <a href="#settings" onclick="_trackEvent('openPage','settings')">Settings</a>
>
> If you want this to work with CSP you need to add an id to the anchor,
> then in another script do:
> document.getElementById(...).addEventListener(...,function(){
>    _trackEvent('openPage','settings')
> }, false)
>
> Or something like that (maybe you can make it easier with
> data-event/data-page attributes or so).

Or just:

$("#settings").live("click", function() {
_trackEvent('openPage','settings'); });

in jQuery speak.

It's actually the recommend design pattern because it separates
behavior from semantics.

Adam


> So the question would be, what to suggest to the Google Analytics team..
>
> Changing the code to something like:
>
> <script src="<analytics url>" type="text/javascript" inline async>{
>  account: ["UA-1234-12","UA-123-11"]
> }</script>
>
> might be a solution, but if none of their customers are using CSP, and
> no one asks for it.. they will lower the priority so low it will never
> get actually implemented.
>
> -- Eduardo
>
>
>
>
> On Wed, Jun 8, 2011 at 1:21 PM, John Wilander <john.wilander@owasp.org> wrote:
>> I agree web analytics are easier to cspify (pronounced 'cisspify' :) than
>> 3rd party ads but I think they're first in line to obstruct CSP adoption. A
>> lot of organizations who I'd like to see implement CSP in the first round
>> don't have 3rd party ads, such as banks and insurance companies. Also, web
>> apps as opposed to web sites are less likely to have 3rd party code-based
>> content.
>>
>> Eduardo, thanks for the info on Google Analytics. I figured that was the
>> case and as far as I can see ga.js doesn't generate any inline code blocks
>> but we'd have to check it with CSP to be sure. Any idea why the GA guides
>> don't show or even suggest the file solution? Seems unlikely the majority of
>> developers will fix this on their own, rather just follow the guide. Maybe
>> we can suggest the Google Analytics team to change it?
>>
>> I will set up a meeting with some Omniture guys to discuss the issue with
>> them. Will get back on that one.
>>
>>    /John
>>
>> 2011/6/8 Adam Barth <w3c@adambarth.com>
>>>
>>> Yeah, one of the challenges for CSP is that it imposes constraints on
>>> how you integrate with third-parties.  Web analytics is probably one
>>> of the easier examples of this issue.  Advertising is probably more
>>> challenging.  My sense is that CSP succeeding on this dimension is
>>> going to take a while.  Enough developers need to be interested in
>>> using the feature that providers of these third-party services have an
>>> incentive to play nicely with CSP.
>>>
>>> Adam
>>>
>>>
>>> On Wed, Jun 8, 2011 at 4:19 AM, John Wilander <john.wilander@owasp.org>
>>> wrote:
>>> > Hi PubWebSec!
>>> >
>>> > To get ready for Content Security Policy in production organizations
>>> > have to
>>> > get JavaScript guidelines in place stating no inline JavaScript, only
>>> > JavaScript in files. That's fine for in-house developers but I'm
>>> > starting to
>>> > get worried about web analytics tools such as Omniture SiteCatalyst and
>>> > Google Analytics. These are very popular out there and the decision to
>>> > use
>>> > them are typically made by managers closer to money than the security
>>> > department typically is.
>>> >
>>> > I've been using both SiteCatalyst and Analytics before, both using
>>> > inline
>>> > JavaScript. Looking at their online documentation and tutorials I only
>>> > see
>>> > inline solutions.
>>> >
>>> > Example from SiteCatalyst tutorial
>>> > (https://developer.omniture.com/en_US/get-started/sitecatalyst-tagging):
>>> > [bla, bla] return to the Page Code tab and copy all of the code in the
>>> > tab.
>>> > In the HTML files, locate the comment that says Begin Paste the
>>> > SiteCatalyst
>>> > JavaScript Page code here and then paste the Page Code below the
>>> > comment.
>>> >
>>> > Example from Analytics tutorial
>>> >
>>> > (http://www.google.com/support/googleanalytics/bin/answer.py?answer=174090):
>>> > In the Profile Settings page, click the "Check Status" link. You'll see
>>> > something similar to the code snippet below. (...) Once you find the
>>> > code
>>> > snippet, copy and paste it into your web page, just before the closing
>>> > </head> tag.
>>> >
>>> > All of this will be a show stopper for CSP. I think we have to start
>>> > working
>>> > with the web analytics vendors to 1) find working file-only solutions,
>>> > and
>>> > 2) write good tutorials on how to get file-only web analytics working..
>>> > We
>>> > might be successful since developers in general consider this "paste the
>>> > JavaScript into your page" practice quite ugly.
>>> >
>>> > Thoughts?
>>> >
>>> >    Regards, John
>>> >
>>> > --
>>> > John Wilander, https://twitter.com/johnwilander
>>> > Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
>>> > Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee
>>> > My music http://www.johnwilander.com
>>> >
>>> >
>>
>>
>>
>> --
>> John Wilander, https://twitter.com/johnwilander
>> Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
>> Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee
>>
>
Received on Wednesday, 8 June 2011 18:36:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC