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

Ad 1)  Advanced analytics and performance management tools require to be loaded first on a page,  as they need to interact with the DOM and also ensure they can inject JavaScript monitoring code into frameworks like jQuery. So for simple page load scenarios I agree, but for complex JavaScript heavy single page apps the story is a different one.

Ad 2) Monitoring code can be inject in two ways a) by manually modifying the page or b) by doing this dynamically at runtime when the page is delivered by the web server. While a is simple it does not work in cases Third Party software is used or pages are created dynamically by frameworks that do not support injection. In these cases the script tag must be injected at the right place in a page to not cause any side effects. The simple case is to do this right after the head tag. In reality there are lots of cases when this does not work that easily. There are cases when a substantial part of the page has to be read to take the decision where to insert monitoring code. As the output has to be buffered this will result in a slow down of the page delivery.

So now we're adding a blocking resource (or several) to rendering and execution of every page? That by itself is a big red flag. If part of the intent here is to "avoid the observer effect", then I think we've already failed this criteria.

[Alois] It is up to the user how much observer effect is ok for him. Just as he decides this today when using analytics tools. In fact the observer effect will be less once the whole page does not need to be parsed  before sending it to the client in some weird cases.

Ad 3) This is about availability monitoring. The frequency of the event is not the question here. Availability monitoring is the top use cases for web ops. If this case was irrelevant why would we then have the Navigation Error spec at all?

Ad 4) This use case is about downloading e.g. a pdf file. There is no document in this case and therefore also no Resource Timing information.

Adding a full out cookie mechanism per origin, with ability to inject arbitrary scripts into execution context of the page seems very dangerous, and unnecessary -- now, every PDF and image file I download can walk my document and beacon random data to any destination? I'm not a security guy, but this seems like giant security hole.

[Alois] You are still in the control of your own domain and the cookies used there. I do not get the point here

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.

[Alois] This would work if a) we always would send back all information. This is not what RUM tools typically do b) This information is enough. This is not true if most performance relevant information is collected by other means like JavaScript instrumentation of single page apps.

To be clear, I'm not arguing against the proposal -- I think it would be great to have something like this, but I don't think this is the right mechanism. (Happy to be convinced otherwise).

ig





From: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>
Date: Thursday, August 1, 2013 1:48 AM
To: Alois Reitbauer <alois.reitbauer@compuware.com<mailto:alois.reitbauer@compuware.com>>
Cc: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: [JSPreflight] - First Draft of JavaScript Preflight Injection online


  *   The monitoring JavaScript becomes a single point of failure for the page if it does not load
  *   Modification of page source can result in unwanted side effects
  *   The monitoring JavaScript will not be loaded when the page cannot be loaded (e.g. because of a DNS error).
  *   It does not allow to collect performance data for non-HTML request (e.g. images, pdf downloads)

The first two seem contrived.. we all know that these scripts should be loaded in an async way, and we have well defined mechanisms to do so. And isn't the last point intentional and handled by ResourceTiming?

Really, it seems like the only new functionality here is point #3, which is error reporting for pages which failed to load? Which is a valid and interesting case, but having said that, do we have any idea or data on how frequently this occurs in the wild? I know this may be a chicken and the egg question, but I'm curious if the extra machinery (and another cookie-like mechanism is pretty heavy), is really warranted.

ig





On Mon, Jul 22, 2013 at 2:37 AM, Reitbauer, Alois <Alois.Reitbauer@compuware.com<mailto:Alois.Reitbauer@compuware.com>> wrote:
The first draft of the JavaScript Preflight Injection Specification is available. The goal of this specification is to provide a reliable means for collecting performance data in the browser without affecting page behaviour. You can find the latest version at http://w3c-test.org/webperf/specs/JSPreflightInjection/. Comments and contributions are welcome.

// Alois
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.

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.

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.