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

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

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

You would need to instrument things so that you check if resources are
available, etc. It is a different way of doing things, but it doesn't seem
like that big of a mess to me. The potential new functionality is worth it,
imo.


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

You can't always inject the script tag. One place I can see this being
helpful is hosting content from static places like AWS S3. You can set HTTP
headers without needing to parse and modify the content.


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

I'm assuming this would not be possible. The spec should be cleaned up if
so, because I can't imagine that's the intended result :).

-- Chase