> Figma was born out of founder’s need to find a proof of concept test case for real-time collaboration JavaScript engine they created. They stumbled on this idea.
citation needed?
The article discusses adding collaboration to an existing application, the opposite of what this comment asserts.
Not OP, but my reasoning goes like this: mandatory signing means that Mozilla can singlehandedly decide what extension I can and can't install. I might disagree with their decision sometimes, so I want to be able to install those extensions regardless of what they think. Maybe I'm perfectly fine with a specific extension that does something against the AMO rules and want to install it from the creator's website. Maybe I want to try a beta version or downgrade to an older one because something is wrong with the latest one - all of this is possible by just downloading a release from GitHub and clicking the file, but it isn't allowed.
It also means that is AMO goes down or I can't use it for whatever reason, I can't use any extensions. This has happened in the past!
Is "I'm perfectly fine with a specific extension that does something against the AMO rules and want to install it" a thing that happens in practice? (this is an honest question, I haven't come across extensions that I was interested in but that have been explicitly banned)
My original comment was reacting to the description of signing as "nonsense" but there doesn't seem to be understanding of why it exists. In brief: Mozilla can (and does) block specific extensions when they are found to be doing something malicious. From what I have seen the bar for this is very high, this applies not just to extensions that do things like extract user data, but to those that do it in a deceptive way without disclosing to users what the extension does.
Anyway, this blocking works based on a unique ID embedded in every extension. But if extensions were not signed, a bad extension could just claim to be "uBlock0@raymondhill.net" or something, trivially evading blocking. Signing isn't about somebody passing judgement on individual extensions, it is about ensuring that addon IDs are unique and not spoofable.
You might reasonably say that there should be a user option to disable the signing requirement, but how would this work exactly? You wouldn't want the user to have to affirm that they want this setting every time they start the browser, which means it has to be stored somewhere on disk with other user settings. But this is, again, trivially forgeable by any software that has write access to the part of the system where user preferences are stored.
I don't believe that anybody at Mozilla wants to put arbitrary limits on how people can use Firefox, but they do have a strong interest in protecting users who don't have the technical savvy to evaluate the implementation of extensions they install (which I would hope anybody who is installing unsigned extensions does!)
The system described above was built up (over the years!) in response to actual abuse of extensions by bad actors. The choice between having reasonable protections for the overwhelming majority of users versus offering flexibility in this case is a crummy one to have to make, but the compromise Mozilla settled on is allowing for unsigned extensions in developer edition, Nightly builds, or custom-made builds.
You may personally prefer a different outcome for this decision but calling it "nonsense" or ascribing other motives to Mozilla sounds to me either uninformed or disingenuous (or maybe just unable to consider the reality of weighing the needs of different groups of users when making a decision like this).
In addition to the proportion of interest decreasing over time as the principal is paid down, there's an additional factor: the mortgage payment is fixed for the full term of the loan at purchase time. So suppose you take out a 30 year mortgage with a monthly payment of $2000 in 2021 and you never pre-pay or refinance. In 2050, you'll still be paying $2000 per month even though rents will have risen with inflation over that time.
You can use open search -- if you load a page that provides an open search description of itself (such as startpage.com) and then click on the "Page actions" menu (the 3 dots in the url bar), one of the options there is "Add search engine".
One you've added it, you can open about:preferences and set it to the default from there. Perhaps not the smoothest experience but it is possible...
(disclosure: I am a former member of the Mozilla addons engineering team. I haven't been a Mozilla employee for more than a year and don't have any internal information about recent developments)
Regarding Android: As many folks probably already know, the new Firefox for Android is a complete rewrite of the front-end to use an embedable version of gecko (GeckoView). This entails re-implementing all the extension API support that existed in the old monolithic browser. The timeline for switching from the Fennec (the original Firefox for Android) to Fenix (the GeckoView based version) was driven by a bunch of conflicting things. In an ideal world it wouldn't have happened until the extension support was broader, but we reached a point where Fennec can't be maintained any longer yet full extension support in Fenix isn't ready. I don't agree with the way Mozilla has handled this, but to be fair to them -- if they provide a way to easily enable extensions that they haven't tested they will be flooded with reports about extensions that don't work. Sorting through all this would be a huge distraction to a team that's already busy trying to complete the extension implementation.
It seems popular here to be skeptical about Mozilla's goals and ascribe hidden motivations to them, but if you follow the work that's happening on GeckoView extensions (go to bugzilla.mozilla.org search for product GeckoView, component Extensions), you can see that progress is happening slowly but steadily.
As for desktop and additional extension APIs: I think that this is another place Mozilla has dropped the ball on communication. WebExtensions support a concept of "experimental APIs" with which developers can easily prototype new extension APIs. The intention here was always that this would be an avenue for developers outside Mozilla to experiment with new ideas that could eventually become regular apis available to all extensions. To be clear, the bar here is high: among other issues, many things that developers would like to be able to do from extensions are prone to abuse by malicious extensions. Figuring out a way to create an API that allows for customization while also helping users understand how extensions are changing their browser and make an informed choice about whether to allow it is a difficult problem! The developer community seemed to take Mozilla's intention to expand extensions' capabilities as a promise to have Mozilla employees do all that work, rather than an invitation to work together with the community on the process of designing new APIs that can be used in a safe way.
> if they provide a way to easily enable extensions that they haven't tested they will be flooded with reports about extensions that don't work.
Well, it used to be the case that extension had to explicitly declare which applications they support (e.g. thunderbird, seamonkey, firefox). That's not the case anymore with the webext manifest format, but at least temporarily mozilla could have introduced some sort of opt-in by extension developers to avoid this scenario without gatekeeping. The assumption would then be that the developers tested that the available api subset on android is sufficient for their extension.
> The developer community seemed to take Mozilla's intention to expand extensions' capabilities as a promise to have Mozilla employees do all that work
I was interested in that, but when I looked into it it turned out that it was limited to developer edition and required two separate extensions to be installed it's a lot of work that only a handful of users could ever test and after going 2 migrations (XUL -> jetpack -> webext) it felt like yet another temporary thing with uncertain future. It seems to have changed a bit since then, so maybe it's worth looking into it again.
As for experiments, the days of two separate extensions are long gone :) The point about multiple migrations (you didn't even mention e10s!) is a fair one...
I sincerely hope that you are right and I am wrong here, in a few months we'll see of course. I've been with the Mozilla project for 15 years myself, and I've grown more than a bit disillusioned. I know that these people are trying to do the best thing possible. But I also learned that there is nothing more permanent than a stopgap solution. Once things are released and “work” the pressure is off, and there is always something more important requiring attention.
However, this API could be used to optimize some of (not all of) the networking filtering that uBO does. Network filtering is distinct from cosmetic filtering, the latter is what injects scripts into every page.
The uBO wiki has some nice documentation of the different features, measurements of their overhead, etc. E.g.: https://github.com/gorhill/uBlock/wiki/Doesn't-uBlock-Origin...
Great so not javascript running "in the context" of the page.. just javascript running.. somewhere else, for every single network request that is made, and that still has access to the page.
I know a lot of web developers don't want to hear this, but throwing more javascript at the problem isn't always the best solution.
> I'm glad to see uBlock Origin getting some much needed competition,
Why does uBO need competition? It appears to me that it offers the best combination of features and performance out there.
Moreover, the choice to implement as a proxy has some serious drawbacks, features like uBO's cosmetic filters won't be practical to implement in a proxy.
Competition in any space is extremely valuable. If for whatever reason uBlock Origin went away tomorrow there would be a void to fill. Furthermore, competition drives innovation. A separate project may figure out a better or more efficient way to accomplish the same goals and they could potentially share their findings with the uBlock team or vice versa and everyone benefits.
This. It is exactly what happened about a year ago when this performance study[1] was published. In the months that followed, uBlock Origin, Brave and Adblock Plus all worked pretty hard on improving the performance of their content blocking engine, and used the benchmark and open-source dataset from the study to measure their optimizations.
The result is that now, all users of either of these extensions benefit from a better and faster product, thanks to emulation between competing projects. This would not necessarily happen in the absence of competition. In the end, users benefit.
(Disclaimer: I am one of the authors of the performance study)
> If for whatever reason uBlock Origin went away tomorrow there would be a void to fill.
If for whatever reason uBlock Origin went away tomorrow there would be a fork. uBlock Origin is the second (or third, I forget) fork of the original project.
uBlock Origin is still almost exclusively maintained by the original author: Raymond Hill. He was already behind uBlock and is now working on uBlock Origin (the original uBlock being basically stale).
Sure, no argument there. But the original comment said that in this case it is "much needed", suggesting something more specific than just "competition is generally good".
Lots of comments here are making non-specific arguments that "competition" leads directly to improvements in products/technology. It seems to me what is missing here is a concrete idea for making an ad-blocker work better, not an avenue for making a new/different approach available. (In particular, the goals of this project seem to be much more about working around upcoming Chrome extension changes rather than about improving the behavior in some way)
I use, appreciate, and recommend uBO to everybody.
Having said that, competition both puts some pressure to improve more, and also explores some alternative, possibly better, avenues. Historical example: Firefox was significantly better than IE 6 / 7 / 8, and yet ended up improving much more in the course of competing vis a vis Chrome.
All in all, a staunch-and-fair competitor is good to have.
citation needed?
The article discusses adding collaboration to an existing application, the opposite of what this comment asserts.