Things like AMP and WebBundles clearly appear like a self-interested attack on the open web by Google, all the while making reasonable-sounding noises about efficiency and speed.<p>With the inexorable rise of ad-blockers, allowing 'User Agents' to be true agents of the user is a threat to Google's business model, and any significant engineering and standards efforts by that company can and should be evaluated by assuming the driver is not web altruism, but ferocious defence of their business model.<p>Interesting to see Google accounts drop in to misdirect on the essence of the argument outlined in the article: the essence being that bundles create private namespaces for URLS, which is an attack on the agency of a user in consuming content.<p>It should be unsurprising that Google wants to blackbox websites. If these kinds of initiatives succeed the philosophical debate around whether a user has the right to filter content running on their machine becomes moot, because technically they won't be able to.<p>The bottom line is: Google's business model is threatened by users being able to control the content they consume. Splitting hairs on how bad WebBundles will be in practice wilfully or otherwise misses this larger, more important point.<p>Operating in an Australian context, it's exasperating arguing forcefully for Google and Facebook [1] in regards to the new shakedown laws outlined brilliantly by Stratechery [2], all the while knowing there are very real criticisms that should be discussed, such as AMP and WebBundles.<p>[1] <a href="https://news.ycombinator.com/item?id=24186376" rel="nofollow">https://news.ycombinator.com/item?id=24186376</a><p>[2] <a href="https://stratechery.com/2020/australias-news-media-bargaining-code-breaking-down-the-code-australias-fake-news/" rel="nofollow">https://stratechery.com/2020/australias-news-media-bargainin...</a>
I can already give everyone a unique URL to the same resource at the cost of it not being cached (which is a cost this mechanism doesn't avoid).<p>The article admits this, but then simultaneously tries to claim that the loss of caching would prevent that from being common... but this loses caching.<p>I can already give everyone unique resources for the same URL by keying the response on the Referer (which I would also add to the Vary header).<p>The article also admits this, but then tries to claim problems that are out of scope... the "first visit" will never be to a subresource of a page.<p>The article further tries to claim that this is difficult or defeats caching, but adding Referer to Vary is trivial and works with all CDNs and caches.<p>Meanwhile, if we believe this kind of argument about "people won't bother to do it because it is slightly hard" (I don't), then we need to be consistent.<p>It will take work to generate the multiple obfuscated copies of this bundle and be maximally disadvantageous to caching to do so for each visitor.<p>Ad blockers that work using URLs are fundamentally only possible because they aren't common: if you make them common, they will break.<p>I mean, ad blockers are so uncommon right now that you can often get away with blocking hosts at the DNS level... that is so trivially defeated!<p>If you want to do something useful, work on post-download ad "view" blocking by having an AI classify regions of the page as ads and then erase them.<p>This is also an arms war, but it is one that will more than likely at least result in subtle ads that you don't mind (as the AI "lets them slide") ;P.
Disclaimer: I wrote the article.<p>I'm not sure where the claimed confusion is above.<p>The argument is: I want to include something like fingerprint2.js in my page. I know filter lists block it, bc users don't like it.<p>W/o web bundles, you have to either inline it (bad for perf), copy it to a new URL (which could later also be added to a list), or add some URL generation logic to the page, and have some server side logic somewhere to know how to understand the programmatically generated URLs.<p>With WebBundles. I call it <a href="https://example.org/1.js" rel="nofollow">https://example.org/1.js</a> (which is a diff than what <a href="https://example.org/1.js" rel="nofollow">https://example.org/1.js</a> points to in a different bundle) or even just call it <a href="https://example.org/looks-to-be-benign-to-the-web.js" rel="nofollow">https://example.org/looks-to-be-benign-to-the-web.js</a>.<p>The claim is not that bundles are coming from random URLs, its that the bundles create private namespaces for URLs, and that breaks any privacy tools that rely on URLs.
This post is very confused. If one entity generates the page and the ads, then they can already reasonably easily randomize URLs and circumvent ad blockers. Facebook does this. On the other hand, if one entity generates the page and another handles the ads (the typical situation where a publisher uses an ad network to put ads on their page) then web bundles don't do anything to resolve any of the coordination problems that make url randomization and ad blocker circumvention difficult.<p>I'm currently exploring using WebBundles to serve multiple ads in response to a single ad request, because it allows ads to be served more efficiently while keeping them secure and private, but ad blockers would still prevent the ad js from loading before the ad request was ever sent.<p>(Disclosure: I work on ads at Google)
Disclaimer: I work at Google, though not on this, and I very much want to see WebBundles succeed to solve many problems with asset distribution right now and reduce the gymnastics that bundlers have to go through.<p>So, this is a super unfortunate analysis that seems to be founded on a major logical inconsistently.<p>The post claims that:<p>1) It's costly to vary URLs per-user without WebBundlers because it harms caching. By caching I presume here they mean edge caching.<p>2) It's cheap to vary URLs per-user with WebBundles.<p>The costs are not any different:<p>* If you vary the bundle per-user then you <i>also</i> harm edge caching.<p>* If you build a bundle per-deployment, like current bundlers do, then you're not varying URLs per-user<p>* If you build bundles on the fly per request, say in an edge worker, then you could also just as easily and cheaply vary URLs per user the same way, with the same or less impact on caching.<p>The whole thing just doesn't make sense, and undermines one of the most important proposals for fixing not only resource loading but also much of the tooling ecosystem.
Many of these complaints seem... odd. The primary complaint with Web Bundles is "they make the web like SWFs" - last I remember, people LIKED the fact that Flash content could be bundled that way. You actually were able to distribute Flash content like a normal web application, broken up into multiple SWFs, images, and so on. The vast majority of Flash content was a single file, because it's easier to distribute that way.<p>With WebBundles, if you want to deny specific subresources, you can still have the browser block them by identifier or hash, which is the same as you can do with a regular web request. The reason why there are no content blocking tools for PDFs is because nobody's bothered to write a PDF reader with that capability. Furthermore, I don't see how putting the resource identifier in the content of a bundle makes it easier than changing the URL. Both of those will either defeat or be defeated by caching.<p>If you have a CDN that generates random URLs for a single cached resource and serves them on the same domain as user websites, then identifier-based blocking won't work with or without WebBundles. You can do this today with Apache rewrite rules and PHP, which are about as economical as you can get. If your threat model is "people who just know how to SFTP a handful of JavaScript files" then yes, WebBundles makes things "easier". But I'd argue your threat model is laughably unworkable if that's the case. The state-of-the-art in adtech is to smuggle your fingerprinting platform as a randomized subdomain of the client site - how do you even begin to block that with identifiers alone?
Again I wrote the piece but…<p>Folks "who are well actually, you can already make URLs meaningless"'ing are missing the point of how practical web privacy tools work, including the ones you all have installed right now.<p>There is an enormous, important difference between:<p>i) circumventions that are possible but are fragile and cost more, and
ii) circumventions that are effortless for the attacker / tracker<p>Every practical privacy / blocking tool leverages that difference now, the proposal collapses it.
> WebBundles Allow Sites to Evade Privacy and Security Tools<p>I completely disagree. Browser-level code can still effectively apply user-defined privacy and security policies onto WebBundles.<p>Didn't Firefox originally solve the issue of deep-linking into opaque bundles with it's jar: URI scheme idea? For example, this URI could be used to reference specific files in a zip archive in Firefox. iirc this scheme might not be supported by Firefox anymore.<p><pre><code> jar://https://site.example/archive.zip!/file%201.txt
</code></pre>
The same concept could be applied for WebBundles with another similar URI scheme so that content blockers and security tools can effectively introspect the bundle before initializing resources from the bundle. For example, something like:<p><pre><code> bundle://[optional hash, origin, or regex?]![uri or regex]
// e.g.
bundle://https://site.example/!https://site.example/regulated-sub-bundle-file.html</code></pre>
Until the entire advertising community gets their s<i></i>t together I will block every ad and script that I can.<p>It has gotten to where there the line between advertising and malware is blurred or nonexistent.<p>It seems to me that every new API or web standard that Google creates is an attempt to stop ad blockers disguised as meaningful useful features.
Yet another case study in why allowing a privacy-hostile advertising company to control the most popular web browser and influence web standards is bad for the web.
Seems completely baseless.<p>There is no difference between an URL without web bundles, and an URL that refers to a "web bundle" and a path within in.<p>All the things that they claim can be done with Web Bundles can be done without just as easily by putting all dependent resources in a versioned subdirectory.
> So-called "Binary Transparency" may eventually allow users to verify that a program they've been delivered is one that's available to the public, and not a specially-built version intended to attack just them. Binary transparency systems don't exist yet, but they're likely to work similarly to the successful Certificate Transparency logs via <a href="https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#uc-transparency" rel="nofollow">https://wicg.github.io/webpackage/draft-yasskin-http-origin-...</a><p>We are building a binary transparency system here: <a href="https://transparencylog.com" rel="nofollow">https://transparencylog.com</a><p>Having HTTP signed requests would be nice to prove that the origin server presented the contents.
2 things bother me about this proposal:
<a href="https://web.dev/web-bundles/" rel="nofollow">https://web.dev/web-bundles/</a><p>1) The use cases discussed by Google are largely offline. So how is this a "web" standard when it doesn't involve the web? If Google wants to implement an offline app format, that's their prerogative, but it's not clear to me why it should be enshrined as a web standard, just because it happens to use HTML/CSS/JS.<p>2) Google keeps talking about it as a tool for you and your "friend". I'm suspicious that this is the real motivation. Is the Google Chrome team really very concerned about in-flight entertainment? (Especially now when hardly anyone is flying anymore.) A number of people have suggested that the real motivation here is AMP. The "spin" in Google's proposal is too "friendly".