6 ms·

That original post was written by the same Justin Schuh who went on this ridiculous tirade on twitter claiming he headed the manifest v3 adblocker neutering cha

• 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 ago
    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.
    • targonca 7y ago
      His employer considers him trustworthy.
      • deleted 7y ago
        [deleted]
      • nsuser3 7y ago
        I'm not his employer (luckily).
      • prepend 7y ago
        Just because your mom thinks you’re handsome doesn’t mean you’re handsome.
      • sk5t 7y ago
        Trusted to advance his employer's interests, do you mean?
      • staticassertion 7y ago
        I have no affiliation with Google or Justin.
  • dan-robertson 7y ago
    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.
    • shawnz 7y ago
      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.
      • deleted 7y ago
        [deleted]
      • dan-robertson 7y ago
        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.
        • tsimionescu 7y ago
          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.
  • 9HZZRfNlpR 7y ago
    Trustworthy 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 ago
    His 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 ago
    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...
    • vengefulduck 7y ago
      Except the extension could just inject a script into the webpage and exfiltrate data that way.
      • rndgermandude 7y ago
        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.
• magicalist 7y ago
  > the same Justin Schuh who went on this ridiculous tirade on twitter can you link to the ridiculous tirade? Cause here's the text I see in full > The sole motivation here is correcting major privacy and security deficiencies in the current system. I know, because I set that focus, and the team reports up through me. And here's a bit more context on the uBlock assertions. [link to other tweet] > Honestly, all of the negative coverage here is because the team is doing all of this development in the open and engaging with the community. They're taking feedback and making significant changes in response. So the framing here is just not accurate.
  • ngold 7y ago
    Do the merits of his claims hold true? Then I don't care if it's written by a guppy fish with I'll intention. Truth is the standard. Not the writer.
    • dannyw 7y ago
      No. Ublock does not have a performance problem.
    • giovannibajo1 7y ago
      Depends on your point of view. Chrome is going to use the same architecture that Safari has had for a few years (on iOS and Mac): data-driven content blocking, where rules are declared by the extensions, and then read and implemented by the browser core with no JavaScript involved on each request. Javascript-based content blocking is technically slower because you need to invoke V8 on all requests, and then it’s up to the extension to make sure that the JavaScript code is fast enough. It surely is more flexible (as you can do whatever you want in that javascript code) but it’s hard to beat a simpler, data-driven content blocking engine written in native code and integrated in the core. Whether this difference in resources does have a concrete impact or not, remains to be seen. The fact that Apple Safari did it first makes me believe that there is some truth in the technical merit argument; surely Apple didn’t want to make sure their content blockers were ineffective, but was actually using the same approach as always: providing a possibly “weaker” but far more efficient implementation (compared to “de facto standards” on other platforms) to protect iOS resources usage.
• deleted 7y ago
  [deleted]
• ChrisCinelli 7y ago
  His job history may tell you another reason on his positions about the subject: https://www.linkedin.com/in/justinschuh/ https://www.linkedin.com/in/justinschuh/
  • hellcow 7y ago
    TIL the engineering director for Chrome comes from the NSA and CIA. Surely he cares deeply about everyone's privacy now, though... As for me, I'll use Firefox.
    • sterlind 7y ago
      Over a decade of military and then offensive CNE work, a quick tour around the private sector and then a decade of leading Chrome. I guess Chrome had a ton of security issues early on? I can't really think why they'd pick someone like this for directing Chrome and not Chrome security specifically. Even picking him for his contacts doesn't make sense - it's a free product, not much in the way of government contracts to land. And from a "mole" perspective, it'd make more sense to go to Project Zero anyway. Also, genuine question: isn't it hard to go private sector if most of your resume is redacted? How do you convince employers that you're talented?
      • lightedman 7y ago
        You take the test which YC people fail to provide. One that tests integrity along with diligence and capability.
      • CydeWeys 7y ago
        A lot of the time (most of the time), you end up in a particular specialty by career accident, not because you're genuinely excellent at that and only that, and not good at related adjacent things.
    • Hnrobert42 7y ago
      There are some who work for those organizations that care passionately about civil liberties and work hard to preserve them while still carrying out necessary functions of government.