3 ms·

This a good example of why manifest v3 sucks. By definition, it can't do anything like this...no live code hueristics are possible. It's a war of escalation w

• codetrotter 2y ago
  Abandon Chrome, embrace Firefox.
  • ilrwbwrkhv 2y ago
    [flagged]
• gruez 2y ago
  >This a good example of why manifest v3 sucks. By definition, it can't do anything like this... Technically manifest v3 has nothing to do with APIs that the browser makes available to extensions. On firefox manifest v3 is supported with blocking web request[1], which is the filtering api prior to "manifest v3". Therefore the statement that it certain functionality "by definition" is false. [1] https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/ https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
  • sieabahlpark 2y ago
    [dead]
  • WD-42 2y ago
    OK so Google's near monopoly implementation of V3 sucks. Technically a difference, but practically not so much.
  • fallingsquirrel 2y ago
    Exactly this. There's some good stuff in MV3, but Google decided to take the opportunity to smuggle in some self-serving changes, similar to how Congress likes to sneak controversial laws under the radar as part of unrelated bills*. * https://en.wikipedia.org/wiki/Rider_(legislation) https://en.wikipedia.org/wiki/Rider_(legislation)
  • takeda 2y ago
    I'm confused, isn't the Manifest V3 essentially just API spec?
    • nine_k 2y ago
      Yes. The point is which APIs Google exposes through it.
    • tyingq 2y ago
      They trojan horsed hobbling webRequest.onBeforeRequest into their manifest v3 design doc and rollout. Which is part of what would give you request time cloak detection.
  • tyingq 2y ago
    > Therefore the statement that it certain functionality "by definition" is false. Here's the design document. The hobbling is noted there as part of the spec. "API Changes WebRequest: Restrict the blocking capabilities of the webRequest API." https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit?tab=t.0#heading=h.9lwe237fxtp2 https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz... That firefox chose to skip that portion of the design and still call it 'v3' doesn't change history. A true-to-spec implementation kills live heuristics.
• madeofpalk 2y ago
  There's no reason why a declarative manifest v3 API couldn't offer this. If I'm reading the commit details correctly, it could work even better by being better integrated into the request flow to block the request on the actual IP address used before anything is sent to the servers. Of course, this all relies on browser vendor (Google) wanting to add this API. Doing this imperatively with "live code" allows for innovations in userland before browser makers add built in support for it.
  • tyingq 2y ago
    It could. Google won't do that for chrome. Had they not taken away onBeforeRequest with manifest V3, plugins could implement it themselves. Which is the thing you're suggesting...before the request goes.
    • madeofpalk 2y ago
      The commit message details the caveat of using onBeforeRequest, and how it's not perfect because it's called at the wrong time in the request lifecycle with incomplete info.
      • tyingq 2y ago
        This commit is using onBeforeRequest: >The change allows early availability of ip address so that `ipaddress=` option can be matched at onBeforeRequest time. It is using some other functionality, on Firefox only, to get that early availability. But I'm saying Chrome is a non-starter since onBeforeRequest is hobbled there. So the "early availability of ip address" doesn't help. You need both.