Hacker News new | ask | show | jobs
by laurent123456 2117 days ago
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.
2 comments

Kind of.

It is already be possible today to put ads into a page directly.

But the benefit for Google would be that if they deliver the bundle, they would know that their ads are in there. Heck, they would know everything that is in there. So they would have full information about all ads and everything that is taking place on this new "web".

Of course, they could also use the opportunity to hinder ad blockers further. For example by not allowing plugins to get between reading the bundle and rendering it. They already weakened plugins a lot over the recent years.

> But the benefit for Google would be that if they deliver the bundle, they would know that their ads are in there. Heck, they would know everything that is in there.

Is this a problem for Google currently?

1. They already get loaded/notified for the ads themselves. Do they have a problem with sites claiming they're serving ads and not doing so? (Wouldn't those sites just not get paid?)

2. They'd be serving this in response to web searches. They've already crawled the web page, or at least some version of it. (Yes, it could be a different version, but given the increasing unpopularity of what's now called "server-side rendering" aka the normal thing back in the CGI days, there's no guarantee even with a bundle that the site as seen by a human matches the same site as seen by Googlebot.)

3. If you are running Google Ads or even Google Analytics, you're evaling JavaScript controlled by Google in the context of your web page. They already have access to every detail of what's happening with your site, down to (if they want) where the user's mouse pointer is. What more information would they have access to by seeing the bundle?

> For example by not allowing plugins to get between reading the bundle and rendering it.

Why could they not do this with normal web pages? Define a Content-Security-Policy: no-extension-modifications header and make up some story about protecting high-value sites from buggy extensions....

    They already get loaded/notified
    for the ads themselves
Because the ads are loaded from their servers. Which makes it easy to block them.

A simple text or image in the website would currently not be tracked by Google. But if they deliver it, they can track it.

In order to do that, you'd need a change on the website's server to load and embed a Google ad into the web bundle. But if you could do that, you could just make a change on the website's server to render a Google ad into a normal web page - it's a less complicated change, and it can be done right now without adding a new feature to every browser.

I also don't really follow the attack that Google is supposedly trying to protect itself from. Is it trying to track whether websites that have signed up for Google ads are actually serving those ads to users? (Why would they care about that? If ads aren't being served, websites aren't making money.) Is it trying to track whether ads are showing up on users' screens and not being blocked by an ad-blocker? (Then it doesn't make a difference if Google views a signed web bundle or injects a script to monitor the page, and again, they're already injecting a script.) If a Google script is blocked, isn't the answer to track it as "zero" - i.e., what's the problem with (potentially) more ads being shown than Google knows about?

You could already use random URLs to serve ads and track, not sure how a bundle changes anything
Serving ads or doing tracking from random URLs doesn't work with extensions like uBlock Origin.

In Firefox, uBO can block first party domains: https://github.com/uBlockOrigin/uBlock-issues/issues/780

Also domain or URL blocking isn't the only thing you can do. You can also ban scripts from the page, or monkey patch JavaScript to change behavior that ad networks rely on. And you can also do cosmetic ads blocking, to hide elements from the page, via user stylesheets.

It's no wonder that Google is deprecating the APIs uBlock Origin relies on, in Manifest v3 ;-)

Fact of the matter is Google is now engaged in war against ad-blocking.

Again I don't get it. If a site wants to they can serve ads inline right now, without making client side requests to ad servers and ublock can't do anything about it. And first party cookies don't do any good for tracking so it doesn't matter if they come in the bundle. The ad trackers want to see where you go across multiple sites and there's no simple way to do that w/out 3rd party cookies (although you can use browser fingerprinting)
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.
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?
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.
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.)

In the scenario, the third party is the advertising broker, Google, who are also the entity serving the signed bundle.
How do bundles "help" with third-party cookies?
Normally, if you load a page from Party A which pulls in content from Party B, it's hard for them to correlate who you are because they have separate cookies. That's not a problem if they're served from the same host, probably even on the same QUIC connection.