5 ms·
Justin is a trustworthy guy and, while unfortunate, I believe the Chrome security team was acting in good faith with the manifest v3 changes.
by staticassertion 7y ago
Justin is a trustworthy guy and, while unfortunate, I believe the Chrome security team was acting in good faith with the manifest v3 changes.
- ocdtrekkie 7y agoWe 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.
- targonca 7y agoHis employer considers him trustworthy.
- deleted 7y ago[deleted]
- nsuser3 7y agoI'm not his employer (luckily).
- prepend 7y agoJust because your mom thinks you’re handsome doesn’t mean you’re handsome.
- sk5t 7y agoTrusted to advance his employer's interests, do you mean?
- staticassertion 7y agoI have no affiliation with Google or Justin.
- dan-robertson 7y agoThere 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.
- shawnz 7y agoThe 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.
- deleted 7y ago[deleted]
- dan-robertson 7y agoI 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.
- tsimionescu 7y agoYou 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.
- 9HZZRfNlpR 7y agoTrustworthy to who? Definitely not for the 99.9% of the population. Helping to build the biggest spying machine gestapo would be jealous of can be only done by men with very low morals.
- JohnFen 7y agoHis argument just doesn't hold up, though, so I have a hard time thinking that it's anything more than a sales job.
- rndgermandude 7y agoThey 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...
- vengefulduck 7y agoExcept the extension could just inject a script into the webpage and exfiltrate data that way.
- rndgermandude 7y agoThat 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.