> 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.
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 "[email protected]" 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.
> In a short time we'll read a statement -- released on a Friday afternoon -- stating the EOL for blocking webRequest
Good grief, only the HN Mozilla-haters could take an announcement that plainly says that they are keeping webRequest and read it as the opposite.
Think about this for a minute, they are in the midst of a gigantic engineering project where the cost of keeping blocking webRequest functional is certainly significant. If there was any reluctance to keep this capability around, this would be the time to stop supporting it.
You may disagree with decisions folks at Mozilla have made in the past but if you think they're careless enough to invest significant time and energy now to port webRequest to work with all the other changes described in this article, only to kill it shortly afterward, you're simply not being rational.
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...
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...
(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.
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...
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'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.
> To be clear, this is more of a criticism to Mozilla Firefox's security model, not to this particular extension.
It's a fair comment, but this extension works by injecting javascript into every page the browser loads. If this capability were removed or even changed, it would break a ton of existing extensions (and compatibility with the many extensions written for Chrome).
Given the nature of javascript and the web, once you can run a bit of javascript on a page, you can do just about anything, so the phrasing "can access data" sounds scary but it is accurate. Of course, "can" doesn't mean "does", hence all the other commenters suggesting auditing the code.
You can see what is gathered by opening about:telemetry. That page also has links to dashboards derived from telemetry data.
You can read the policies that apply to what data may be collected at https://wiki.mozilla.org/Firefox/Data_Collection
This is a moronic argument -- "if you fix this vulnerability used by malware, the malware authors will find another vulnerability so there's no point removing the vulnerability".
citation needed?
The article discusses adding collaboration to an existing application, the opposite of what this comment asserts.