- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 8 Jun 2011 11:35:14 -0700
- 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