Hacker News Reader

Comment by staticassertion | Hacker News Reader

Justin is a trustworthy guy and, while unfortunate, I believe the Chrome security team was acting in good faith with the manifest v3 changes.

View on HN

We probably shouldn't refer to someone as "trustworthy" who is repeatedly demonstrated to be blatantly lying and spreading clear falsehoods.

As the parent stated, manifest v3 changes didn't hide any information from extensions (hence, by definition, not improving privacy), and independent studies completely discredit Justin's claims about the effectiveness of ad targeting.

His employer considers him trustworthy.

I'm not his employer (luckily).

Just because your mom thinks you’re handsome doesn’t mean you’re handsome.

Trusted to advance his employer's interests, do you mean?

I have no affiliation with Google or Justin.

There were two parts to the changes. One that stops the current system of ad-blockers requiring them to use a different url-filtering api (specifically one which denies them the ability to read the urls), and one that puts really tiny limits on that api.

I think the first change was in good faith and reasonable. Provided the filtering abilities are reasonable, it is good for privacy and performance (and it would make sense for eg Firefox to support this api too). (I think I would be happiest with an api that lets you write a pure (somehow enforced) js function from url to an action (eg block/allow/upgrade to https) and 4 bits of data).

Although obviously it is unfortunate if it stops various good extensions from working well.

For the second change, I can’t decide. It could be that they were made deliberately small, or it could be that they didn’t really know what appropriate size limits would be and picked limits which were way too small.

The limits aren't the only problem -- forcing everyone to use only the declarative API restricts the ability of adblocker vendors to develop new techniques for blocking different kinds of ads or privacy threats.

I agree that there are good reasons to want something less declarative but I claim that only allowing declarative rules is a reasonable bona fide choice from a security or privacy perspective. In particular if there were no question of motives, I think there would be far fewer complaints about this system being implemented. Indeed Apple’s system for mobile url filtering works like this and though some people complained about the lack of expressivity I didn’t see any complaints that it was some kind of conspiracy to sell ads.

You keep missing the fact that there is no security/privacy advantage to what Google did, since the API for an extension to see every URL being accessed and use it in arbitrary ways still exists. They only removed the part where the extension could block that request from happening.

Selective request blocking has huge security implications. In many ways it's a similar attack surface to arbitrarily rewriting the content. (Imagine making some charges to your credit card, then blocking the request that lists card charges on your bank's website.)

No, they did not deny ad blockers the ability to read the URLs. They removed the ability to modify requests via the webRequest API, but left in the functionality for observing all requests made.

How long until we find out that Google adservers and tracking can not be blocked in the new API?

Who really thinks a whole professional team of developers goes and neuters adblockers for nothing?

Let us not be naive.

They didn't even try to solve it.

It took me less than 2mins of thinking (and I am hardly the smartest guy ever) about it to figure out that you can solve the potential privacy hazard that webRequest poses (extensions siphoning off request data) by introducing a special kind of content script, let's call it a request-script, that is input-only/one-way-communication except for a limited set of request manipulation and only when asked by the browser. Such as blocking requests. Of course, the devil is in the details here of what to allow and not allow.

The input-only nature still allows for it to be feed new/updates instructions, and it being a script it can still implement rules that cannot be implemented with a fixed rule list like google proposes. But it cannot make web requests and exfiltrate data like that, it cannot communicate back to the host extension and exfiltrate that like that, it cannot exfiltrate data, period. It only ever is allowed to perform certain (not all) request modifications and only when asked by the browser itself.

That leaves the "performance issues" google claims are a major problem. And indeed, there is a chance a misbehaving extension might obliterate performance. But you can do a lot of things in this space, too. "You" are the browser after all and any extension or any request script is at the mercy of what you're allowing it to do anyway. A low hanging fruit here would be to enforce that a request-script has to give an answer in a sane amount of time. Or warn users when an extension slows down requests too much.

And ultimately users will decide if a e.g. 100ms delay for each request is preferable over downloading a few megabytes of video ads for them or not. That is if google was really interested in protecting their users and improving their experience and did not have other motives...

Except the extension could just inject a script into the webpage and exfiltrate data that way.

That requires some different permissions to the webRequest permission in question.

But yeah, a bad actor would probably just switch away from webRequest to <all_urls> + webNavigation permissions and siphon off data with content scripts. So google's argument that is is a privacy issue and thus they just HAVE TO cripple their webRequest APIs doesn't get any better.

That is still possible with Chrome's new declarative model too, so the parent's idea is strictly an improvement.

> 100ms delay for each request

NOPE

That was an example - it's actually more like one or two ms.

Blocking is itself a communications channel. You have some data to exfiltrate from extension to server. The page embeds a bunch of URLs to your ad server, you selectively block based on the data to exfiltrate, the server gets 1 bit per URL.

Any additional blocking capabilities (reordering, delaying, selective header stripping) increase the number of bits.

His argument just doesn't hold up, though, so I have a hard time thinking that it's anything more than a sales job.

Reply on news.ycombinator.com