WebBundles Harmful to Content Blocking, Security Tools, and the Open Web (Standards Updates #2)


Level 62
Mar 29, 2018
In a Nutshell ...
Google is proposing a new standard called WebBundles. This standard allows websites to “bundle” resources together, and will make it impossible for browsers to reason about sub-resources by URL. This threatens to change the Web from a hyperlinked collection of resources (that can be audited, selectively fetched, or even replaced), to opaque all-or-nothing “blobs” (like PDFs or SWFs). Organizations, users, researchers and regulators who believe in an open, user-serving, transparent Web should oppose this standard. While we appreciate the problems the WebBundles and related proposals aim to solve,[1] we believe there are other, better ways of achieving the same ends without compromising the open, transparent, user-first nature of the Web. One potential alternative is to use signed commitments over independently-fetched subresources. These alternatives would fill a separate post, and some have already been shared with spec authors.

The Web Is Uniquely Open, and URLs Are Why
The Web is valuable because it’s user-centric, user-controllable, user-editable. Users, with only a small amount of expertise, can see what web-resources a page includes, and decide which, if any, their browser should load; and non-expert users can take advantage of this knowledge by installing extensions or privacy protecting tools. The user-centric nature of the Web is very different from most application and information distribution systems. Most applications are compiled collections of code and resources which are difficult-to-impossible to distinguish and reason about. This difference is important, and is part of the reason there are many privacy-protecting tools for the Web, but very few for “binary” application systems. At root, what makes the Web different, more open, more user-centric than other application systems, is the URL. Because URLs (generally) point to one thing[2], researchers and activists can measure, analyze and reason about those URLs in advance; other users can then use this information to make decisions about whether, and in what way, they’d like to load the thing the URL points to. More important, experts can load https://tracker.com/code.js, determine that it’s privacy-violating, and share that information with other users so that they know not to load that code in the future.

WebBundles Make URLs Meaningless
Google has recently proposed three related standards, WebBundles, Signed HTTP Exchanges (sometimes abbreviated to SXG), and Loading. Unless otherwise noted, this post will use the single term “WebBundles” to refer to all three specs. So far, WebBundles have been pitched for use in proposed advertising systems (i.e., TURTLEDOVE, SPARROW) and as parts of a follow-up to Google’s AMP system, although I suspect this is just the tip of the iceberg. At a high level, WebBundles are a way of packing resources together, so that instead of downloading each Website, image and JavaScript file independently, your browser downloads just one “bundle”, and that file includes all the information needed to load the entire page. And URLs are no longer common, global references to resources on the Web, but arbitrary indexes into the bundle. Put differently, WebBundles make Websites behave like PDFs (or Flash SWFs). A PDF includes all the images, videos, and scripts needed to render the PDF; you don’t download each item individually. This has some convenience benefits, but also makes it near-impossible to reason about an image in a PDF independently from the PDF itself. This is, for example, why there are no content-blocking tools for PDFs. PDFs are effectively all or nothing propositions, and WebBundles would turn Websites into the same. By changing URLs from meaningful, global identifiers into arbitrary, package-relative indexes, WebBundles give advertisers and trackers enormously powerful new ways to evade privacy and security protecting web tools. The next section gives some examples why.

URLs in WebBundles are arbitrary references to resources in the bundle[3], and not globally shared references to resources. This will allow sites to evade privacy and security tools in several ways. At root, the common cause of all these evasions is that WebBundles create a local namespace for resources, independent of what the rest of the world sees, and that this can cause all sorts of name confusion, undoing years of privacy-and-security-improving work by privacy activists and researchers. The sections below discuss just three ways that this confusion could be exploited by Websites with WebBundles.

(Editor's Note -TLDR, subheadings for the body of the article)

WebBundles Alow Websites To Evade Privacy and Security Tools ...
Evading Privacy Tools By Randomizing URLs ...
Evading Privacy Tools By Reusing URLs ...
Evading Privacy Tools By Hiding Dangerous URLs ...
WebBundles Make Privacy Violations That Are Currently Difficult Easy ...

... Conclusion
Brave works to improve privacy on the Web, in the web browser we build, the tools we build and share, and the advocacy we do in standards bodies. The concerns shared in this post are just one example of the work Brave does to try and make sure Web standards stay focused on privacy, transparency and user control. We’ve tried to work at length with the WebBundle authors to address these concerns, with no success. We strongly encourage Google and the WebBundle group to pause development on this proposal until the privacy and security issues discussed in this post have been addressed. We also encourage others in the Web privacy and security community to engage in the conversation too, and to not implement the spec until these concerns have been resolved. One way to join the conversation would be to comment on this issue describing these concerns with WebBundles (both the issue and this blog post were written by the same person). Other options include opening new issues against the spec, or letting your web browser know how important privacy tools are to you, and that the risk this proposal poses to those tools.

Read the entire article here
Last edited: