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.


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

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.

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>
> Date: Thursday, August 1, 2013 1:48 AM
> To: Alois Reitbauer <alois.reitbauer@compuware.com>
> Cc: "public-web-perf@w3.org" <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> 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.
>