
WebBundles harmful to content blocking, security tools, and the open web - alokrai
https://brave.com/webbundles-harmful-to-content-blocking-security-tools-and-the-open-web/
======
justsee
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.

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](https://news.ycombinator.com/item?id=24186376)

[2] [https://stratechery.com/2020/australias-news-media-
bargainin...](https://stratechery.com/2020/australias-news-media-bargaining-
code-breaking-down-the-code-australias-fake-news/)

~~~
cycloptic
I just don't get this criticism, nothing in web bundles appears to be
particularly new, nor would it make it much easier to create private
javascript namespaces. Years ago I built web apps that were packaged as zip
files, which then were decompressed in a worker and then had javascript loaded
from them. If you want to do this right now, it's not hard.

~~~
justsee
The blog author summarises the core issue here [1].

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.

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

[2]
[https://github.com/gorhill/uBlock#philosophy](https://github.com/gorhill/uBlock#philosophy)

~~~
cycloptic
You're talking to someone who hasn't used a browser without ublock origin
since 2014. Just looking at the spec, it's not any more effort to build a zip
file than it is to build a web bundle.

~~~
liability
Google pushing this does more to normalize the practice than anybody in this
thread who 'tinkered with an equivalent idea a few years ago' or whatever.

~~~
cycloptic
I don't think that is an important distinction to make. Google isn't alone in
wanting this, with a simple search you can see by now there are multiple
webpack plugins that produce zip files:
[https://www.npmjs.com/search?q=webpack+zip](https://www.npmjs.com/search?q=webpack+zip)

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.

~~~
AriaMinaei
You’re missing the point. It is one thing for a small percentage of websites
obfuscating their code and assets in zip files, but it’s a whole other thing
if the practice is standardize and a large number of websites move to
implement it.

~~~
cycloptic
I don't see how that is relevant at all. Obfuscating code and assets isn't in
the spec. Either way, you have to go out of your way to do it. Web bundles
actually seem like they would be significantly better for content blockers
than zip files would be, because accessing them still uses the standard xhr
APIs which can still be hooked.

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.

~~~
AriaMinaei
> Obfuscating code and assets isn't in the spec

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...](https://github.com/WICG/webpackage/issues/551#issuecomment-618776153)

~~~
cycloptic
Obfuscating of the URLs is a non-issue and I think that comment is being
unnecessarily negative instead of looking at ways to deal with the problem.
There is no reason an adblocker should not be able to get at the actual source
(i.e. knowing that request A is actually going to be fulfilled with a resource
included in web bundle B coming from site C). If ad blocking tools are unable
to do this for reasons unrelated to the web bundle spec, that's a separate
problem.

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).

~~~
AriaMinaei
> I think that comment is being unnecessarily negative instead of looking at
> ways to deal with the problem [...] If ad blocking tools are unable to do
> this for reasons unrelated to the web bundle spec, that's a separate
> problem.

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.

~~~
cycloptic
I probably won't because I don't maintain any ad blockers at this time, in my
opinion if you really care about this as an attack vector it's better to just
block javascript entirely. As I've said before this type of circumvention of
ad blockers is not anything new and has been possible for years. The sites
that really wanted to mess with your url filtering are already doing it, with
or without web bundles.

------
saurik
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).

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.

~~~
saagarjha
One of the problems with ad "view" blocking is that the problematic code still
downloads and loads, so you lose much of the benefits of content blocking
making your page lighter and only get the benefit of removing mental
overhead/distractions (I say "only", but I'm not trying to say it's not a huge
gain). Ideally this AI would work at the network level, but the fundamental
problem is that a URL doesn't have to tell you anything about what is on the
other end, and we haven't tried "browser antivirus" software yet that blocks
JavaScript by matching it against (say) an ad network's "fingerprint"…

~~~
saurik
Yeah. For various article-context reasons I am concentrating on the blocking
of "ads" here rather than on "malicious code". The latter is a much more
complex problem to solve in the first place, though: like, it relies on a
specific model of opponent that is also extremely dumb; amazingly, this
opponent exists in the wild, but I swear it is only because people who go out
of their way to block them with simple techniques are so rare as to not be
worth investing into including in your un-targeted resource utilization
attack. (And FWIW, the ad pages I run into that are maximally bad -- ones that
abuse the browser using history state tricks, popping up notification boxes
and printer dialogs, sometimes even managing to lock up the entire rendering
engine on purpose in an attempt to get the user to agree to the terms of the
scam -- all have URLs that are constantly being randomized so often that I
have a hard time showing them to other people.)

------
pes10k
Disclaimer: I wrote the article.

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](https://example.org/1.js) (which is a diff than
what [https://example.org/1.js](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](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.

~~~
jefftk
Understanding your situation: you're imagining running a website that wants to
include fingerprinting JS? So the site today looks like:

    
    
       <html>
       ...
       <script src=/fingerprint2.js>
       ...
    

The blocker sees ".*/fingerprint2.js" and excludes it. So far so good.

But your site could, with minimal effort, do:

    
    
       <script src=/asdf23f23g.js>
    

randomizing the URL on every deploy. This would circumvent url-based blocking
today, with the downside of preventing the JS library from being cached
between deploys.

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)

~~~
pes10k
Again random urls are just a demonstration of the problem.

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)

~~~
jefftk
Making it per-user instead of per-deploy is simple today, though! Assign each
user a first-party cookie, and use it to generate per-user URLs. Now users can
cache across deploys as well:

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.

~~~
xg15
I might misunderstood how web bundles work, but it still seems significantly
easier to implement with web bundles than without.:

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.

~~~
jefftk
If you serve a full bundle in response to each request then you've given up on
caching for the fingerprinting library.

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.

~~~
xg15
Yes, I understand that.

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.

~~~
jefftk
_> 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 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.

------
jefftk
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.

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)

~~~
jakelazaroff
_> 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._

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."

~~~
jefftk
_> Why is this a use-case that I as a web user should care about?_

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.

~~~
pes10k
This is just super wrong. With WebBundles I can call 2 different things, in
two different WebBundles
[https://example.org/good.js](https://example.org/good.js), and that can be
different from what the wider web sees as
[https://example.org/good.js](https://example.org/good.js).

Random URLs are just an example of the capability they are not the fundamental
problem

~~~
saagarjha
> With WebBundles I can call 2 different things, in two different WebBundles
> [https://example.org/good.js](https://example.org/good.js), and that can be
> different from what the wider web sees as
> [https://example.org/good.js](https://example.org/good.js).

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?

~~~
xg15
The criteria are well-known and basically restricted to what is contained in
an HTTP request. With web-bundles (like with service workers) the logic which
actual resource the URL resolves to is instead deeply embedded into the
browser.

At least, that's my understanding.

~~~
jefftk
We're talking about what the server decides to put in the initial HTML file
you request. Since those are almost never served cacheable to the client, the
server can just randomize the URLs it produces.

------
spankalee
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.

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.

~~~
jmull
> I very much want to see WebBundles succeed to solve many problems with asset
> distribution

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.

~~~
spankalee
The benefits to native bundling are _huge_. I really cannot overstate how much
they will improve UX, and DX.

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.

~~~
jiggawatts
Explain to me why _any_ of this is necessary once HTTP/3 is widely adopted?

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.

~~~
spankalee
HTTP/3 is just HTTP/2 over QUIC, fixing head-of-line-blocking will help some,
but...

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.

------
kmeisthax
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.

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?

~~~
reaperducer
_people LIKED the fact that Flash content could be bundled that way_

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.

~~~
rrobukef
Wasn't the majority of Flash content made before the rise of JIT-compliation
and the use of mobile devices everywhere? For me, the downfall of Flash were
security issues and its similarity to Java plugins. Additionally, Adobe never
invested all that much in Flash, Macromedia is still more associated with the
name.

~~~
kmeisthax
Yes and no.

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.

------
pes10k
Again I wrote the piece but…

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.

~~~
lukevp
I am not in any way pro-Google and I feel what they are doing with AMP is a
perilous path, but your article was not convincing. It’s trivially easy to
rotate a JS name and serve it from the same cached edge file (eg with
cloudflare workers) and not incurring any major additional cost. It’s not hard
to imagine advertisers doing something similar with their own CDNs. This could
even be done at the DNS level with random sub domains. Unless we are ok
blocking (star).facebook.com/(star), every other part of the URL is trivially
easy to randomize.

------
Sephr
> WebBundles Allow Sites to Evade Privacy and Security Tools

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
    

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:

    
    
        bundle://[optional hash, origin, or regex?]![uri or regex]
        // e.g.
        bundle://https://site.example/!https://site.example/regulated-sub-bundle-file.html

~~~
anhner
So what does that solve? It will still load the whole bundle before it can do
anything

------
sloshnmosh
Until the entire advertising community gets their s __t together I will block
every ad and script that I can.

It 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.

~~~
ssss11
There is a need for ethics in the technology industry. Without it, capitalism
causes ordinary people to do unethical things for profit.

------
jakelazaroff
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.

------
devit
Seems completely baseless.

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.

------
philips
> 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
> [https://wicg.github.io/webpackage/draft-yasskin-http-
> origin-...](https://wicg.github.io/webpackage/draft-yasskin-http-origin-
> signed-responses.html#uc-transparency)

We are building a binary transparency system here:
[https://transparencylog.com](https://transparencylog.com)

Having HTTP signed requests would be nice to prove that the origin server
presented the contents.

~~~
tialaramex
The circumstances that enabled Certificate Transparency to succeed were pretty
narrow, but people seem to keep proposing more of these X Transparency systems
so maybe I should actually properly write down why I think that's largely
futile, not because I expect it will stop anyone but because at least then I
can just paste the link.

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?

------
lachlan-sneff
WebBundles would be great for distributing applications to users as a single,
well, bundle.

~~~
est31
Yes, especially you currently can't run .wasm based apps without a server on
either Chrome or Firefox, but WebBundles will make this possible (I hope).

------
lapcatsoftware
2 things bother me about this proposal: [https://web.dev/web-
bundles/](https://web.dev/web-bundles/)

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".

~~~
lapcatsoftware
To me the key part is this: "Loads in the context of its origin when
cryptographically signed by its publisher"

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?

~~~
AgentME
>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.

~~~
lapcatsoftware
> Why would Google have hosting everything on their domain be an end goal?

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.

------
Santosh83
What is Mozilla's stand on WebBundles, SGX and Loading?

------
cblconfederate
Signed HTtp Exchanges are harmful as well

------
TylerE
Sounds like Brave is sore someone might keep them from skimming ad revenue off
legitimate creators.

~~~
Ensorceled
Do you have a rebuttal that's NOT an ad hominem?

~~~
TylerE
Do I need one?

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.

~~~
BrendanEich
We don't make revenue from ads in pages, or lose revenue if Google smuggles
ads into SWF-like WebBundles via AMP imposed on publishers under pain of
search rank loss. Brave user ads fill user inventory, not in-page ad slots
(perhaps you heard misinformation claiming otherwise). So even as an ad
hominem rhetorical ploy, what you wrote doesn't work.

~~~
Akkuma
I'm not here to agree with the who you responded to, but Google smuggling
unblockable ads does 100% harm Brave. If part of Brave's selling point is the
built-in ad blocking and in a hypothetical dystopian scenario the web were
overrun with unblockable ads from WebBundles Brave would inevitably be harmed
to some degree. I say that as someone who runs Brave on my phone primarily. I
know I'd probably switch browsers if one of the primary reasons to use it were
largely killed off.

~~~
BrendanEich
If AMP2.0 emerges with ads and tracking embedded in bundles, we will not lose
money from those ads. Our performance and battery+dataplan savings will be
gone, but we will be no worse than Chrome for such content.

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.

