Hacker News Reader

Comment by jefftk | Hacker News Reader

There is still "block request" functionality, the change is that it's now declarative. This is the same way it works in Safari, and is (a) more efficient because you don't need to execute JS to evaluate each request and (b) more private because an ad/content blocker doesn't need to be given such broad permissions. There are serious tradeoffs (no request time js makes it less flexible) but it's still very capable and easily can be used to block Google ads.

Docs: https://developer.chrome.com/docs/extensions/reference/decla...

(Disclosure: I work on ads at Google, speaking only for myself)

View on HN

The safari change absolutely kneecapped content blockers. Ublock dropped it[0], and the remaining few providers, like AdGuard, have to do all sorts of trickery[1] to get even close to the same performance.

If you're going to argue this is better, don't point us to such a clearly worse result.

[0]:https://github.com/el1t/uBlock-Safari/issues/158 [1]:https://adguard.com/en/blog/safari-adblock-extensions.html

I'm not arguing that V3 is better -- I think that's a complicated question, and I was trying to describe some of the tradeoffs. What I am arguing is that V3 does, contra my parent, support request blocking.

It does not allow request blocking as that has been understood in the context of extensions until now

It is not a question that V3 breaks the gold standard privacy protecting extension.

I quibble with this. Request blocking "as that has been understood", is preventing the request from leaving the browser. That's still demonstrably doable with mv3. What's changed is the mechanism. You can argue about the value of changing the mechanism, about the burden placed on plugin developers, or the efficacy of various APIs, but the functionality is inarguably still there.

You're being disingenuous. With Manifest v3, it is not possible any more to block requests dynamically which has huge implications for the efficacy of ad blocking (example: forget blocking youtube ads). Additionally, you're limited in how many static rules you can have.

Therefore, it's not just about changing the mechanism, the end result is clearly a lot worse. One can say, they crippled ad-blocking which this change. Hopefully, once the millions of people using ublock origin start noticing what's happening, they will move away from Chrome. I already did, ublock origin is worth more to me than any feature Google puts in Chrome.

I just hate that rhetorical game of "well, prima facie I meet your standard so what's the problem?" You met the standard before too, obviously that's not the problem

Fair point, apologies if I came off a bit harsh. I'm just really frustrated in the direction Google has taken with this whole thing.

I understand the average user probably shouldn't be able to easily hand over so much control to extensions, but on the other hand, dynamic ads shouldn't be able to serve malware or cryptominers.

I'd be a bit more open to the idea of a locked-down manifest if we had seen more good-faith attempts from AdTech to change the paradigm that makes content blockers almost a requirement.

I’m sure you are an honest person working in good faith. But we saw very similar behavior from Google around AMP. They had a very narrow reasonable sounding explanation, and just ignored all criticism and requests from both users and publishers that didn’t fit their narrative. This went on for years.

Today we know AMP was also a anticompetitive plot to kill off header bidding.

Why should we to believe a word of what Google says about Manifest v3?

> Today we know AMP was also a anticompetitive plot to kill off header bidding.

I completely disagree, and I think this will become clear as information continues to come out.

It's been years since AMP went live. Disagreeing while pointing to information that's been withheld for years and does not (to my knowledge) have a timeline for release... that does not make a very compelling argument. It amounts to "trust us". But we don't-- that's kind of the point.

I interpreted coffeefirst as referring to the current antitrust action against Google, and saying that I expect more information will come out as it progresses.

There will never be a smoking gun because the people cooking up these dark pattern schemes are generally smart enough to not document them. The problem they want solved gets broken up into pieces that are given credible cover stories and then when it is all integrated together the intended outcome happens without it ever being explicitly written down in an incriminating email.

Yes-- while never on a criminal level, I have seen it happen in places where I have worked before.

Good point, that may be what they meant. Although I would not count on all of those details coming out: for years Google has been warning employees against using certain types of language that could in someway look bad from an antitrust/anticompetitive point of view. So I would expect that a lot of documentation, emails, etc will look anodine on the surface through self-censorship.

I don't expect anything that comes right out and says something like "we must implement AMP to as a strategy to remove competition from header bidding". Instead it will mostly be just the standard talking points about user experience and load times.

I could be wrong though: plenty of things have been revealed in things like text messages where people don't think of them as being part of an official record.

Is it in dispute that google added an intentional delay? If it's not, then it doesn't really matter what else comes out.

https://news.ycombinator.com/item?id=25449748

Recently a large software company managed to avoid looking into a bug report for several days about an inability to dial 911 on an Android handset until enough social media indignation was generated (1). However, the org in question ignored it until enough outrage on Reddit was generated and it was eventually noticed. Not one alarm bell seems to have gone off despite all those clever people and funky machines and the much vaunted AI/ML and stuff. That's a bug that might engender criminal liability in some jurisdictions.

In this case, it appears that multiple large orgs are involved: G and M. One provides the environment and the other appears to have dropped their drawers and crapped in it but in the end a telephone should always be able to make emergency calls regardless of what is installed or configured on it.

In the end this sort of thing might look like lack of responsibility due to arrogance due to lack of competition. I'm sure other interpretations are available.

Normally the above should be considered an example of whataboutery but I think your response deserves little else. If you have something to contribute then please do but not that sort of thing.

(1) https://www.theregister.com/2021/12/09/android_911_teams/

[Edit: weird formatting snag, content unchanged]

Stop astroturfing.. Your company is a scummy monster!!

Google has not asked me to comment here, now or previously. When I see incorrect claims about something I have background on I point it out.

But it was your incorrect claim that was trivially disproved.

So if you weren't asked to, you're just astroturfing voluntarily. That's not better, it's worse: If one gives up one's integrity, one should at least get paid for it. Otherwise, one isn't acting just scummily, but scummily and stupidly.

What claim have I made that is incorrect?

This claim: https://news.ycombinator.com/item?id=29505292 Debunked in: https://news.ycombinator.com/item?id=29505552 (as was the attempted defense a year ago that you linked to in response).

Your linked claim is that "AMP was also a anticompetitive plot to kill off header bidding". Your linked "debunking" is about AMP pages delaying loading for non-AMP ads, which is completely unrelated to header bidding.

The claim, in a broader sense, was: "AMP is shit", or perhaps even "AMP is shit, and Google are anti-competitive arseholes". And those are certainly well-established enough by to make any attempt at defending against (either of) them delusional.

I'm happy to talk about specific claims if you want, but I was trying to respond to a specific false claim about header bidding and not signing up to defend all things AMP.

This is just an attempt to rehash the same old arguments provided by Google that have been repeatedly debunked by developers and security researchers.

> I work on ads at Google, speaking only for myself

I'm doubtful about a person's ability to speak for themselves, when they have been consistently defending their employer on HN for years, at every occasion they got.

"It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It"

Also known as Sinclair's law.

> (a) more efficient + (b) more private

This is somewhat debunked in the article of this post.

> the change is that it's now declarative.

In the App MANIFEST. To my understanding, each update of those lists will require an app update (going through Store approval process).

If only it would have been dynamic, the end result would have been much better.

And again, there is no reason to disable dynamic updates if they are only lists of blocked URLs.

I would believe this more if Mv3 didn’t allow extensions to inspect all web requests programmatically, just not block them. Want to exfiltrate your users’ data to attack or track them? Fine. Want to block ads. No way!

> (a) more efficient because you don't need to execute JS to evaluate each request

This is true, but I think overly performance-focused. It doesn't feel like that much time, so I think there's a valid complaint that it doesn't make sense to kneecap flexibility for speed.

> more private because an ad/content blocker doesn't need to be given such broad permissions

Sure, but this doesn't seem like the only possible solution for the people that own the browser. Why not only allow a restricted subset of JS that lacks any form of IO? Or if that's impossible/risky, why not something like Starlark or Lua?

I think this is based on a fundamental misreading of the problem. The privacy concern is that your data will leak, not merely that it's accessible to a third party. The cat binary can read my data, and I'm not at all concerned about that. So can my shell, and likewise on the concern.

Privacy doesn't necessitate this solution. It is one of the possible solutions, but I think is hard to sell as the best solution to the problem. It is likely the easiest.

> There are serious tradeoffs (no request time js makes it less flexible) but it's still very capable and easily can be used to block Google ads.

Those serious "serious tradeoffs" made me completely stop using the web on my iPhone. Yeah, Safari content block can block roughly 80% of web ads, but those extra 20% are extremely annoying.

Web owners use all sorts of trickery to bypass adblockers and serve malware filled ads. Handicapping our current best defense tech against this is a sure as hell way to make me never open chrome again and completely purging it from any friends and family computer.

While there seems to be some disagreement with your position, I just wanted to thank you for being transparent about your involvement at Google. More people should act like that.

They can block Google ads for now. Google is playing a long game.

Reply on news.ycombinator.com