WebBundles harmful to content blocking, security tools, and the open web
brave.com
brave.com
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.
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.
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.
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.
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.
[1] https://news.ycombinator.com/item?id=24186376
[2] https://stratechery.com/2020/australias-news-media-bargainin...
WebBundles are an attack on user agency: the right to filter content on the open web.
Google putting forward a proposal which directly attacks the ability of general-purpose blockers to operate is not a case of "nothing to see here, I did something I think approximates this situation years back".
The moral case of "blocking = theft" clearly isn't getting political traction so an alternative or accompaniment is pushing standards to destroy the rights of user agency.
Keep in mind Gorhill's statement on justifying uBlock Origin [2]:
"That said, it's important to note that using a blocker is NOT theft. Don't fall for this creepy idea. The ultimate logical consequence of blocking = theft is the criminalisation of the inalienable right to privacy."
Noble and correct, but if this technical war is successfully waged as mentioned it all becomes moot.
Some may desire that the internet moves to a set-top box model of pressing buttons to get an un-inspectable, unmodifable content window for consumption, but many of us do not.
I can't think of anything worse: the open web transformed by ad-tech behemoths into some kind of locked-down hotel entertainment system.
If someone really wanted to sabotage the URL right now, they would have already been doing it by hacking these to randomize the filenames, which is the same thing you would have to do to deliver that type of obfuscation in a web bundle anyway.
If you're really worried about big mysterious obfuscated blobs of code running in your browser that can't be broken up and blocked individually, the real culprits are web assembly, and minimizing bundlers like webpack. Not some packaging scheme.
By "obfuscate," I meant obfuscate the URL, which has been mentioned multiple times in this discussion, so I thought it wouldn't be confused with code mangling.
This comment illustrates the point very well imo: https://github.com/WICG/webpackage/issues/551#issuecomment-6...
It also seems to paper over the fact that randomizing urls requires a server side component to keep rebuilding the bundle which is the same thing you would have to do with the zip file method, and has most of the same drawbacks (i.e. changing the url would invalidate cache).
The Github thread starts with making the spec and adblockers compatible [0]. You seem to be of the opinion that they are, or that their incompatibility is better solved on a different layer. If so, your input would be appreciated at that thread, which is still active.
[0] And in response to the push back, explains the incompatibility.
I didn't say that, and I would assume most HN readers understand I was moving from the specific concerns content blockers have with your 'WebBundles' proposal to commentary on the wider motivations of Google: that its business interests logically drive it to find ways to thwart content blockers which frustrate their ad-tech ecosystem.
A web architecture which does not allow content to be modified – one that results in websites being a 'black box' – is the ideal outcome for Google's ad-tech ecosystem.
I am hardly claiming any one initiative takes us straight there - that would be quite the poor strategic play from Google. But Google's changes to Chrome to frustrate content-blockers [1], through to AMP and now WebBundles paint a disturbing picture for independent observers.
For examples that might speak to the institutional strategies employed by Google, recall the claims from Johnathan Nightingale that Google systematically sabotaged Firefox over a decade [2].
Those claims are telling not just for the institutional analysis, but for the revelation of an honest mindset among Google engineers internally:
"I think our friends inside Google genuinely believed that. At the individual level, their engineers cared about most of the same things we did."
When I see the valid claims made of serious issues around AMP and WebBundles, and see honest, heartfelt responses from Google engineers that it's all fine and a beat-up, I can't help but think of Nightingale's observations.
"Hey everyone, it's all fine. We mean well. Don't worry - nothing to see here."
[1] https://www.cnet.com/news/google-holds-firm-on-chrome-change...
[2] https://www.zdnet.com/article/former-mozilla-exec-google-has...
And I'm not making a "claim" out of thin air. The WebBundles spec is available for anyone to look at: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...
WebBundles plug into the exiting request/response flow and allow a browser to fetch a response from the bundle instead of the server: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...
It's effectively serializing a HTTP/2 stream. A browser doesn't have to fetch from the bundle and can fetch from the URL directly as well. Any processing currently done at the request/response level, like blocking, is still done on the request/response level.
There is an objective truth here that is not subject to conspiracy theories about the intent of Google.
WebBundles do not prevent content from being modified, and does not make web sites a "black box". That's just FUD, and I challenge you to point to where WebBundles do any such thing.
WebBundles are an archive format with an easily parsable index, and where it's easy to read individual files based on their offset in the bundle. The contents of WebBundles are individually processed, individually addressed by URL, individually populate the network cache.
If you have any evidence to back up your description of WebBundles as a black box, please provide it, because the fact on the ground do not support that assertion, and the article in question doesn't even directly claim that, even though it sneakily skirts around the issue by comparing bundles to PDFs. PDFs aren't modelled as a bundle of several responses, so the comparison is flat out wrong.
Can you explain how to accomplish content blocking with WebBundles? For example, adblockers?
That's what I'm trying to point out by saying that WebBundles adhere to the current request/response model - they just preload a bunch of responses so you don't need the network round-trip. See the section I already linked: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...
An extension that can modify requests and responses still can with bundles. In fact, it should be easier to identify and block individually address resources out of a WebBundle vs the transpiled bundle out of WebPack, et al.
Provided that adblock/content block functionality wouldn't be impacted, I can provisionally get behind this. It would certainly make my life as web developer easier.
"I am hardly claiming any one initiative takes us straight there [to a black box of the web]".
I was extremely clear on that, and further explained that we must consider Google's pattern of behaviour and commercial interests here – not one specific action.
Ignoring my good-faith clarification you seemingly continue to suffer this misconception – that I asserted something I didn't ("back up your description of WebBundles as a black box"). You may be more interested in engaging with and refuting arguments based on a convenient misconception, but I really am not.
For anyone seriously interested in this topic from the perspective of the open web and content blocking, the blog author summarised his concerns in a Github ticket [1].
(The responses throughout the Github issue reflect a similar strategy of a 'fingers-in-the-ears, everything is fine, what are you talking about' approach)
[1] https://github.com/WICG/webpackage/issues/551#issuecomment-6...
I see that you think this is a bad spec, but you don't seem to acknowledge comprehend or grasp that a lot of people want this for really good & wholesome reasons. Signed exchanges for instance are absolutely critical in allowing users to share content with each other while offline, which has radical & excellent potential.
(I posted one comment on this article, and a few follow-up comments to people who engaged with it.)
They hate that people can deep link into their platforms and share these links with each other, untracked. They want to have complete control of the experience. They are slowly migrating us to a network of crummy walled gardens.
If it was up to them, they would just have you download a giant .exe file and require that you run with admin privileges. The only protections that the likes of Google would offer you is that the different pieces of opaque adware clogging up your device not interfere with each other, and not to so destabilize your device that you can't be advertised to. In other words, Android.
And they will use every bit of leverage they have to continue to corral us from the open pastures of the web into their nightmarish silos.
A powerful bulwark against this was Mozilla. But their #1 priority now is to validate and amplify Google's vision of the web. Rest assured, now matter how awful and user-hostile webundles turn out to be, Mozilla will be there, offering an inferior implementation.
Firefox got popular because they completely rejected Microsoft's vision of the web. They didn't try to implement Microsoft's terrible ideas, because they were user hostile and not worth implementing.
[1]: https://www.pcworld.com/article/2362123/google-chromes-origi...
I'm one of the sometimes shrill voices when the url is getting de-emphasized but I really don't feel like webbundles are part of that threat.
What is different is that a server no longer has to be online serving content for folks to be able to get content. 3rd parties being able to serve content is a very different world indeed, & I have reservations about folks no longer having to run their own big world facing services & becoming reliant upon 3rd party serving. But those concerns are far outweighed by how excellent it will be being able to share web content with friends while offline together, being able to easily transfer webapps among users, &c.
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.
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).
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.
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.
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.
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.
Ad blockers that work using URLs are fundamentally only possible because they aren't common: if you make them common, they will break.
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!
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.
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.
- Lots of tools don't allow you to block requests off those additional keys (Google's Manifest v3 for one, Apple's iOS content blocking too)
- In many cases, making consistent replies based off those keys requires additional information privacy tools also try to limit (referrer fields, cookies, etc)
- There is practical, real world value in making things more difficult for trackers / folks sending you stuff you don't want; decisions are made at the margins!
- Ad blockers are common on the web (estimates 10-30% of users!); they're effective bc they work with the grain of the web, and circumvention is deterred (though not prevented) bc there are costs to circumventing adblockers; WebBundles push those costs to zero. Again, decisions are made at the margins
I'm not sure where the claimed confusion is above.
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.
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.
With WebBundles. I call it https://example.org/1.js (which is a diff than what https://example.org/1.js points to in a different bundle) or even just call it https://example.org/looks-to-be-benign-to-the-web.js.
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.
<html>
...
<script src=/fingerprint2.js>
...
But your site could, with minimal effort, do:
<script src=/asdf23f23g.js>
Web bundles change none of this. Just as you can generate an HTML file that references either /fingerprint2.js or /asdf23f23g.js, so can you generate a bundle. Unlike your claim in the article, this does not turn "circumvention techniques that are expensive, fragile and difficult" into ones that are "cheap or even free".
(Disclosure: I work for Google)
At root is private name resolution. What one bundle sees as asdf23f23g.js is different from what another bundle sees as asdf23f23g.js is different from what the web sees as asdf23f23g.js.
A site changing URLs often is a pain filter list authors deal with (automation, etc). Private namespaces for URLs is the real problem here that makes the proposal dangerous (and using it to randomize URLs is just a demonstration of how the dangerous capability can be used)
1. First HTML request: Generate a random string, put it in a server-side cookie, use it to name the fingerprinting script.
2. Later HTML requests: Pull the random string out of the cookie, use it to name the fingerprinting script.
3. Requests for the fingerprinting script: see that the cookie is present on the request, return the script.
This is some work, but not that much. And unlike a WebBundle version, it is cacheable.
Your cookie-based solution still requires the cookie as a sort of state tracker to memorize the URL in question. This requires some server-side logic to coordinate different requests and deal with cases where the cookie gets lost.
In contrast, implementing the same with web-bundles is as easy as generating a single HTML page: There is only a single script needed that generates the whole bundle in gone go and therefore can also ensure the randomized URL is used correctly without any kind of state.
If you're ok with giving up on this caching then you don't need cookies, you can have the server generate random-looking urls that it can later recognize are requests for the fingerprinting library.
I think the point is that this part:
> that it can later recognize are requests for the fingerprinting library.
is made significantly easier to implement by web bundles. (Because with web bundles, the server doesn't need to understand the URLs at all)
I agree however that it's questionable how well this technique would fit into real-life situations. I imagine as most ads and tracking scripts are not served locally, you usually wouldn't be able to embed them into a bundle anyway, randomised URLs or not.
I agree it's a little easier than what I described because there are no longer separate requests to connect, but it's not much easier. On the other hand, if you're going to give up on caching and bundle everything into one file you could just have your server inline the tracking script. (Or use HTTP2's server push.)
Taking a step back, your last paragraph looks right to me. Ad scripts are very rarely served locally because there is an organization boundary between the ad network and the publisher (and a trust boundary), and they're large enough that you do really care about caching.
You might lose some granularity in the filtering but most blocking is already done per-domain rather than specific assets.
It's one level of abstraction but if you can control the content of the bundle then you can also control the URL to that bundle, therefore there is no difference. If it's from a 3rd party then you can block the domain or bundle address. If it's 1st party then it's all the same abilities as today.
Right now, when I Google "WebBundle," the first result is your article. The second result is an intro to Webpack.
These just look like optimizers that bundle multiple JavaScript files into a single file to avoid latency.
I'm confused. At least for adblocking, it's always an arms race.
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.
(Disclosure: I work on ads at Google)
Why is this a use-case that I as a web user should care about? Frankly, I don't find it very comforting that an article raises privacy concerns, and an engineer working on ads at Google responds with "these concerns are misguided; I'm exploring this technology to make ads better."
If you block ads, then my work will have no effect on you. If you do not block ads, then my work decreases bandwidth usage and makes it harder for ads to deface each other.
> I don't find it very comforting that an article raises privacy concerns, and an engineer working on ads at Google responds with...
The article describes privacy concerns, but those concerns are based on a misunderstanding of what WebBundles make easier. Specifically, they're concerned about URL randomization, which is no easier with bundles.
Random URLs are just an example of the capability they are not the fundamental problem
I can also do that on my server based on whatever criteria I want, just by returning different content. How is this significantly different than the problem you've brought up?
At least, that's my understanding.
If they're served by a 3rd-party then you block on domain or address to the bundle just like today. If it's 1st-party then they can already randomize every URL.
Right, I'm claiming the post is wrong, and that this is not something WebBundling makes (newly) possible or makes easier.
> Julia and I believe that one of the best ways to make the world better is to donate to effective charities.
I would argue that the best way to make the world better is to First do no harm. Making a large income by pushing ads at Google doesn't uphold that rule, in my opinion. And perhaps this person's sensitivity around their job is why they feel the need to publicly list their donations, rather than giving quietly. Public philanthropy has often been used as a way to try to deflect criticism from how the money was first made.
I can't speak for Mr. Kaufman, but I imagine he shares this information publicly not to brag, but to encourage a new norm of publically donating a significant portion of one's income to effective charity.
He and his partner may have literally saved hundreds of lives with their contributions over the last few years alone[0].
What have you done for the world lately? For myself, the answer is: not enough.
0.https://www.givewell.org/how-we-work/our-criteria/cost-effec...
If I thought my work in advertising was harmful I would stop. I think it's probably slightly positive: https://www.jefftk.com/p/value-of-working-in-ads
> perhaps this person's sensitivity around their job is why they feel the need to publicly list their donations, rather than giving quietly
I've been listing my donations publicly since before I started working in ads. I wrote https://www.jefftk.com/p/make-your-giving-public when I was working on open source software that rewrote web pages so they would load faster.
This message brought to you by Subway: Eat Fresh.
So fuck that argument.
Why exactly am I paying Google for again? Remind me: Is it so that I don't see ads, or so that the artists are properly compensated?
I'm asking because my bank account is lighter, Google has made records profits, but neither of the two outcomes above has occurred...
Technically the Youtube subscription is for the platform itself and extra features, and a little bit of the money is shared with creators in return for removing the ads. They actually make less with Youtube premium users, and if you paid them the same as their ad revenue then your total subscription would be much higher.
Anyways, the only "theory" is that costs need to be paid, and you can't have no ads and no payments and expect that to work.
Hence ad blockers, without a shred of remorse.
My local newspaper is dying and I don't feel sorry for them.
"Companies therefore must run advertisements to make content because a significant portion of the target audience does not want to pay for it" does not follow from that.
There are many industries that typically do not run advertisements for their content - book publishing comes to mind here - and they seem to get by just fine.
90% of everything is crap, so 90% of entertainment disappearing because production houses and producers stop whoring themselves out to Madison Ave and big brands is a net positive for society. Make the 10% of things you can get funded by the target audience without having to mentally and emotionally manipulate them (which is what advertising is) and you'll still have too much content for the average person to consume.
Advertising is immoral, and advertising to children is both immoral and explicitly evil.
This is true for most online content. For various reasons, content that's not music or video has an assumption of being free. Book publishing is not comparable.
> "90% of everything is crap"
Maybe, but everyone has a different 90% so there's no "average". Content is made to match demand and there's something for everyone.
> "mentally and emotionally manipulate them ... Advertising is immoral"
Everything is manipulation and influence. Recommending something to your friends is a form of advertising (and even officially called "word of mouth marketing"). I agree that advertising should have better safeguards since it's influence for a price, but calling it immoral gets into some strange philosophical territory that doesn't accomplish anything productive.
So, this is a super unfortunate analysis that seems to be founded on a major logical inconsistently.
The post claims that:
1) It's costly to vary URLs per-user without WebBundlers because it harms caching. By caching I presume here they mean edge caching.
2) It's cheap to vary URLs per-user with WebBundles.
The costs are not any different:
* If you vary the bundle per-user then you also harm edge caching.
* If you build a bundle per-deployment, like current bundlers do, then you're not varying URLs per-user
* 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.
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.
(Disclosure: I also work for Google)
I mean the way it was shown is that WebBundles allow the author of that content to arbitrary hide and package content in such a way where you cannot filter specific content; so either you view a page with ads and trackers or you don't see anything at all.
The infrastructure needed to randomize and remap URLs for bundles is basically the same as for endpoint URLs. You can already serve all requested content, including things a blocker might want to block, as first party, meaningless URLs. https://my-site.com/1g276dn4kas for everything. Store the URL map in the session data rather than bundle.
I don't even think the hard part in either case is mapping the URLs and serving the content, but rewriting all the references to the URLs in the source files.
I’m wondering what those are. The use cases I’ve seen seem pretty tenuous to me (people don’t want to send web bundles to each other. They want to share a link. They don’t want alternate transports in general, really, or the complexities that come with that.)
I guess I may not know what the use cases are, but right now it looks like a complication with little upside.
One problem with asset distribution is that bundling (good transfer compression, efficient full download) and fine-grained loading are fundamentally at odds. Both Google and Netflix depend on dynamically combining chunks into responses today. Web bundles makes this possible using platform features and potentially also adds proper cache invalidation on top of it.
It's not quite there in the current specs but being able to send ES module graphs in web bundles does have properties that are hard to replicate without it. This isn't really related to users sharing URLs, it's more about the behind-the-scenes of loading assets for a page that got loaded using a traditional URL.
Doesn't it already solve all of these issues, and head-of-line-blocking as well?
I can see ways to model this kind of behavior on top of individual requests but it'd likely be even more complicated than it already is with web bundles. E.g. telling the browser that certain resources shouldn't be fetched because they'll likely be pushed because of a different pending request is super awkward without a "resource bundle" abstraction.
The core web file formats: JavaScript, CSS, HTML, and images, do not have native multi-file bundling support. Today's bundlers have to jump through serious hoops, which drastically reduces the effectiveness of the network cache, to emulate bundling. And those hoops bring constraints that limit the native features of the web platform that are usable with bundlers.
JavaScript is bundled by significantly rewriting it. At the very least imports and references to imports have to be rewritten. Live bindings from modules require special care. Dynamic import() is severely restricted. import.meta.url usually doesn't work well, or at all. Base URLs for all resources are changed, so getting assets with new URL() and fetch() is usually broken. That causes bundlers to support importing module types that the browser doesn't support, so at development time you still have to run the bundler. The whole thing just diverges from standard semantics.
CSS is bundled by assuming a global CSS scope so that the individual files are not needed separately. URLs within the CSS have to be rewritten. The upcoming CSS Modules specification allows JS modules to import CSS, but since you need to import the actual stylesheet you want, and CSS doesn't have it's own multi-module support, you really need native bundling to make this work well in production.
Images can be bundled _sometimes_. Maybe a spritesheet will work, or data: URLs. It all depends on how you're using them.
It's all a complicated mess that requires complicated tools and WebBundles just fix it all. You no longer have to rewrite any references in any files. If you do build files, it's purely for optimization, not because you have to.
What's important for users is that files in a WebBundle are individually cached. This makes it finally possible to do delta-updates on pages where you only send the updated files. Maybe the initial visit is with a bundle and subsequent visits use HTTP/2 push. Maybe when you deploy you build delta bundles against the previous X versions of the site. With current bundlers only the bundle is cached so you can't do this at all.
That's just how I see it, I know I can easily be wrong. If it takes off, we'll be able to measure its value by penetration. E.g., if it's being used on 1% of sites, that means it has some decent niche value. If it's being used on 10% and rising sites, we'll know it has really good value.
Isn't the whole point of HTTP/3 to "emulate" bundling without actually requiring content to be zipped up into a binary blob? Isn't it also quite good at caching, such as incrementally updating individual files without complexity? Isn't it also capable of pipelining a bunch of small logical files into a contiguous stream as-if they were in one big blob? Isn't the head-of-line blocking issue, which HTTP/3 solves, going to be a problem with monolithic web packages? What's next... WebPackage 2.0 with a yet another head-of-line-blocking-solution!?
This all feels like the left hand not talking to the right hand at Google.
It also feels like Google is perfectly happy to bloat web standards to the maximum extent possible given the size of their development team, permanently and irrevocably blocking anyone from ever again developing a web browser from scratch to compete with Chrome. Unless of course they can devote a few thousand man-years to the task. Which noone short of two or three companies can now.
I've never even heard of this "problem" that Google is trying to solve, but clearly Google is pushing very hard for it to be solved... for some unstated reason.
From the outside, this feels incredibly self-serving.
Having spent lots of time trying to optimize servers to correctly utilize HTTP/2+push, and building bundle-less deployments, not only is it quite difficult, it doesn't achieve the compression performance that bundling does. We measured ~30% better compression from a bundle over separate files.
And I don't see this as bloating standards at all, but fixing a huge problem in current web development and paving a cow path. Bundlers are central to web development today, maybe even more so than frameworks. And they cripple the features of many of the files types they bundle. WebBundles fixes that.
Arguably "people" don't even want HTTP, either. They don't want any technical feature, they want the things they can do with that technical feature. You're right that they want simplicity, but Web Bundles done right should be very simple to the end user.
Just a random example that comes to mind: I want to share a number of photos with someone. A web bundle could very easily group those photos together along with a quick webpage showing thumbnails, selection etc. without ever having to involve uploading photos to a remote server. That seems like a really interesting possibility to me.
There are similar ones.
These are suggesting people want to share or access web sites in some other way than links. I don't think that's true in any significant way.
> ...they want the things they can do with that technical feature...
I agree. But the problem with all of the alternative transport scenarios is they have the user managing transport through some additional actions on their part. People couldn't care less about HTTP. What they like about it is they click/tap or copy/paste a link and that's it. Additional steps, like going through a specialized UI to share files via bluetooth is not going to interest very many people. That web site actually suggests people may want to share/access their website through the sneaker-net. That's just not a very important scenario.
To take your photo sharing example. That could be done using a web bundle. But it could be done in a variety of ways that would look the same from a user perspective. Keep in mind a network (with servers) is needed to share the data, whether there's a web bundle or not. So the remote servers are there, regardless.
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.
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?
The reason why nobody has bothered is because PDFs contain the desired content only. Generally, when viewing a PDF, you're not bombarded by five concurrent video ads competing with the text for your attention. There's no clickjacking, or overriding of scrolling behaviour to force a full-page popup down your throat the instant you scroll up, scroll down, or interact with the page in any way.
The latest insanity that has suddenly become popular in the HTML world is the ad-forward page. When you first visit a site, it forwards you to the content page, but if you try to click "back", you end up going to a full-page advertisement instead of the referrer page. I'm sure someone thought this up to defeat ad-blockers: You can't get to the content without being forwarded through the ad page, and then the browser history is polluted, so it's too late to simply block content. Pretty soon, uBlock will have to rewrite the browser history to stop ads.
This is bordering on insanity.
It's the same behaviour as when I walk into a whitegoods shop and a pushy sales guy steps into my way and demands to "help" me. Or when on holidays in a third world country, where being white means being endlessly harassed by hawkers.
Doesn't it make you people feel dirty to have to write the code to do these things?
Why, for the love of God, can't we have some sort of model where browsers pay for content with microtransactions?
I know it has been talked about a lot in the past, and rejected for various reasons, but seriously: It has to be better than this.
Mark my words: The inevitable outcome of funding content only with ads will be all such pages eventually evolving into DRM-protected video with the ads overlaying the text. It's just a matter of time.
Developers did. People didn't. People hated Flash because it was bloated, downloaded slowly, and killed anything with a battery.
All this pining for Flash is just revisionist history inside the HN bubble from people who have forgotten how much Flash was hated by the general public.
At least in my social circle that's incredibly far from the truth. My friends and I loved Flash videos and games. Downloading the Flash runtime was a very small price to pay for the functionality it unlocked. And these people are definitely not HN users.
Strictly speaking, there is nothing particular to Flash that precludes JIT compilation. In fact, AS3 code runs on a VM specifically built with JIT in mind. AS1/2 code does not, but that could be remedied with shittons of guard statements like modern JavaScript VMs have.
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.
There is an enormous, important difference between:
i) circumventions that are possible but are fragile and cost more, and ii) circumventions that are effortless for the attacker / tracker
Every practical privacy / blocking tool leverages that difference now, the proposal collapses it.
I completely disagree. Browser-level code can still effectively apply user-defined privacy and security policies onto WebBundles.
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.
jar://https://site.example/archive.zip!/file%201.txt
bundle://[optional hash, origin, or regex?]![uri or regex]
// e.g.
bundle://https://site.example/!https://site.example/regulated-sub-bundle-file.htmlIt has gotten to where there the line between advertising and malware is blurred or nonexistent.
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.
There is no difference between an URL without web bundles, and an URL that refers to a "web bundle" and a path within in.
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.
We are building a binary transparency system here: https://transparencylog.com
Having HTTP signed requests would be nice to prove that the origin server presented the contents.
For now, let me highlight a really big consideration:
- Most of the effectiveness of CT logs stems from the logging mandate not the cryptography. The publicly trusted CAs proactively log either everything they issue or all but some relatively small controlled subset of issued certificates which purposefully fall outside the mandate.
Will your X transparency be mandatory? Who will enforce that? Won't it be more practical to reject systems that try to mandate X transparency than to implement it?
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.
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".
It's only recently that due to security reasons, the ability to load HTML from local files was greatly restricted - so I personally would be pretty happy if loading pages from non-web sources is on the table again.
Then it feels like a bit of misdirection to immediately pivot to "easy to share and usable without an internet connection". What if you do have an internet connection? What if the real goal is actually to republish entire web sites on google.com, i.e., AMP?
Why would Google have hosting everything on their domain be an end goal?
WebBundles address the technical limitation that causes AMP to serve everything from Google's own domain.
To become the internet! Much like AOL was in the past, kind of like how Facebook is now. Each of the big tech corps is trying to set up a walled garden that you never leave.
In the beginning, Google Search was not a destination, it was merely the way to find your destination. But now a large percentage of searches never actually leave Google. The data is re-presented by Google Search.
Google has a search engine, DNS, browser, email service, office suite... oh yeah, and a mobile platform. All of which have millions or billions of users. They just need to host web sites too in order to create their own web-on-the-web. The Google Internet. It's about controlling the entire "experience".
Think about it: the web is supposed to be "free" (as in freedom), but increasingly web site owners have to design everything around Google: ranking high in Google Search, having the right format for AMP, rendering "correctly" in Google Chrome. Even being forced to adopt https (read Dave Winer on that issue) or be erased.
They're clearly speaking as a neutral source when to anyone with an ounce of knowledge they have a biased agenda.
Would you take an article from 1990's Microsoft about how Apple is evil seriously?
Also, pointing out a conflict of interest isn't ad hominem. I didn't call them nazis or morons.
Because Apple and likely other browsers will not adopt SXG etc, such AMP2 content will have to include a fallback link (as AMP does today). We may in such a scenario automatically prefer the non-AMP2 content.
In any case, your argument fails because we are no worse off in the worst case, and in better cases we still block many requests for greater user wins.