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

Re: CSP and web analytics

From: <sird@rckc.at>
Date: Wed, 8 Jun 2011 13:43:01 -0500
Message-ID: <BANLkTi=+T1e=-5g81oz3yzErqzU+ojA7kA@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: John Wilander <john.wilander@owasp.org>, public-web-security@w3.org
Well, assuming that you use jQuery of course..

Anyway I was thinking more on:

<a href="#settings" data-event="click" data-value="['openPage','settings']">


var elems=document.getElementsByTagName("*");
for (var i=0;i<elems.length;i++){
  if(elems[i].getAttribute('data-event')){
    elems[i].addEventListener(elems[i].getAttribute('data-event'),function(){
      _trackEvent.apply(window,JSON.parse(this.getAttribute('data-value')));
    }.false);
  }
}

So you don't have to modify the script every time you add a new one.
-- Eduardo




On Wed, Jun 8, 2011 at 1:35 PM, Adam Barth <w3c@adambarth.com> wrote:
> 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:43:50 UTC

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