Re: [JSPreflight] - First Draft of JavaScript Preflight Injection online

FWIW, CSP avoids all of this by standardizing what gets reported and providing the beacon URL:
http://www.w3.org/TR/CSP/#sample-violation-report

^ I think that's the right way to do it -- all we need is NavTiming JSON object to be sent back. No need for cookies or other complications. And yes, I appreciate that this disallows you from being able to instrument arbitrary code on my page -- but personally I think that's the right behavior. If you want to instrument custom application code, then the site owner can add the right snippet.

If timing were all that people wanted, there would be better ways. However, people generally want other types of data as well, and what that data is is evolving over time. Single page web apps are an example of a somewhat new paradigm that affects how analytics are measured and reported. A general approach using instrumentation scripts is reasonable, imo.

Right, now I want to instrument my app with some arbitrary event beacons.. How do I register those with an injected script? Take GA for example.. when I include the <script> tag, I know what I'll get and when (and if) its loaded by the browser. With a "side load" injection, I can't count on the _gaq object being there (e.g. older browser) in which case now I need to implement a side-loader for the side-loader - that's a mess.

[Alois} GA is a bad example here as it fully relies on the user to put the tag in the correct place. I circumvents the problem of finding the right inject place. Modern RUM solutions on the other hand inject their JS code at runtime without having the user to manually touch their pages.  In the GA case you simply might not need this functionality.

[

If you really need it, you can inject the script tag right at the beginning of the page, without even parsing any of it (or buffering anything) and get the same results as described in the spec.

[Alois] If it were that simple :-). In the general case you are right and that's what we do today. However, there are tons of cases where this breaks the page. I can provide some real world examples where this gets really tricky to impossible.  This approach is also not applicable to the case where the page cannot be loaded.

All of this is gated upon the site owners enabling the functionality. There should be no way for some nefarious "other" entity to insert a preflighted JS script for domains they don't own. And although this may impact page load performance, it is up to the site owner to decide if the trade off is worth it.

If we allow adding this beacon to arbitrary resources (e.g. image asset), then that's exactly what we'll get. I'll hotlink an image on my site, and all of the sudden, I have third party JS executing in the context of my page.

[Alois] So your proposal is, to only allow this for pages?

ig
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Geb?ude G.