HN user
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.
No, but there is atom (https://www.figma.com/blog/feed/atom.xml) and jsonfeed (https://www.figma.com/blog/feed/feed.json)
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).
Can you say more about why this is "nonsense"? Do you understand why it exists and disagree with the reasoning? If so, can you elaborate?
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...
at least temporarily mozilla could have introduced some sort of opt-in by extension developers to avoid this scenario without gatekeeping
Yep, I agree completely. In the mean time, there is https://github.com/mozilla-mobile/fenix/issues/14034
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.
The webRequest api uses javascript, but with code that runs in the context of the extension, not code that is injected into web pages. You can read a bit more here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Chrome has a beta extension API that does this: https://developer.chrome.com/extensions/declarativeNetReques...
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...
Not sure why you have that impression. Chris Beard, the previous CEO served from 2014 until December.
Its being worked on: https://bugzilla.mozilla.org/show_bug.cgi?id=1080682
Competition in any space is extremely valuable.
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.
Speaking of auditing extension code, I like https://addons.mozilla.org/en-US/firefox/addon/crxviewer/
There's some good information here: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...
If you want to jump right in and look for bugs that match your skills/interest, try: https://codetribute.mozilla.org/
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
..which have nothing to do with the Open Web,
Which, in turn, has nothing to do with the origin article. Read it again, it is only about how search engines are defined inside add-ons.
What are you crying about? Both Firefox and Chrome support a common format for defining search engines from add-ons:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
https://developer.chrome.com/extensions/settings_override
The fact that it doesn't have "open" in its name doesn't actually make it any less open or interoperable. This is about standardizing on having a single and modern way to define search engines, nothing more and nothing less.
There's a very good point here about the limits of using usage telemetry -- given a question of the form "should we invest in improving feature X?", it's a mistake to decide not to simply on the basis of low usage. Low usage could be because users simply aren't interested in the feature (in which case it probably doesn't make sense to invest in improving it), or it could be that they really are interested in it but they don't use it because of limitations (in which case it may well make sense to invest in improving it).
However, I don't believe that's an issue for the specific features discussed here (userChrome.css and userContent.css). These are by their nature features that are only accessible to users with particular knowledge/skills and the Firefox user base is much broader than web developers. But moreover, nobody is proposing to remove this capability and I think its debatable whether it is now harder to access in practice (existing profiles that use this capability were automatically converted, for new profiles you already have to manually add a file to the profile directory, flipping a preference in addition is not a serious barrier).
I don't know if it's a purposeful process or not, but I'd say it's perfectly reasonable for users to think that pref-gating is the first step toward removal
It might be reasonable if no other reason was given, but there is a specific and compelling reason (avoiding unneeded main thread I/O during startup for something like 99% of users) here.
How much of a performance improvement does this make?
For a user with an SSD, perhaps not much. But there are still a lot of users out there with magnetic hard drives. Firefox has to do a decent amount of I/O at startup, and unneeded disk seeks add up for these users.
In addition, Firefox formerly checked for these files on the main thread, which is especially bad for performance. (Firefox engineer Mike Conley wrote about this at length at https://mikeconley.ca/blog/2019/05/16/a-few-words-on-main-th...)
If you read through the related bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1541233), you can see that folks went to some trouble to keep anything from breaking for people using these files today. The claims that this is a step toward removing the files completely is FUD.
If that's what best for you, its trivial to change it in about:preferences (in the "Home" section). What's "best" for everybody is hard to define, I would bet that Mozilla has studied this significantly more than Grue3 has.
The issue isn't about having a sufficiently scary warning. It is that the browser has to store the fact that the user has agreed to this warning somewhere (ie, presumably in the user's profile). That means any other software running on the computer with regular user permissions can make the same modification to the profile and then install an unsigned extension without the user's consent.
Typically, when Mozilla finds out about software installing extensions without user consent, the extension is added to the blocklist, but if the extension is unsigned it can just claim that it is ublock origin or adblock plus or some popular extension, leaving no practical way to block it.
This is described in greater detail at https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte...
(in full disclosure, I am a Mozilla employee)
You're telling me that the intended behavior is that FF allows add-ons signed by an expired cert?
The leaf certificate is specific to a particular instance of an addon. Firefox has a separate, more flexible capability called the blocklist that can disable individual addons. Since the blocklist exists, enforcing expiration dates on the leaf certificates wouldn't help in any way, but it would require re-signing and re-distributing all addons periodically. So, yes it was a deliberate decision to ignore expiration dates on leaf certificates.
If that is the case, then what is the point of the signing system in the first place?
I'm not sure if this was meant literally or not but it is outlined here: https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte...
You can choose the level of risk. If you want to run unsigned extensions, use Developer Edition or Nightly.
(disclosure: I am a Mozilla employee but not commenting in any official capacity)
"Give me control over what code I run on my computer" (meaning "provide a switch to disable the requirement that extensions be signed") keeps coming up over and over. And perhaps it hasn't been clearly stated but the problem is this: if there's a switch that a user can flip, the browser has to record the state of that switch somewhere (presumably on disk). If such a switch becomes available, we'll quickly be flooded with malware that flips that switch without users' consent. At that point, there's no way to tell the difference between savvy users making an informed choice to enable unsigned extensions and malware doing it behind their backs. The browser can do various things to obscure the way that setting is stored, but ultimately any method the browser uses to read and write the state of that switch is something that other software can easily mimic.
This is not a theoretical concern, a modern web browser target is an irresistible target for all sorts of get-rich-quick scammers -- if you don't experience this day-to-day its due in no small part to the fact that browser vendors among others are constantly working to keep the bad guys at bay. But make no mistake: the bad guys are out there and they quickly find and exploit any opportunities that are available to them.
So as to the problem of how to let users disable signing but ensure that they have made a conscious decision to do so, there is a stark tradeoff here: giving the most savvy users that switch necessarily makes other users less safe. The solution that Firefox has opted for here is to handle this tradeoff differently on different channels. The release channel (aka the stable channel, or the thing you get by default when you download Firefox) is intended for a very wide audience, and so it handles this tradeoff by favoring safety for all users regardless of their level of technical knowledge. The developer edition and nightly channels are intended for more technically savvy users and they handle this tradeoff differently; specifically they do provide a switch for disabling extension signing.
If there are other (practical and effective) ways to solve this problem of determining true user intent, I (and I'm sure many many others) would be very interested in hearing about them. In the mean time, using the mass-market versus developer-focused channels as a signal for users' preferences on the risk-configurability continuum seems like a reasonable way to handle this.
The technique of attemping to load web accessible resources does not work in Firefox. For starters, Firefox uses moz-extension: instead of chrome-extension:, that's obviously trivial to adapt to, but Chrome then uses the extension's global identifier in those URLs, while Firefox uses a locally generated identifier, specifically to avoid this sort of fingerprinting.
In a sandbox even I, as the owner of the computer, can't let them out of. That's not cool.
If you want unsandboxed extensions, you can install Nightly or Dev Edition and flip the extensions.legacy.preference. The basic problem with providing a simpler escape hatch on release Firefox is that if you compare the number of users who are equipped to make an informed choice about allowing extension X arbitrary access to browser internals versus the number of users who will be tricked into letting malware do terrible things, the second number is multiple orders of magnitude larger than the first. I understand why folks are unsatisfied with the "use Nightly or Dev Edition with the preference flipped" solution but I am certain that it is the least bad option.
I haven't looked closely at the extension but I think the two big building blocks are sidebars [1] and the tabs API [2], both of which have many applications outside of tree style tabs. The "hide the tabstrip" bug mentioned in other comments here is more narrowly focused than those two but it hasn't landed yet...
[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/us... [2] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/AP...