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

On Thu, Aug 1, 2013 at 11:12 AM, Ilya Grigorik <igrigorik@google.com> wrote:

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

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.

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.

-- Chase