- From: <sird@rckc.at>
- Date: Wed, 8 Jun 2011 13:43:01 -0500
- 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