Hello and welcome to the 3rd party party. 

Where we party like it's 1995. Because when it comes to  3rd party widgets in many ways it is 1995. 

So let's try to figure out what the party should look like in 2015. We have Ben and me representing 3rd party widget providers. 

Barbara's here representing a consumer of 3rd party content. 

Guy and Stephen are also on Barbara's side helping publishers deal with all the extravagance people like me and Ben put out there.  Quick overview: 3rd party content is commonly either scripts (like google analytics for example) or iframes. 

Or scripts that write iframes. 

So we understandably want to focus on how we load JavaScript and how we deal with iframes. 

Scripts that write iframes seems to be state of the art. 

You need iframes for the sandbox and you need the JavaScript as  sort of Trojan horse on the publisher page to help you for example resize  the iframe to fit the content or open another iframe if needed.  So loading someone else's script from some location you don't control  over the network. What could possibly go wrong? 

Ben wanted me to mentioned the recent Outbrain attack. Outbrain is a recommendation widget provider that was recently attacked by Syrian army folks. 

Messing up with the include script lets the attacker deface or simply redirect the pages that include the script. So for example redirect all Washington Post visitors to a different page. 

For an attacker, the third party providers are one-stop shop. Why would you break into a bunch of sites instead of breaking into a single widget provider. 

A widget's JS, included synchronously is a SPOF.

If your widget provider is blackholed in a country or an enterprise, you are effectively blocked too. 

And then there's performance.  So what is the state of the art with script includes? 

People still use regular blocking script tags despite all the evangelism we've put into async loading. 

There are also some crazier ideas like writing the iframe inside another frame or loading the script in an iframe. The goal being to unblock `window.onload` which is still important for some folks. 

Another thing on the crazier side is forcing refresh of the included script. Again using an iframe. The goal is to be able to load the scripts with far-future `Expires` header. Because 3rd party scripts are notoriously short-lived: 10-15-30 minutes so they can push urgent security updates. 

There's also the web-perf group part of w3c that discusses some interesting  script loading ideas and we can talk about them.  There is this idea I call C-3PO, or Common 3rd Party Objects. I posted about it some time ago, turns out Ben was also thinking about something similar. So maybe now is a good time to talk about it. 

The thing is that many of the third party script includes to the same thing: parse the page looking for a place to write an iframe, then resize it. 

What if we get together and write one such open-source script that works for all widgets. 

Then the publishers host this script, package it however they like and use it to write all the iframes for all widgets. The script will also listen to `postMessage`s from the widgets and do things for them, like open another iframe, remove the iframe, resize and so on. 

Why loading 5 scripts from 5 providers with total of 100-200K worth of code that largely does the same thing, instead of having 0 new HTTP requests?  Meanwhile in more foreseeable future we have all this new things happening. 

WebComponents. Sounds like third party widgets are ideal use case for web components. Anyone doing it? Are there any problems? From the publisher perspective is it any easier to  include a web component rather than the current state of a div+script. 

Sandbox attribute for iframes? Should we encourage people to use it? What would they disallow in a widget? 

Seamless iframes seem to be a thing that never happened. 

What about `srcdoc`? Dying too?  Content security policy is out there now. 

Should we encourage and guide publishers and/or widget providers to benefit?  Far-future and near-future ideas and standards are cool, but what about today? 

Barbara says sites today are "bombarded by scripts". She also challenges anyone to try and stand between the marketing folks and their widgets 

How do people setup budgets of bytes or milliseconds you can spend on 3rd party content. Stephen is curious about this and how do you monitor and keep 3rd parties in check from an ops perspective. 

Some of the third party content is not that very well written either:  document.write and so on. How do people deal with these? 

Guy says according to the httparchive the number of domains sites are using is  going up. And the number is mostly attributed to third parties.

He has some ideas around using common domains, some borderline crazy like copying cookies. Or something more doable like hosting all widgets static resources on a common domain? 

So instead of serving the like button script and sprite from fb-whatever-akamai.net can I use c3po.org hosted by Akamai together with a bunch of other providers.  Mobile is here. Finally. 

What does it mean for widgets? Is it simply making the performance problems even more painful. Do people even use that many 3rd parties on mobile sites.