
Google proposed Web Bundles could threaten the Web as we know it - maproot
https://www.ghacks.net/2020/08/30/google-proposed-web-bundles-could-threaten-the-web-as-we-know-it/
======
jasode
Fyi... Web Bundles and Signed HTTP Exchanges are confusing topics so I think
it's worth reading 2 previous threads with comments from 2 Google employees
(spankalee, jefftk) [1].

One may still choose to discount their explanations because they may be biased
sources but I still think everyone should try to _understand_ what they're
saying. Hopefully, being familiar with the technical details will _elevate the
discussion_ so people who disagree can point out _specific and concrete
technical flaws_ of those explanations rather than just restating a
generalized version of _" Google is trying to take over the whole web."_

[1] previous threads:

[https://news.ycombinator.com/item?id=24275752](https://news.ycombinator.com/item?id=24275752)

[https://news.ycombinator.com/item?id=24278068](https://news.ycombinator.com/item?id=24278068)

[https://news.ycombinator.com/item?id=24324120](https://news.ycombinator.com/item?id=24324120)

~~~
drewbug01
> Hopefully, being familiar with the technical details will elevate the
> discussion so people who disagree can point out specific and concrete
> technical flaws

Asserting that an elevated discussion should center only on technical flaws
and disagreements is a myopic way to look at a topic.

There’s more to the web than the technology used to power it. How a technology
is used, and what it enables (good or bad) is an appropriate topic for this
forum and constitutes elevated discussion.

~~~
jhall1468
I think you misunderstood the point you were replying to. The idea is that you
can’t really have a discussion about what it enables or how it’s used unless
you already understand the technical details. And that shows as a lot of the
comments/blog posts about this topic are using underlying technical
assumptions that are entirely incorrect.

~~~
drewbug01
The plain language of the comment doesn’t say that:

> so people who disagree can point out specific and concrete technical flaws

That’s the basis of my reply. I think you have a good point; but it isn’t what
the parent said.

~~~
jsnell
The criticism the original post has of WebBundles is fundamentally technical.
All of their privacy and anti-adblocker claims stem from the idea that the
bundles have special URL randomization powers that the current one-resource-
per-request model can't replicate.

If that technical basis is incorrect, the whole thing just collapses. There's
nothing left. Not allowing disproving the technical basis of these kinds of
posts would mean that we have to just accept conspiracy theories at face
value. That does not seem like a healthy outcome.

(Or to put it another way: you wanted to discuss "how this technology will be
used". But how can we possibly have that discussion without agreeing on "what
the techology can do" first?)

------
TekMol
I think their idea is to combine that with signing the bundles, so a page from
www.someserver.com can be served by anyone, aka Google. I guess this would
mean Google can serve all content on the web.

There seems to be a strong urge in Google to cut the connection between then
endpoints of the web and become the central authority. Make all traffic flow
through their machines. Let no information arrive at the endpoints.

Right now, requests on the web are kind of p2p. A user requests a website, the
publisher serves it any way they see fit. Directly via their servers or via a
CDN of their choice.

Google seems to have a strong focus on ending this. Turning the web into
Googlebook / AOLoogle.

I wonder why. Do they see their business model threatened on the open web? Or
do they see a chance to increase their profit with a closed web?

~~~
laurent123456
The article seems to give some clue. The format would allow serving
unblockable ads using random urls, or urls that look legitimate. Google’s goal
is to have full control over the user experience so that they can serve more
ads.

~~~
efficax
You could already use random URLs to serve ads and track, not sure how a
bundle changes anything

~~~
otterley
Browsers like Safari are increasingly enabling privacy features that, among
other techniques, block third party cookies by default. So this could be
Google’s way of reacting to this change.

~~~
geofft
I don't see how. Web bundles don't affect whether a cookie is considered
third-party or not. Either the content is provided and signed by the actual
website, which cannot place cookies for the advertiser's domain, or it's
provided and signed by the advertiser, at which point it would be subject to
blocking just like normal web traffic from the advertiser. Is this any
different with bundles?

~~~
jlokier
The third-party cookie will be blocked, but when both sites are served via the
same proxy server, over the same TLS/QUIC connection, the third-party can get
similar tracking information they would have had with a cookie, without
needing a cookie. It's not exact, but it's good enough for inference.

~~~
dlubarov
Assuming that the third party in this scenario is distinct from the party
serving the bundle, they wouldn't be involved in the TLS/QUIC connection,
right?

So it seems like a third party wouldn't even know that their resource was
delivered, unless the party delivering the bundle notified them, or their
script makes a separate request to their own server. (And those are options
already, so AFAIK bundles wouldn't give third parties any new capabilities.)

~~~
jlokier
In the scenario, the third party is the advertising broker, Google, who are
also the entity serving the signed bundle.

~~~
geofft
Yeah, I think this is a compelling argument, but also, it's a decent argument
against using Google Search itself, is it not? They can almost certainly
_already_ correlate a click on a search result on google.com with the Google
Ads subrequest from the target page.

And, on the other hand, the fact that web bundles are signed and can be
delivered by any origin means that a privacy-focused user agent could try to
fetch the bundle indirectly via some privacy-preserving CDN - essentially DoH
for web bundles. If you are about to load a site via some known web-bundle
host (like [https://www.google.com/amp/](https://www.google.com/amp/)
probably), try sending a request to some Cloudflare Workers setup or something
first.

~~~
joshuamorton
This would be like opera turbo (and similar from other browsers), but with
fewer privacy concerns, so it's not even new design space.

------
cflat
Let’s call a spade a spade. The only real world problem that WebBundles (and
Signed Exchanges) really solve is to allow AMP to impersonate your website.

Google wants all the click data and the click through navigation data about
users (by way of passive logs) so they can sell more ads.

There are no other real world problems that web bundles solve.

~~~
Spivak
The real world problem web bundles solve is distributed caching. Right now
sites have pick one or a few CDNs and have a trust relationship with them and
allow them to impersonate your site.

Web bundles changes this relationship so that anyone can cache sites if it
benefits them to do so. If you share a link on Twitter or Facebook or Discord
or Slack they can cache the page on their servers and deliver it through the
connection you already have open to them.

Web Bundles also open the door for network-local caches that don’t require
MitM or trusting the cache.

~~~
cflat
This feels contrived. Rarely do I, as a brand or content creator, want it
circulating without my control. It doesn’t make business sense.

~~~
Spivak
This feels like such a weird stance. I can’t imagine someone saying something
to the effect of “I don’t want my DNS records just circulating without my
control.” This isn’t like AP giving CNN republishing rights, this is getting a
magazine from the stand at the convenience store rather than having going to
the Condé Nast corporate HQ.

Like it’s your site, exactly as it would be if it was delivered by your server
just delivered by someone who already had a copy on hand rather than fetching
a new one every time. This is what HTTP proxies used to do, what DNS caches
and browsers still do. TLS broke web caches because TLS secured the connection
instead of the content.

~~~
cflat
DNS is not content.

HTTP caches were always problematic from a business perspective. Great for
downloading large binaries (installs) but problematic when they don’t expire
as expected, or if content needs to change for contractual reasons.

~~~
joshuamorton
Tell that to cloudflare.

It's not like you're forced to cache things if it doesn't work for your
business case.

------
tmd83
I am really curious what's the general opinion on Googler's as a web
developer. I have seen a long while ago some nice articles from Google about
site optimization.

Do they even follow any of their original advice or Google basically keep
doing over engineered stuff fixed by adding another set of over engineered
staff?

Let's talk gmail. I just refreshed the window and it did close to 400 request,
~8MB download which translates to nearly 40MB resource. And it keeps making
more requests even when I'm not doing anything.

And a refresh of Google.com the search page did 33 request and nearly a MB
download.

And they are preaching the world about optimizing the web?

~~~
return1
Yes because heavy pages clog their crawlers. Of course they are not following
their advice (neither does FB)

~~~
tormeh
This is great:
[https://developers.google.com/speed/pagespeed/insights/?url=...](https://developers.google.com/speed/pagespeed/insights/?url=mail.google.com)

I mean, kudos to Google for (probably) not cheating here, but that's a low
score.

~~~
entropie
And thats only for the login page.

------
ffpip
Yet another thing Google wants to fix by serving everything through their
servers instead of asking devs to fix their owns sites.

Same problem with AMP. Instead of asking news sites to fix their slow pages,
it forced them through AMP by promising better result ranking.

Ask them to make their sites faster within a month or say they'll get booted
off search. You'll be surprised at how fast they comply

------
jmull
I think this line of criticism of web bundles misses the mark. It looks to me
like the issues raised are perfectly possible and just as easy without web
bundles -- that is, these may be legitimate issues, but are independent of web
bundles.

My issue with web bundles is that it's yet another pile of complexity with
very little incremental value over things that already exist. A poor tradeoff.

There's a substantial on-going cost to each web standard added so each one
needs to "pay" for itself with broad or deep usefulness. Web bundles are just
another way to skin a cat.

------
maple3142
I don't understand why can't this be blocked by content blockers. I tried open
a .wbn in the original article, and tried to inspect the resources using
devtool, it still have files listed there. So content blockers can still block
something like xxx.wbn:/js/ads.js if browser have such api.

Also, I think web bundle can be a Electron replacement too for some use cases,
so that some totally offline JavaScript webapp don't have to use Electron.

------
jakelazaroff
I was hoping this would be more than a rehash of the article on the Brave blog
about the same topic, but alas. Link to that discussion:
[https://news.ycombinator.com/item?id=24274968](https://news.ycombinator.com/item?id=24274968)

------
jeroenhd
Is there anything in the web bundle standard that forces outdated pages to be
refreshed? The spec seems to say little more than "detecting stolen keys is
not our problem".

I can imagine this being a problem when news stories turn out to be false
alarm and Google happily keeps serving the original content instead of the
corrected content.

There's also a risk of vulnerability here, as getting a signed package might
very well be used to host phishing pages on web caches.

------
bogwog
Google should just fork the web already. Let them create their own private
platform and do whatever they want.

The massive control Chrome and Android gives them means they can do whatever
they want already, but at least with a private platform they won’t have to
fight people and deal with the negative PR of doing evil stuff. And then the
rest of us who like privacy and competition and ad blockers can use the
“legacy” web.

~~~
fartcannon
Then they'll just pay a few journalists to run a couple hit pieces on the open
web, saying it's a place where people who kick puppies reside.

------
dimitrios1
Interestingly the main quotation in the article is from a Brave team member --
what does Brave do when this is rolled out? Fork Chromium?

------
jimbobimbo
Web bundles look like a great thing for Electron and PWA like scenarios,
specifically due to signature support. We had to drop service workers and
reinvent the wheel with APPX (basically a signed ZIP file) in one of our apps,
to ensure code integrity.

------
tormeh
So it's a signed executable, running in a sandbox, served from a federated app
store... Isn't the whole JS/CSS/HTML web crap a bit overcomplicated for this
purpose?

------
azangru
The missing hyphen in the title is really confusing.

------
rektide
I for one believe in the specified use cases of Web Bundles, & believe they
are worthy.

[https://wicg.github.io/webpackage/draft-yasskin-wpack-use-
ca...](https://wicg.github.io/webpackage/draft-yasskin-wpack-use-cases.html)

What we have here is a budding conspiracy theory, not even a theory, just
gesticulation. Consensual Delusion, a belief that we are persecuted by secret
forces that must be held off, held at bay.

This started months ago with an incoherent rambling ticket by the Brave author
that is being cited. He spent months going back & forth with wild accusations
& unspecified concerns. After dozens and dozens of exchanges, he finally named
one single scenario, that people might "hide" their tracking malware by
renaming files as they put them into the bundle.

Color me extremely unimpressed & unscared. Enormous sound & fury, for a
capability that is in no way different from the web we already have today.
It's not hard to setup a.webserver to randomize asset names. Nothing about
webbundles is new or changes that.

Consensual Delusions like this hacked up hoax of a story threaten reality as
we know it. As the old civic videos say: DONT BE A SUCKER. Anyone selling
fear, uncertainty, & doubt is to be met with skepticism. Increasingly, FUD is
how Apple/Mozilla/Brave are selling their anti-feature policy. "Trust us, we
won't let the web work with midi" doesn't sound that great, but is much more
honest than what we get, which is "these engineers & standards groups working
on these specs are secretly trying to undermine this treasured web which we
must protect & keep as is at all costs". the involved engineer's histories
indicates they obviously care enormously about bettering the web, & in this
case are combatting sizable transpiling tool bloat for devs, & enabling
offline sharing & offline capable web, and literally fighting censorship,
which are truly worthy goals all that will vastly help the web.

This is all super hard to work through. Yes, google used the web to reap
enormous profit by means of enormous information control & inventory systems
for ads & eyeballs. But Google also would not exist without the web, &
historically the web was a small toy that couldn't do much compared to apps.
The tables have turned, & the web is clearly ascendant, much safer, &
increasingly we understand that the limitations of ux were largely from lack
of will to explore & test what limits there really were, so the situation is
no longer so obviously tense. But Google Chrome & Chromium & the spec work
Google does are, imo, designed to improve a communal shared resource for all
humanity, designed to greaten the web, not subvert it. We can see that here,
as the engineers working on webbundle have shown a thousand times over their
commitment to honest above board clear integrity as they have tried & tried &
tried to work with Peter Snyder as he fumbled & plodded his way to a scenario
where WebBundles pose any real danger, & Peter has imo failed at presenting
anything. We can see the engineers take Peter seriously, try to work with him.
And so I feel it is in general. It is intimating as hell that the web is so
big, has so many capabilities, that so much keeps getting added, and so much
of that comes from gigantic unimaginably huge pools of capital derived from
eyeballs-on-screen. But somehow it has been working out, the engineers have
genuinely cared about doing the right thing, & usually the standards bodies &
TAG can eventually come to harmony & agree, & the web improves.

Peters dissent thread:

[https://github.com/WICG/webpackage/issues/551](https://github.com/WICG/webpackage/issues/551)

Personally I greatly look forward to WebBundles. It will radically improve the
JS module situation, yay, a thousand times yay, & giving people the ability to
share content directly with one another, without relying on centralized
infrastructure, is one of the most genuine pure & true new expanses for the
web & one I am greatly looking forward to.

~~~
maproot
Is it "simple coincidence" that "conspiracy theories" almost always come true?
I'm about conspiracy theories which are not made up by ____to make fun of
conspirators to show them like "idiots" on public.

Anyway, users always lose. Another coincidence and in this case they will not
lose, right? :-)

[https://news.ycombinator.com/item?id=24383039](https://news.ycombinator.com/item?id=24383039)

~~~
lachlan-sneff
> Is it "simple coincidence" that "conspiracy theories" almost always come
> true?

That's quite a statement to make. In no way do "conspiracy theories almost
always come true."

~~~
maproot
The main point that there are legit theories that always carry at least a
grain of truth. And when such theory come into the public,
government/google/etc begin there job to 1) hide them/remove/censor 2) if it
still becomes popular they start to make fun of it with misinformation. 3) if
it's not help they start to fork the main theory with a lot of alternative
views/lies.

------
noisy_boy
The only answer is to not click on ads. Do your research via review
videos/amazon etc (I know that they are/could be indirect advertisements but
atleast the creators get some sponsorship money). Then go to the brick and
mortar shop, check it out and then, here is the kicker, pay the extra $5 bucks
to buy from them.

------
samsquire
This is an idea I had, an alternative to web bundles and solves the same
issues.

Inside a HTML file, we introduce an attribute for embedded resources called
cache=”identifier”. Script tags, style tags will have this attribute defined.
There would also need to be an embedded image introduced. Inline all your
resources. The browser will fetch the HTML and add whatever has the
cache=”identifier” to its cache.

Then when the browser fetches a page, it will send a Cache-Got header, this is
a bloom filter serialized of identifiers cached.

The server will check the bloomfilter to see if an item needs to be sent to
the client and exclude the contents of those embedded resources with an empty
script tag or empty style tag.

EDIT: Why is this being downvoted?

