layout: true class: center, middle background-image: url(media/taking_back_control_free_gray.jpg) --- # Taking Back Control .center[Yoav Weiss  |   @yoavweiss] .right[] --- ## Our ecosystem is # Broken! ??? I want to talk about third parties, and the reason for that is that I think that *Our ecosystem is broken*. And you are suffering as a result. You go to conferences, listen to people talking about performance and why it matters, set up a performance budget, optimize all your images and make them responsive, clear out the critical rendering path to make it lightning fast, and then a requirement from business comes along to add some tag to your HTML. And this tags comes along, and invites his other tag friends, and together they all... relieve themselves all over your hard performance work! You are suffering! Your users are suffering! --- ## Who is to blame? ??? Is it the business person's fault for making you add that third party tag? The business person in this story is not evil. They're just trying to make sure there's money to pay everyone's salaries. And the "tag", the third party, is not evil either. It's just trying to be the best analytics/ad/tracker/click-grabber/attention-hoarder provider that it can be. It is trying to bump up the metrics that pay its own salaries. But it doesn't care about your user's performance and experience. Not really. Not profoundly. Again, not because it's evil, but because --- ## Our ecosystem is # Broken! ??? So, that's what I want to talk about. I want to outline the problems that third parties bring along with them. then I'll describe the current workarounds for some of these problems, and I call them workarounds because they take care of some of the symptoms rather than the underlying illness. But they are things that you can apply today in your projects and have users that are safer and happier. And once I'm done with all that, I'll propose mechanisms that can help us fix the underlying issues and bring back control to where it belongs. To your hands. --- # #1 - The Problem ---  ??? http://www.theverge.com/2015/7/20/9002721/the-mobile-web-sucks http://blog.lmorchard.com/2015/07/22/the-verge-web-sucks/ Almost a year ago, the verge has published an article about why the mobile Web is so inherently broken, stating performance as a huge concern. --- .wide[] ??? A response post by a Mozillian examined the verge's own site and came up with some interesting conclusions. Turns out, the site's content requires about ~1MB to load, which is pretty heavy. But then, the site continues on to load 11 more megabytes, including 7MB of javascript. That's 7MB on the network. Now imagine that a browser has to ungzip that, parse all that JavaScript, run it, and store it in memory for the lifetime of the site's tab. Most of that stuff is third party content. And I do believe the Verge have no desire that their site's performance would be dragged down by those third parties. But it did. Because their engineers, which care about performance and proper UX, had no actual saying in the matter. ---  .footnote[https://twitter.com/jason_kint/status/720129850225401856] --- ## Ads are getting worse ??? On top of that Web sites are extremely content poor - for many sites, the space reserved for ads is much larger than the one reserver for content. Ads are intrusive, confusing, pretending to be the real content, use as an attack vector, start playing audio in the background... What I'm about to say may be revolutionary, but users don't seem to like it. And the ecosystem responds --- ## Ad blockers ??? In Web standards browsers are defined as "user agents". They're there to act on behalf of the user. Many browsers (or user agents) have an extension mechanism that is designed to give users control over their content. And when user experience have been neglected, users will be taking that control by force. In the last couple of years we have seen a steady rise in users installing ad blockers, for all the reasons we mentioned before. They have been growing as browser extensions on desktops for a long while, and iOS content blockers, that showed up with iOS9, made them mainstream. ---  .footnote[https://twitter.com/brucel/status/727773013479919617] ??? Browsers are now integrating adblockers natively, and get significantly faster loading sites. Opera are doing it, Brave, a new contender in the browser market is doing it. ---  .footnote[https://blog.pagefair.com/2015/ad-blocking-report/] ??? Today, depending on your audience, there's a good chance that a large chunk of your users have them installed. In europe it seems to range from 10-40%, and I've talked to publishers that told me that according to their analysis, it's over 50% for them. Such an analysis is particularly difficult, because analytics scripts are often blocked by ad blockers as well, so figuring that out requires comparing server side logs and client side analytics. --- ## Walled gardens <div style="width: 60%;margin: auto"> .inline.half[] .inline.half[] </div> ??? At the same time, aggregators and content embedders see their users suffer. They see their users afraid to click on links as we have trained users that "links are slow" (or at least some of them are). So, what are content aggregators to do? They build their own formats, that basically prevent all that 3rd party madness. Apple came up with Apple News, where they control the content and its display. (and show ads of their own) Facebook followed with Instant Articles, and Google came up with their own initiative: AMP, which stands for Accelerated Mobile Pages. All these formats are basically a recreation of RSS or WAP. They force publishers to "distill" their content so that it would be something that users can view without distractions. --- ## AMP  ??? AMP, in it's essence is a subset of HTML, with a mandatory Javascript framework. Certain elements are banned in favor of custom elements that replace their functionality. AMP is not the fastest way to build a site. The framework does many smart things, but you could build a faster site without it. What the framework (and the AMP verification mechanism) give us is ... --- ## Guaranteed Performance ??? And these other formats are the same. They're all about being able to guaranty fast loading of content, so that users can un-learn their current "clicking on links is slow and expensive" habit. Embedders use their position in order to favor such "guranteed to be fast" content and provide it visibility benefits. It get better search rankings, better UI emphasizing it (and driving traffic to it), or share it to more people. For that reason, these formats run a risk of forking the Web. Publishers now need to publish their content in multiple formats to satisfy all these different walled gardens. And the SEO and visibility benefits, make sure that they *have* to do it. --- ## Advertisers got the message ??? The advertising industry that previously was dismissive of previous criticism of its ads being too heavy and too invasive, started taking notes. With Ad blockers now hitting mainstream and with a non-negligable % of users having ad blockers on, they kinda had to. The IAB - Interactive Advertising Bureau - understood the huge risk that users taking matters to their own hands poses on the ad industry, and started a few initiatives that mitigate the negative impact of ads. --- ## LEAN .center[] ??? The IAB came up with two initiatives, one targeted at advertisers telling them their ads need need to be LEAN: Lightweight, encrypted (so served over HTTPS), Ad-choice supported (where ad choice is a UI embedded inside the ad enabling users to opt-out, at least in theory), and finally Non-Invasive (including some UX guidelines that ads should take into account). --- ## DEAL .center[] ??? At the same time, they also came up with an initiative targeted at publishers called DEAL: Detect Ad blockers, Explain, Ask them to turn them off, Limit access to ad blocker users. http://www.iab.com/news/new-iab-tech-lab-ad-blocking-primer/ http://www.iab.com/news/lean/ http://www.iab.com/guidelines/safeframe/ --- .center[] --- .center[] --- ## Ad blocker blockers ??? New startups and technology is now being built our current generation ad-blockers and how you can work around them and display your ads regardless of the user's choice. http://thenextweb.com/apps/2016/02/11/around-and-around-we-go/ - ad-blocker-blocker-blocker --- ## Ad blocker blocker blockers ??? And of course, ad blockers are learning these technologies and figure out ways to block them as well. An arms race in the war on ads. And like most wars, the main people that benefit are those who sell the ammo. --- # #2 - Workarounds ??? What can you do about third parties now? There are several techniques that you can use --- ## Async loading ??? You should almost never load external scripts syncronously, and that goes double to third party content. All providers now give you async snippets and you should use them. --- # Panacea? ??? You still have arbitrary third party code running on your domain, with full access to everything. Browsers don't necessarily deprioritize async scripts, so these scripts are likely to get priority over your content. --- ## Preconnect and preload .center[`<link rel=preconnect>`] .center[`<link rel=preload>`] ??? You can use the new preconnect link rel in order to preconnect to your third party providers and take that part of their download outside of the critical path. You can use the preload directive in order to preemtively download resources that you'd need later on but are discovered late in the page loading process. --- # Panacea? ??? A lot of the resources are dynamic and come from arbitrary host downloading arbitrary resources. You cannot know what they would be in advance. Arguably, perf aware third parties could have used the same mechanism to accelerate their third parties (e.g. they may know what the host is in advance) --- ## Service Workers ??? Service workers give you new means of control over third party content. You can use them to make sure that if a resource doesn't respond within X seconds, you return a null response to the browser, making sure that it is not blocking rendering. (what we often refer to as front end SPOF) So if some resource's host is down, your users can carry on with their lives, and have access to the rest of the content that they managed to load. You can use them to log third party request number, separate hosts, etc and complain to your third party providers if these don't match your expectations. You cannot really use them to have better insights into your third parties beyond URLS, as the responses are opaques and you cannot see what they are or what's their size. // TODO: code sample // TODO: do service workers see the requests of their iframes? Are they opaque? Or just not captured as they're out of scope? --- # Panacea? ??? It helps avoid third party induced SPOF, but cannot really enforce many policies beyond that. You cannot know the size of resources. You cannot intervene on behalf of the user when third party content is going wild. You can only log (slightly indirect metrics) and whine about them. --- ## Framing ??? You should use frames to further isolate your third party content from the rest of the page. No all third parties support that as some want access to the main page for various reasons. Framing also goes a long way to protect your users from rogue third parties. --- ## `<iframe sandbox>` ??? Sandbox is a feature built on top of frames that enables you to shut down what these frames can do. Sandbox is an opt-in feature, so if you just include the attribute, that frame is effectively sandboxed and cannot do much: It cannot run scripts, cannot open modal dialogs, cannot submit forms, cannot open popups, cannot access the top navigation, cannot run plugins, etc. It's really limited in what it can do. --- ## `<iframe sandbox="allow-scripts">` ??? You can then relax some of those restrictions that you find appropriate in order to enable some iframe functionality, without compromising security and performance. // TODO: explain what sandbox is, write samples, decide which attributes would be sane alternatives --- # SafeFrame ??? SafeFrame may be able to help isolating third parties while providing them with the info they need from the main page. --- # Panacea? ??? Well frameing and sandboxing our third parties is a good first step, but it's not always possible, and even when it is possible, iframes can still download arbitrary amounts of data, they can still hog the CPU (and in most browsers today, the main thread). So, it's a very good mitigation technique, but can't save us on its own. --- # Content-Security-Policy ??? Content Security Policy enables you to limit what resources the main page can access, so it enables you to limit the hosts that certain resources can be downloaded from. In some cases that enables you to create limits so that third parties for example can't download video and audio. You can effectively apply sandboxing on the main content. enable you to enforce CSP rules on frames, so that the same can apply to third parties inside frames. TODO: in practice that means.... // TODO: show code samples --- # Panacea? --- ## You're a third party? ??? If you're a third party a want to be a better citizen, what can you do? Well the obvious things would be to stop downloading a ton of data and work well inside of frames (potentailly with SafeFrame). But there are a few new standards that can help you take it a step further --- ## Passive touch events .left[ ```javascript document.addEventListener('touchstart', handler, { passive: true });``` ] ### https://github.com/WICG/EventListenerOptions/blob/gh-pages/explainer.md ??? --- ## Intersection observers ### https://github.com/WICG/IntersectionObserver/blob/gh-pages/explainer.md ??? Another new standard that can help you be a nice third part is IntersectionObserver. I'm not going to dive into the details but this API lets you get notifications when certain elements in the page move into the visible viewport or close enough to it. Up until IntersectionObserver, you could get that info by listening to scrolling events and poll the various elements during them. That was hacky, caused performance issues (since scrolling events listening can have perf costs), and resulted in a lot of jank. Intersection Observer, allows you to get the same info without all that damage. --- # #3 - The Plan™ ??? So, we looked into mitigations, but how do we fix the ecosystem? How do we align everyone's incentives with the incentives of our users? How do we ensure that it is in everyone's best interests to provide a reasonable user experience? --- ## Do-Not-Track ??? The first sign of "civil unrest" with the ad ecosystem were a few years back with the Do-Not-Track proposal. Users were getting uneasy with the tracking behavior that many sites exibited, and the addition of a header signifying that the user has opted-in to prefer their privacy over targeted ads. Turns out, a *lot* of users prefer that. So, when IE 10 added DNT enabling as a specific question in their startup dialog. The IAB, which initially supported the proposal and said he'd encourage its members to respect it, backed out. DNT still lives as a tooth-less header that does nothing in particular. There's no way to enforce it, which makes it meaningless. The main take away here is that whatever solution we'd come up with, it has to be enforceable. --- ## Content-Security-Policy ??? We saw CSP as a mitigation mechanism that has specific properties that can be useful to us for performance, even if its goal is security. But, CSP as a mechanism has many useful properties that we may want to copy. It has a reporting infrastructure, can be applies to iframes, etc. And it's a successful model of how we can apply various policies on a page and its third parties. Plus, for some of our goals, CSP can be extended to address our use-cases! ---  ??? Both of these technologies is what I had in mind when I started blabbing about a standard AMP-style enforecement mechanisms. Whatever we come up with, has to be enforecable by the browser. Talking to Chrome and AMP folks about it, the CSP model kept coming up, where the author can enforce a policy and the site as well as third parties *have* to comply or the browser will break the site on them. The name Content Performance Policy floated around (originally proposed by the AMP folks). ---  ??? The original proposal included many directives, some more realistic than others. But the main intention was to create a way for sites and third parties to declare "I'm performant as I'm not doing X which is known to be performance kryptonite". And for such a declaration to have any meaning, the browser has to be able to take them up on their word. The browser has to be able to enforce that the declaration is truthful or else Everything Breaks™ Another meeting between cristalized the direction in which this was going, and enabled us to break up CPP into 4 different proposals. --- ## Feature Policy  ??? The first part is about limiting harmful Web platform features. Features that cause the browser to halt, interrupt the user experience, or a combination of the two. Like I said before, developers can make sure that they don't use awful platform features. They can verify that their Javascript doesn't include document.write or alerts. They can make sure not to use sync XHR, which causes the main UI thread to halt on the network. What they cannot do is guaranty that other people's scripts that they add to their pages don't do that. --- ## That Other Team™ ??? More than that, other people in this scenario doesn't have to mean third parties. There's are always That Other Team™. You know who I'm talking about. those slackers. Always cutting corners. They just don't care as much as you do. Sure, you could add some build system in place to make sure they fit the performance budget, but detecting that they are not using those nasty features is not always trivial. So, we want some mechanism that enables you to turn off these features and make sure that when them Other People™ use them, the browser will just laugh in their face and make them feel bad about themselves. What are the features that we're talking about? --- ## sync-script ??? * Syncronous scripts - using scripts in a synchronous way halts the parser and results in a significant delay. The preloader enables us to get rid of *some* of that damage, but not all of it. Sync scripts should be discouraged. --- ## sync-xhr ??? * Synchronous XMLHttpRequest - big no-no but often used as a hack in analytics scripts. No one should use it now that we have the Beacon API. --- ## docwrite ??? * Document.write - one of those awful features that keeps getting (ab)used, mainly by ad providers. There are a few others features that this proposal disables, mostly for security reasons. The proposal is still very much at flux, so... watch this space. --- ### `Feature-Policy: {"disable":["sync-xhr","sync-script","docwrite"]}` ??? * Policy applies to the top-level document and inherited by all iframes. * Top level document can make the policy stricter for certain iframes. * Reporting mode that indicates violations, so that the policy can be tested in the wild before being deployed in "break the page" mode. --- ## Resource size limits ??? The next part that needs tackling about third parties is limiting the resource sizes that they download. Part of that "click fear" we talked about earlier is the fact that users don't know how much a certain site is going to cost them. Bandwidth can be expensive, and sites have been getting heavier and heavier. A large part of that is the content itself, but a good chunk is third party resources. Embedders today have no way to guaranty the user won't pay excessively for the link they're presenting them. And people that write Web sites have no way to guaranty their site will not be an extreme burden on their user's data plan unless they have zero third party components. --- ## Resource size limits ??? So, we're proposing to introduce some policy that will ensure that the browser enforces resource dimensions limits, which enable embedders (and users) to know what they're getting into before they click a link, and enables the site's developers to be in control in that respect. If a third party tries to download too many resources or ones that are too large, the browser will make sure that it won't happen. Again, the browser is acting as the enforcer. How would such a policy look like? There's no concrete proposal just yet, but it's likely to look similar to the sandbox one. Overall site limit for the various resource types as well as the entire bytesize. Then (potential) further limitations on iframes, as well as a reporting mechanism. --- ## CPU and bandwidth priority ??? Similarly to resource downloads, there's no way to guaranty that *your* content gets priority over third party content, as well as that critical third party content would get priority over another one, which is less important. There's no way to tell the browser that certain content should get all the CPU power and network bandwidth that it needs, and that another one should only get scraps. --- .left[```html <meta http-equiv="cgroup" name="ads" content="cpu-share 0.2; cpu-priority medium; net-share 0.8; net-priority medium"> <script cgroup="ads" src="/ads-manager.js" async> </script> <iframe cgroup="ads" src="//3rdparty.com/widget"> </iframe> ```] ??? Ilya grigorik proposed something he called "cgroups for the web" as a way to tackle that issue, and make sure that not "all content is created equal". --- ## User experience ??? The fourth group that needs tackling and is still a big mistery is the "User experience" part. How can a browser enforce the fact that ads are not "annoying"? That's something we still need to put some thought into, as the definition of annoying is fuzzy and subjective. --- ## Privacy??? ??? You may have noticed that none of this tackles the privacy aspects of the ad ecosystem. The main reason for that is that tracking is done server side and therefore not-trivial to enforce from the client side. The browser has no visibility into what the server is doing with the user's data. --- ## What do such policies enable? --- ## Control for site owners --- ## Smarter embedders ??? Embedders can define their own criteria as to what they consider "fast" content, and promote sites that declare that as a policy. --- ## Smarter ad blockers ??? Today ad blocker block based on a list of hosts. That's both inaccurate and fragile. Performance-related policies can enable them to block third-party resources that might be slow, but letting through guaranteed-to-be-fast resources and frames. --- background-image: url(media/unicorn.jpg) layout: true class: center, middle --- # Happier users --- # Thank you! .center[Yoav Weiss  |   @yoavweiss]  --- # Questions? --- ## Acknowledgements Taking back control - https://www.flickr.com/photos/jastrow/6347298190/ Unicorn - https://www.flickr.com/photos/128161151@N08/22748457244