Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proxy Chrome extensions are not going to be usable in MV3

bugs.chromium.org

Post reply on HN
Print view View original

191–200 of 215 posts

Re: Proxy Chrome extensions are not going to be usable in MV3

#191

Post by erklik »

esperent wrote: post #186
erklik wrote: post #171

Earlier quoted context omitted.

Doesn't it? Product A is bad, thus use Product B. That's how most of my problems with different products are solved.

What if product B is also bad? And there's also a product C, D, E but when you check them out you realize they are essentially clones of product A?

Firefox is a legitimate alternative, it works for >99% of the world's websites and is an actual alternative i.e. not a clone of Chrome. I've been using it for nearly the last 5 years full-time and have never needed to open Chrome. I am not sure how one can pretend otherwise, so no, I don't think just saying it's "bad" and ignoring it as an alternative is viable.

Do some Google websites perform worse on Firefox? Sure, but the entire reason that's because people don't use Firefox enough i.e. some websites are worse on Firefox. You just go around and around. If the audience of HN is not able to make that sacrifice (not use some of the GOOG's website) then we deserve the monopoly of Chrome.

Other than that, I also think we need a third alternative for Browsers. Ladybird is in the news these days, and if you're a dev and care about this issue, we should all be contributing to it.

I agree about your clone comment ala Brave, and so on.

Re: Proxy Chrome extensions are not going to be usable in MV3

#192

Post by oefrha »

londons_explore wrote: post #46
yegor wrote: post #4

As a proxy extension developer, this is absolutely maddening. We're forced to choose between auth-less open proxies (bad), or baking in a wacky authentication scheme through a side channel (also bad). MV3 drops in 2.5 months, and will leave tens of millions of proxy extension users unable to use products they paid money for. This is all on top of the many other issues with MV3 that Google is pushing under the guise o…

Is there really nowhere else to store Auth information in a synchronous datastore? For example it looks like you could use a lambda function with the Auth info pre-bound...

One big thing about MV3 is that background script, persistent or not, is no more. You have a web worker that can start afresh at any point, outside your control. So variables assigned asynchronously outside your event handler (which must be registered synchronously at the top level) scope don’t work reliably.

Re: Proxy Chrome extensions are not going to be usable in MV3

#193

Post by dotproto »

HellsMaddy wrote: post #125

Manifest V2 deprecation is likely going to break extensions that inject userscripts, like Tampermonkey [0] and SurfingKeys [1]. The Chrome team has been rather unhelpful. They've promised to add support for power-user tools like these in MV3: dotproto from the Chrome team commented on May 27 [2]: > @mon-jai, the short answer is no, I don't have any updates to share. That said, I'll reaffirm that we plan to support us…

Hey, I'm that Simeon/dotproto guy!

We discussed Chromium's current plan to support user scripts managers in Manifest V3 during our WebExtensions Community Group (WECG) session at TPAC[1] last week. The notes for that meeting haven't been merged yet, but there's an open PR[2] and when they are they will live here[3].

In short, the current plan in Chromium is to require end users and extension authors to opt into execution of arbitrary scripts via a Chromium UI setting and new permission, respectively. During the meeting Firefox folks raised some questions/concerns about this plan and it's probably best to try to align with them on next steps if possible.

And typing this out is making me realize we don't have a great tracking issue for this in the WECG repo. Just threw together a placeholder issue[4] to track discussion in this area.

[1]: https://www.w3.org/events/meetings/7bbba4a3-8305-45cd-a998-6...

[2]: https://github.com/w3c/webextensions/pull/277

[3]: https://github.com/w3c/webextensions/blob/main/_minutes/2022...

[4]: https://github.com/w3c/webextensions/issues/279

Re: Proxy Chrome extensions are not going to be usable in MV3

#194

Post by Schroedingersat »

teawrecks wrote: post #146
jacooper wrote: post #127

Earlier quoted context omitted.

Mozilla only has themselves to blame. I'm going to repost a previous comment here. > https://news.ycombinator.com/item?id=32741481 > I used to refuse Chromium for the Same reason. > But honestly it already happened, Firefox is already irrelevant. > Mozilla is mis-managed organization that is funded to avoid anti-trust investigations, they dont fully push for privacy because they are afraid of google, do out of touch…

I'm out of the loop. I've been using FF for years without any issues across multiple OSes and devices. I plan to continue doing that. I simply don't understand the negative sentiment I see about it, it's served me very well.

The negative sentiment is advertising for brave (an advertising company) to get people to switch to their ad delivery software.

Re: Proxy Chrome extensions are not going to be usable in MV3

#195

Post by dotproto »

yegor wrote: post #4

As a proxy extension developer, this is absolutely maddening. We're forced to choose between auth-less open proxies (bad), or baking in a wacky authentication scheme through a side channel (also bad). MV3 drops in 2.5 months, and will leave tens of millions of proxy extension users unable to use products they paid money for. This is all on top of the many other issues with MV3 that Google is pushing under the guise o…

A couple hours ago I added a comment to the bug to describe our current plans[1]. TL:DR; you'll be able to use webRequest.onAuthRequired in MV3.

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=113549...

Re: Proxy Chrome extensions are not going to be usable in MV3

#196

Post by WirelessGigabit »

somat wrote: post #61

Are proxy extensions just a hook to set the http_proxy? I always have a hard time with chrome. because where firefox has a config area to set the proxy chrome wants to use an environment variable. so do these proxy extensions fill this missing config gap?

Yes. I can do a per page proxy with extensions which is helpful when doing debugging / mitm.

Re: Proxy Chrome extensions are not going to be usable in MV3

#197

Post by fungi »

erklik wrote: post #171
naikrovek wrote: post #124

Earlier quoted context omitted.

that doesn't fix the problem, though.

Doesn't it? Product A is bad, thus use Product B. That's how most of my problems with different products are solved.

no bc they are leveraging monopoly in search to advantage their other products and undermine competition.

im a relatively happy firefox user, but at this point to say mozilla significantly mitigates googles monopoly is as plausible as when microsoft claimed that BeOS somehow mitigated theirs.

Re: Proxy Chrome extensions are not going to be usable in MV3

#198

Post by WirelessGigabit »

TedDoesntTalk wrote: post #153
JohnFen wrote: post #113

Earlier quoted context omitted.

It greatly restricts how effective ad blockers can be.

Proxy extensions are not the same as adblockers.

It is used as such by many people, for example those who cannot install a system proxy.

Re: Proxy Chrome extensions are not going to be usable in MV3

#199

Post by reciprocity »

roblabla wrote: post #172
_aizw wrote: post #169

Earlier quoted context omitted.

Like what? I can't imagine firefox has done anything worse then MV3.

Oh, I don't know, maybe breaking literally all of their extension with the deprecation of XUL? I'm a happy firefox user, and I'm pretty sure it was the right choice IMO, as firefox is certainly much more stable and fast now than it was before. But it was certainly a very, very rough process and left some very popular extensions broken without alternatives for months and even years before the necessary APIs were added…

"Breaking all of their extensions with the depreciation of XUL" is one interpretation, another one is that it was needed (of course it was the correct choice!) and there wasn't going to be an easier approach than just ripping the band-aid off. It needed to be done, it's done, and now instead of discussing the larger picture, we're talking about XUL depreciation from Firefox which happened in 2018. So what's your point?
Post reply on HN