I find this pretty exciting for (hopefully; someday) wider adoption of alternative protocols:
Starting with Firefox 59, several protocols that support decentralized architectures are available for use by extensions. The white-listed protocols are:
so basically the explanation is simple. There is a whitelist of protocols you can have your WebExtension take over.
If the protocol you want to control is not on that whitelist such as an hypothetical "catgifs:" protocol, you need to prefix it like: "web+catgifs" or "ext+catgifs" depending if it will be used from the Add-on or by redirection to another Web page. This makes it inconvenient to use with lots of decentralization protocols because in many other clients we are already using urls such as "ssb:" and "dat:" (eg, check out beaker browser). In essence this allows us to implement many new cool decentralization features as add-ons now that we can take over protocols, so, you could be in Firefox browsing the normal web and suddenly see a "dat:" link, normally you'd need to switch clients to a dat enabled app, now, you can have an add-on display that content in the current user-agent you're using.
Still, there is another feature that we need before we can start really implementing decentralization protocols as pure WebExtensions, we need both TCP and UDP APIs like we had in Firefox OS (as an example, Scuttlebutt uses UDP to find peers in LAN and its own muxrpc TCP protocol to exchange data, DAT also uses UDP/TCP instead of HTTP).
I have been building little experiments in Firefox for interfacing with Scuttlebutt which can be seen at:
Decentralization and safer protocols are needed. Plain HTTP and even HTTPS are really not the best one could come up with. There are better alternatives, but using them is not always easy. So, thanks a lot for your work on making that easier!
In essence, your connection to a given peer is encrypted in a way that only you both have the keys, even if someone breaks that key (such as the peer being a bad agent) it would not compromise your connection with other peers as they will use different keys. It is quite an awesome protocol.
It's nice but the fact that you can never delete a message in your feed means that it doesn't really work as a social media protocol. Some people see that as a feature since it is theoretically uncensorable, but that's not how humans like to interact.
I have been using patchwork[1] as my main social network client for scuttlebutt. In my current experience, the fact that messages are not removable makes me more careful when writing and has led to much better and more meaningful interactions on the network.
Also remember that a message being in the feed doesn't mean it is displayed. Scuttlebutt is quite flexible, there are clients that have support for "chess messages" so their users can play chess, patchwork doesn't support those messages so I don't even see them. There is git-ssb[2] which allows people to host and contribute to code directly inside the feed, not all clients show these messages but they are all there.
New messages could be added for flagging a message id as deleted and clients could honor them and not display that message anymore, they would still be on the feed, much like in version control systems we still have access to deleted files (if no one rewrites history).
I enjoy how permanent things are there because as a side-effect it causes people to care more about the ecosystem and culture as those are permanent stuff you're putting out there. Check out this essay "the future will be technical"[3] about the culture on scuttlebutt, you'll see it is quite different than other social networks, but I agree with you, your experience may vary and what I consider an advantage, others may see as a reason not to use.
I am not a lawyer either, but doing a quick read on the scope, I found in first phrase:
"The regulation applies if the data controller (an organization that collects data from EU residents) or processor (an organization that processes data on behalf of data controller e.g. cloud service providers) or the data subject (person) is based in the EU."
And this might not apply as there is no data controller, organization or company. You data is on your computer and it replicates that data to friends and friends of friends. There is no cloud or service involved, it is from one machine to the other, I believe someone that has real knowledge of legal matters and p2p should chime in. I am also a bit lost regarding this.
I contacted an e-chum who is a lawyer specialising in the field of IT, IP and media law [0]. He pointed me back to Article 17 of the Regulation, Right to erasure ('right to be forgotten'), which is contained in [1].
This states that:
"The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay ... where .. the data subject withdraws consent on which the processing is based..."
Paul also expressed the view that: "It’s certainly been written in a way that should require systems to be created to allow for the deletion of personal data, though!"
That intent is key here. Basically: if someone asks you to remove their data and you refuse (or fudge, etc.), then don't be surprised if the EU comes knocking.
Surely that means that the people who replicate it from your ("your friends" and "your friends of friends") would be required to delete the (personal) data?
Thank you very much for the contribution. The decentralized web projects sound really exciting and it's awesome to see support from Mozilla.
However, I find the concept of the scheme whitelist pretty strange in context of WebExtensions.
Of course it makes sense that http:, https:, data:, blob:, etc should be off-limits for extensions. But on the other hand, I'd think that the primary use-case of registering protocol handlers in extensions is to handle existing links - something that the ext+/web+ rule seems to be particularly designed to disallow.
Apparently, the actual handler whitelist for WebExtensions can be found at [1]. It looks pretty... arbitrary?
For example, it's amazing to see that magnet: irc:, ssh: and gopher: are on there, but then why not ftp:, ws: or even steam:? There could be some useful extensions intercepting those as well.
Likewise, while the inclusion of scuttlebutt, ipfs etc is very good news, what makes them eligible now that didn't make them earlier?
Generally, I'd like to know by what process is that whitelist managed and what are the criteria to get on there.
(I understand it's derived from the official HTML5 whitelist [2]. To be honest, that one looks even more arbitrary - but of course has different security considerations, as it defines an API for the open web. The two lists also seem to have some differences, as e.g. gopher: isn't on the HTML5 whitelist while openpgp4fpr: is not on the extensions list.)
Is there a chance we could get MAFF: (and MHT:) protocols as well and let our web-extension handle those (single-file archived web pages if anyone wondered)?
This would allow us to (again) associate the Firefox browser with for example .maf files and have them displayed in the browser via the extension. (I'm sure there must be thousands of archived pages out there that currently are a hassle to view - it would be great to get support for those).
Please excuse the inappropriate question, but this one has been bugging me for many years: will there ever be some kind of session manager on Firefox Mobile that can save and recall your browsing session (a group of tabs) to/from a local file, similar to how OneTab or MySessions are working?
Yeah this is pretty great. AFAIK it's limited to only redirecting to a handler website, but that's a big step forward for using these protocols in links and etc.
Maybe I'm reading this wrong, but it sounds like they've made it so you can develop a webextension that handles DAT:// or IPFS:// URLs. They didn't make IPFS:// URLs redirect to http://ipfs.io/ipfs/$hash.
Sort of. I think this is based on the `registerProtocolHandler()` means, and if so, you can redirect this to an internal page in your extension. See https://addons.mozilla.org/en-US/firefox/addon/overbitewx/ (disclaimer: authored by yours truly).
The more pressing concern is how you would speak these protocols because there's still no direct socket support. In my case, the addon just acts as a history and redirect shim and my server does the actual server access and translation. I'm actually thinking of cobbling together a native messaging-based extension as a stopgap since obviously this is suboptimal.
Hi, I did just like you said using Native Messaging API[1] to communicate with a local companion app using standard input/output shell calls, this app can handle the socket communication, that is how I am handling it for the scuttlebutt experiments I am doing (I mentioned them above with some URLs if you want to check), I hope to start a conversation soon on the add-ons list about the needs of having UDP and TCP available for WebExtensions. It is suboptimal but it works today...
They made that before that protocol was on the whitelist, now they could ship a native app that has a webextension bundled with it to handle all of it without using that redirect.
You can make your own but it will need a prefix like "web+catgifs:" or "ext+catgifs:" depending on how the custom url is handled (redirect vs webextension), to be able to use custom urls without the prefix, you need to be on the whitelist. Thats why that little patch is cool, it enables us to build add-ons without requiring a prefix for the custom procotols used by popular dex stuff.
I think the whitelist on what you can register as protocol handlers is a security measure. E.g. if Paypal uses "paypal:" links which are handled by a OS native application, you can't write a extension that hijacks those links.
So how do I make an extension that supports Firefox 57 or later and does mycustomprotocol:// without prefix? Do I have to Rowhammer my access through Firefox' code? I do not see how it is in Mozilla's right to restrict what a user can do with the user's browser.
The hell does the prefix have to do with user rights? This is a matter of convenience, not capability.
You want arbitrary protocols? The prefix is available to you. You want blessed protocols? The non-prefix is available to you.
There's no restriction in place. And anyways, given OSS, you can bless your protocol with a custom build. But just because you want it blessed doesn't mean it should be forced onto everyone else.
I follow Stallman’s school of thought that software should never restrict the user in ability.
A user should not be protected from themselves, if a user wants to install an addon to intercept paypal:// requests for whatever reason, that should be their choice. And it should not require the user to do custom changes to the system.
You have the source code and can create a build that works like that. The current way it works, which is with a whitelist, makes it a lot harder for some malware to exist and hijack a protocol and this is, in my opinion, a good thing.
Remember that Firefox is used by millions, and a whitelist is a measure that adds a bit more safety to the millions out there that are not as tech-savvy as you and still want to browse the web.
For somebody who blindly follows Stallman's school of thought no matter what the consequences, I find it odd that your password isn't the same as your login name.
>But gradually things got worse and worse, it's just the nature of the way the system had been constructed forced people to demand more and more security. Until eventually I was forced to stop using the machine, because I refused to have a password that was secret. Ever since passwords first appeared at the MIT-AI lab I had come to the conclusion that to stand up for my belief, to follow my belief that there should be no passwords, I should always make sure to have a password that is as obvious as possible and I should tell everyone what it is. Because I don't believe that it's really desirable to have security on a computer, I shouldn't be willing to help uphold the security regime. On the systems that permit it I use the “empty password”, and on systems where that isn't allowed, or where that means you can't log in at all from other places, things like that, I use my login name as my password. It's about as obvious as you can get. And when people point out that this way people might be able to log in as me, i say “yes that's the idea, somebody might have a need to get some data from this machine. I want to make sure that they aren't screwed by security”.
Back then Stallman worked in a secure space with trusted people where physical locks were between him and people wanting to just wreak havoc. Not using a password was a measure of not restricting good willing people.
Blindly askilg people to apply that to todays computers chickens out from the need to distinguish between very different situations.
Your message is not just an ad-hominem ("blindly"), but also a try to play someone for an idiot.
Actually, it wasn't quite as secure a physical or virtual space as you imagine.
It was quite easy for anyone to get into the 9th Floor at 545 Tech Square simply by thumping on the door in the elevator lobby, because anyone on a Lisp Machine within earshot would just press Terminal-D to buzz open the door without getting up from their chair [1]. (And they could summon an elevator by pressing Terminal-E.) And many students and non-laboratory people (referred to as "random turists") knew the series of digits to tell a locksmith to make a key to those locks, or somebody who could make them a master key in the robot machine shop. And even if you didn't have your own key, there was always the MIT Lockpicking Guide. [2]
The physical locks on those doors certainly never stopped me from showing up unannounced, gaining physical access, and wrecking havoc by playing around with the Lisp Machines [3] and PDP-10's [4], spying on other people's sessions with the Knight TVs, printing out and Velobinding reams of documents on the Dover laser printer, and sleeping on the beanbag chair in the "Lounge Lizard Lispmacho" office.
And then there was this thing called the ARPANET that you could use to log in without even knocking on any doors, picking any locks, or being physically present in Cambridge Massachusetts. Breaking into the ARPANET wasn't as difficult as depicted in The Americans "ARPANET" episode [5] (S02E07) where the KGB agents had to actually break into campus and murder somebody to gain access.
The dial-up TIPs themselves actually had no passwords, and BBN would mail you a free copy of the "Users Guide to the Terminal IMP" [6] if you asked nicely -- including "APPENDIX A: HOST ADDRESSES". Then all you had to know was a phone number (301 948 3850 for example) and what to type (E, @O 134, :LOGIN RMS, RMS), and you were in.
You didn't even have to know RMS's password. If you tried to log in to MIT-AI with an unknown user name, it would ask you if you wanted to apply for an account, what your name is, and why you wanted to use the system, etc. If you answered sensibly (like "learning LISP"), you'd have your very own free off-hours "tourist" account [7] within days.
The basic acquisition of every lock hacker was a master key. The proper master key would unlock the doors of a building, or a floor of a building. Even better than a master key was a grand-master key, sort of a master master-key; one of those babies could open perhaps two thirds of the doors on campus. Just like phone hacking, lock hacking required persistence and patience. So the hackers would go on late-night excursions, unscrewing and removing locks on doors. Then they would carefully dismantle the locks. Most locks could be opened by several different key combinations; so the hackers would take apart several locks in the same hallway to ascertain which combination they accepted in common. Then they would go about trying to make a key shaped in that particular combination.
It might be that the master key had to be made from special "blanks" unavailable to the general public. (This is often the case with high-security master keys, such as those used in defense work). This did not stop the hackers, because several of them had taken correspondence courses to qualify for locksmith certification; they were officially allowed to buy those restricted blank keys. Some keys were so high-security that even licensed locksmiths could not buy blanks for them; to duplicate those, the hackers would make midnight calls to the machine shop a corner work space on the ninth floor where a skilled metal craftsman named Bill Bennett worked by day on such material as robot arms. Working from scratch, several hackers made their own blanks in the machine shop.
The master key was more than a means to an end; it was a symbol of the hacker love of free access. At one point, the TMRC hackers even considered sending an MIT master key to every incoming freshman as a recruitment enticement. The master key was a magic sword to wave away evil. Evil, of course, was a locked door. Even if no tools were behind locked doors, the locks symbolized the power of bureaucracy, a power that would eventually be used to prevent full implementation of the Hacker Ethic. Bureaucracies were always threatened by people who wanted to know how things worked. Bureaucrats knew their survival depended on keeping people in ignorance, by using artificial means like locks to keep people under control. So when an administrator upped the ante in this war by installing a new lock, or purchasing a Class Two safe (government-certified for classified material), the hackers would immediately work to crack the lock, open the safe. In the latter case, they went to a super-ultra-techno surplus yard in Taunt-on, found a similar Class Two safe, took it back to the ninth floor, and opened it up with acetylene torches to find out how the locks and tumblers worked.
With all this lock hacking, the AI lab was an administrator's nightmare. Russ Noftsker knew; he was the administrator. He had arrived at Tech Square in 1965 with an engineering degree from the University of Mexico, an interest in artificial intelligence, and a friend who worked at Project MAC. He met Minsky, whose prime grad student-administrator, Dan Edwards, had just left the lab. Minsky, notoriously uninterested in administration, needed someone to handle the paperwork of the AI lab, which was eventually to split from Project MAC into a separate entity with its own government funding. So Marvin hired Noftsker, who in turn officially hired Greenblatt, Nelson, and Gosper as full-time hackers. Somehow, Noftsker had to keep this electronic circus in line with the values and policy of the Institute.
[...]
They went wherever they wanted, entering offices by traveling in the crawl space created by the low-hanging artificial ceiling, removing a ceiling tile, and dropping into their destinations commandos with pencil-pals in their shirt pockets. One hacker hurt his back one night when the ceiling collapsed and he fell into Minsky's office. But more often, the only evidence Noftsker would find was the occasional footprint on his wall. And, of course, sometimes he would enter his locked office and discover a hacker dozing on the sofa.
Regardless of what RMS thinks, users should be protected from code downloaded from the Internet. There have been too many problems with malicious extensions not to do this.
Restricting what users can do for their own "safety" is what gives us walled gardens such as iOS.
I use Firefox precisely because I can (or, rather, could) override basically all browser functionality with addons, without having to set up a custom build server and apt repo myself.
Where by "safety" you mean "the most secure mainstream computing platform currently available, setting a standard to which other platforms approach only asymptotically and with significant end-user effort".
Obviously, I can't end decide this debate, such as it is, in a single comment (or, likely at all, with an acolyte!). But someone should get the message into the tech message board bubble that in the modern software security world, the controversial argument to make would be that iOS isn't the most secure OS out-of-the-box.
The safest computing platform is an airgapped 386, that doesn’t make it useful.
In the same way, iOS may be safe, but entirely useless for many people’s use cases.
And additional, safety is entirely orthogonal to restricting choice. You can have a walled garden that is insecure, e.g. the Amazon Kindles, or you can have an open system that is secure, e.g. OpenBSD.
Power users can hack and compile their own build. But you just want to complain on the internet.
So I don't see why the rest of us should have to endure your specific, less secure world view on software.
For example, your pitch certainly doesn't entice me yet you act like its necessity is self-evident. Maybe it's just time for you to find a browser that suits you instead of replying to every post that disagrees with you.
The protocol handler support is restricted to a whitelist to prevent an addon from taking over, say, "http://" (or other protocols which could be used to insinuate unsafe content).
It still seems safe though to set up rules where domain ownership could automatically grant ownership for a protocol. E.g. Facebook.com:// or just Facebook:// if .coms were allowed to be dropped.
When you navigate to a custom protocol URL there is a popup asking how to handle it, it will show all the add-ons in a list (and maybe native apps too). You can select you're chosen one and tell it "not to ask again".
Happy to see that Mozilla was serious about their intentions to extend the WebExtensions API in post-57 Firefox. I'm also happily surprised at the section about user notification of extension overrides; having a nice UI for this sort of thing is a difficult yet worthwhile problem (and I'm also a big fan of the new Preferences tab in general, it works far better than the old popup window). Hopefully some of this will make it in time for the next ESR so that people who are still on Firefox 52 ESR due to unsupported extensions will have the option to upgrade (though I don't see anything that will satisfy the vimperator users, I'm encouraged by the new mouse gesture APIs). Kudos to Mozilla for conducting this process with an eye towards keeping the security threat of addons reasonably manageable, even if the overall process is slower than we'd otherwise like.
I discovered tridactyl (https://addons.mozilla.org/en-US/firefox/addon/tridactyl-vim...) a couple months ago. While it doesn't have total parity with vimperator, it's much closer than vimium and vimFX, and unlike for those projects, parity seems to be the actual goal.
YMMV, but as someone who was stuck on ESR for a long time for this reason I am now completely satisfied on 57.
It's decent, but there are some major shortcomings caused by the WebExtensions API. For example if you somehow get caught in address bar, you can only leave it by pressing Enter or reaching for the mouse and clicking somewhere else. Another inconvenient feature is the time it takes for the extension to be loaded. On bloated and slow pages, I have to wait for a second or two while pressing the shortcuts to switch to another tab or anything. Basically the whole extension-driven keyboard UI locks up waiting for the page to finally load. And this is not because these extensions are slow, but because they get initialized only some time after the webpage has already begun loading.
I find that :reloadall helps my sanity a lot if I'm navigating through lots of already open tabs, and I've just about got used to using <C-Tab> rather than gT.
We're trying to extend web-extensions to get around the limitations [1], but progress is slow.
It's funny that vimperator is mentioned every single time Firefox extensions are brought up on HN even though it only has about 11,000 users out of the hundreds of millions that use Firefox.
Well, 1) it's a legitimate use-case and 2) certainly the amount of Vimperator / Pentadactyl / Vimium etc users are a much higher percentage of HN users than among the population at large.
I used to be one of the users, but after the millionth time that an upgrade broke the extension I gave up on being able to use it.
I don't think about it often but even though I am mostly over it I get a little sad thinking about it. But only a little.
I've also stopped using tiling window managers.
Most of my time is spent either reading in the browser, writing code or typing in the terminal. I have sufficiently few windows most of the time that alt + tab does the job just fine. I prefer tabbing between windows now because it gives me bigger windows and more flexibility.
I think the scroll wheel is better for web browsing than hjkl.
But my code I will still often edit with Vim, though I sometimes use an IDE also.
For me, macros alone are worth installing Vimperator. Just record a series of steps once, then you can effortlessly play them back how many times you want. I just used it today to skip 20 pages in a dumb interface that only offers previous/next links.
I think its largely a showcase of an ideal: it changes the entirety of the interaction model, and this is ideally what the extension system should be capable of, even if relatively few people want such a significant change.
And, ideally, we should see extensions upturning the interaction model as users experiment with alternatives; that this is no longer possible, that the fundamental model is defined and hardcoded (with minor flavour differences), is, I think, a significant loss.
Its a shame there are few extensions like vimperator; its a greater shame there are none.
I've tried alternatives like Waterfox and Pale Moon, but Waterfox is incompatible with some sites, and Pale Moon is dog slow, so I reverted back to Firefox 56.
Not upgrading a browser is a scary situation to be in, but I just can't sacrifice the usability of Vimperator.
I'm posting this comment using FF 56 also. I don't agree with the decisions they made. I think that the old extension mechanism is fine; add-ons should be able to integrate deeply into browser internals.
> I've tried alternatives like Waterfox and Pale Moon, but Waterfox is incompatible with some sites
Oh, I haven't experienced that in a few months of usage. What kind of incompatibilities did you come across?
I was initially reluctant about trying Waterfox and made several backups of my then-Firefox profile, but it's been a smooth sail and an easy switch so far.
In Waterfox, Slack shows a message that it doesn't support the browser and refuses to load. This could possibly be bypassed by changing the UA, but I don't agree with that workaround. Although, if hard pressed, I might have to.
And I mistakenly wrote Pale Moon above, when I meant IceCat. I've yet to try Pale Moon, but it's on my list.
> though I don't see anything that will satisfy the vimperator users, I'm encouraged by the new mouse gesture APIs
Yep, me too. I switched to Waterfox for the time being because of how important FireGestures is to me. If full-fledged mouse gestures extensions become available in Fx again, that would be a big step towards making the new Firefox usable for me.
Since you mentioned vimperator, another major issue for me is the lack of a VimFx style extension - that one is much simpler than vimperator or pentadactyl, and has other new attempts at alternatives, but 'Saka keys' is the one that seems to come closest (and makes this less of an issue than the mouse gestures one) and that's still kinda buggy and years behind VimFx in terms of features.
I would have missed Tab groups though it's not that big of a deal to me, but I'm glad we'd have that feature again. And another minor issue in that league is the lack of a good Speed Dial extension with a decent UI and set of features (which none of the "replacements" had last time I tried them out).
I have a tangential question for anyone who might know more about tab stuff than me.
Awhile ago, I looked into making Firefox not do any tab management. Basically, always have one tab per window, middle click always opens a new window, normal click always opens a page in the current tab. (I'd like to do tab management with my window manager instead of browser so I can have a consistent tabbing interface across all of my applications.)
The few results I found googling around seemed to be mostly along the lines of "change these 14 prefs in about:preferences, install this addon to stop target:_blank, add these userstyles to hide the tabbar, don't open any internal FF pages, and check back with every new browser version".
Am I missing something that would make this easier, or is this really a thing that's just not really feasible? I can certainly understand that it's not a priority since almost no one needs to disable tabbing, but it also doesn't seem like that farfetched of a use case, nor would I imagine it would require much work to support.
(Not OP but...) A long time ago, I used Fluxbox which had a neat arbitrary window tabbing feature. Middle-mouse dragging one window title bar on to another created a tabbed window. There were keybinds for rotating through tabs vs windows.
I found it novel but with most WMs, I found myself basically doing a very small number of fullscreen windows per workspace. This led me to my current Sway/i3 setup which seems to be working pretty well. Downside is gkrellm, which used to live in the dock (OpenBox), doesn't really fit in the new world order.
It's almost certainly not what OP is using, but if you're interested in tabbing of arbitrary windows as a built-in OS feature, I'd suggest you have a look at how BeOS used to do that. You can still try it with Haiku[1].
I'm also fairly certain that functionality could be implemented with a handful of scripts in awesome (in a floating way instead of using pre-existing tiling WM features).
> Many tiling windows managers like i3 and XMonad have a tabbed layout
I'm aware of that - I use Sway on my linux machines, which ported that over from i3. But thanks for pointing it out, anyway :)
What I didn't know is that openbox and fluxbox can do this too, as oblio notes (but that's more out of disinterest for those two - maybe I should have a closer look).
I mainly pointed at awesome because I find it to be - well - awesome for being so flexible. You can do almost anything if you want to bend it for your specific workflows - be that in a tiling or floating layout.
For example: I still have a couple of scripts lying around that introduce the workspace behavior of the Gnome 3 shell in an awesome desktop.
BeOS did surprisingly little with its tab titlebars. It couldn't even automatically stack them. If you wanted to use them as actual tabs you had to hold down shift and manually move each individual tab to the right spot along the top of the window, and then manually move the windows on top of each other to sorta simulate pages being stacked. No sort of "drag these windows together and we'll turn them into tabbed pages" functionality which would have been convenient.
I find BeOS mainly curious because it experimented with strange features on each level (e.g. said tabs, BeFS/Tagging, etc). I think every one of those features should (and probably would) have gotten an overhaul by now if Be Inc. was still around.
That said, I haven't looked much at their APIs. If the tabbing behaviour is exposed properly, I can imagine it would be quite easy to write a small utility that stays in the tray and does that automatic tabbing separately.
Off topic, but for anyone curious what that image is without clicking: it's a hairy testicle in an egg cup. The title reads "Hacker News" and the caption is "A DDoS made of finance-obsessed man-children and brogrammers".
The form is debatable, however their critique is not completely wrong. The diagnosis that at least a vocal part of the crowd here is finance-obsessed fits my experience.
More generally, some of the people I regularly interact with face-to-face are strongly focused on how they can use things for their financial advantage, while others aren't. Some even want to speculate with cryptocurrencies, which I consider gambling. I don't yet understand what explains the difference. Maybe a fear of running out of money to meet existential needs?
Anybody any ideas what makes seemingly very intelligent people so obsessed with money?
Money is the metric some (I'd say most if not all) very competitive people choose to compare themselves to others. After school it's pretty much the only objective metric.
As tech has very high salaries even for entry-level positions those people tend to come to tech and then find their way to Hacker News.
To get around this you can disable the inclusion of the referrer. In firefox set `Network.http.sendRefererHeader` to `0` in about:config. Of course this only lets you avoid it. But, yeah, I agree. That's pretty rotten behavior and worth avoiding linking there.
I remember see this once before from his blog. Why is he such a dick to HN? Does he have a post about it? (and I guess archive.is link it to avoid the egg testicle).
The default referrer policy is "no-referrer-when-downgrade", so it won't send a Referer header to a "less" secure destination (HTTPS -> HTTP), but it will send one to an "equally" secure destination (HTTPS -> HTTPS).
Websites can override this though. For example, HN could send a "no-referrer" directive to prevent any Referer header being sent.
I went all in with 57 (the first 'Quantum' release) after having been a Chrome user for quite a while. I really haven't missed Chrome at all since I made the move, and in fact, am continually impressed by the little things in Firefox that I keep discovering. Not to mention the speed.
These changes look like they will eventually make things better, especially for extension developers and those of us who get to reap their benefits.
> ... one of the most requested features has been the ability to hide tabs with the WebExtensions API. It was a key element of some very popular legacy add-ons ...
It's weird that they are not mentioning Tree Style Tabs by name. But, at least they're listening the the user requests.
I don't use the plugin myself, but I heard that one of the gripes of the new WebExtensions version is that it still shows the normal horizontal tabs.
They are referring to hiding individual tabs, not hiding the horizontal tab bar.
The legacy extension they are referring to is Tab Groups [0]. It allowed you to separate the tabs of a single session into groups. Selecting the active group would hide the other tabs.
Still, it seems that the current API couldn't really support that use-case if tabs with active audio or video can't be hidden. At least there will be some random tabs hanging around that don't belong to your group.
But the main use-case for this API seems to be organizing things - and it's strange that I would want certain tabs not take part in my organisation scheme.
If I had virtual desktop support, but certain windows are nevertheless shown on all desktops, that would feel broken, too.
Of course notifying users of audio/video recording is important, but this could be done with a separate notification - with options to stop recording or activate and un-hide the tab.
I don't know if this is the case, but the API ought to also let you kill any active video or audio streams playing in a tab. Then you'd be able to go ahead with hiding them.
If this is not possible or planned, it feels kind of broken in my view.
Seems reasonable to not mention a specific one by name so as not to play favorites going forward if someone else wants to make a competitor. Or maybe a Grid Style Tabs, or who knows what.
I imagine it's the same tone they use for discussion of adblocker related features, "we need this for content blocking addons" rather than "we need this to support uBlock Origin."
Hiding the top tabs can be done in current versions but you have to go digging through settings folders and set up a css file with some rules. There's also a built-in header on the sidebar than can be hidden by similar means. Hopefully they'll also let us hide that header (it lets you switch to other sidebar views like Bookmarks and History that I don't want to use in the sidebar) so I can avoid the css setup in the future.
FWIW, I have this in my userChrome.css to fix that horizontal tabs annoyance: `#TabsToolbar{ visibility: collapse !important;}`. Not ideal, but a workaround I can forget about most of the time.
Anyone working on this reading the thread? Can we ever expect an extension that will allow the far better tab management that Chrome has? Namely: Being able to scroll between tabs with the scroll wheel, and being able to select multiple tabs with shift/ctrl to drag them/merge them/close them/etc.
It's crazy to me that Firefox's original selling point was tab management, and today Chrome's is so much better.
Wheel scrolling for tabs has always worked for me in Firefox on Windows, and still does. Arguably FF handles this better because the tabs don't become 8 pixels wide once you have a bunch of them open.
Is this broken on a specific OS or under a specific window manager maybe? It might be worthwhile to file a bug, since it definitely should work.
How I wish there was a session manager for 57+. The Session Manager plugin was great but I'm not aware of any alternatives and Firefox doesn't seem to support a library of multiple past sessions to pick from.
Session Manager was one of the best extensions I relied on before Firefox 57. Since that project was discontinued due to deficiencies in WebExtensions APIs, I'd stopped updating Firefox on some machines (I also like Tab Mix Plus, which isn't yet released for Firefox 57+). On others, I recently installed Tab Session Manager. [1] It's not supposed to be a drop-in replacement for Session Manager, and I'm yet to use it well, but it does have basic session saving/restoring features.
As a technical user who values choice and customisability, I am totally fine with their choice of disabling tab hiding until you flip a bit in the configs. It's the best of both worlds: customisability for power users and security for regular folks.
Or it would be if it stayed this way. It was this way for a while with extensions. You could install extensions you wanted freely. Then there was a config bit to make it so you could install extensions without Mozilla approval. Then they decided grandma was more important and completely removed the ability to install extensions not approved by Mozilla.
The only way around it is to run a beta version or use the unpackaged unbranded versions manually.
I wouldn't count on power user features remaining for long given Mozilla's current target demographic.
The config bit for allowing unsigned extensions was temporary from the start. They did not later redecide that they wanted to remove it, they knew from the beginning that it did not offer the security that they wanted to achieve.
Because any extension or sufficiently capable malware on your system can change about:config values, meaning that if Mozilla ever makes a mistake in the extension approval process and lets a malicious extension slip through, or you get such malware on your PC, then that extension/malware would be able to flip that config bit and open the flood gates for all malicious extensions. Mozilla would also not be able to change that config bit back in any trivial way, if they notice that they let a malicious extension through.
Only moving that configuration to the compilation step is able to prevent this for sure and most definitely is the sensible choice not just for Granny, but for most tech-savvy users as well, as even only a fraction of those care about unsigned extensions.
Months of public discussions have been held on if this can be done in a more (power-)user-friendly way without comprising security for the vast majority of users, who really do not care for unsigned extensions either.
Yes, these discussions would have concluded differently, if those 0.1% users who actually care about unsigned extensions made up 80% of Firefox users, but acting like this decision with a motivation that goes well beyond just wanting to not do as much maintenance is somehow indicative of how much Mozilla cares for its power users, is just ridiculous.
And just look at the malware fest that is the Chrome Store. This is what Mozilla was able to prevent by requiring extensions to be signed.
Lastly, specifically because they now have a functioning way of controlling malware, they can actually be a bit more liberal in what they allow to be configured via about:config and there is now no real use case anymore where it would make sense to move an about:config value to a compile flag.
> Because any extension or sufficiently capable malware on your system can change about:config values, meaning that if Mozilla ever makes a mistake in the extension approval process and lets a malicious extension slip through, or you get such malware on your PC, then that extension/malware would be able to flip that config bit and open the flood gates for all malicious extensions.
If such a malicious extension or other malware got installed, it could already do anything another malicious unsigned extension could, so I don't see how having this setting weakens security under the assumption that there's already malicious code running.
If we assume a system is compromised, it may as well install other malware as normal binaries instead of a Firefox extension.
Just flipping the about:config bit alone doesn't help much though. Any malicious extension installed after changing the setting would still have to have some payload with similar malicious behavior.
Moreover, even if Firefox was compiled without support for that setting, malware could patch the Firefox binary (or download and install a malicious version) to disable the check and then it'd still be able to hide itself as a Firefox extension instead of a binary somewhere else on the system. Once there's malicious code running on the system, it's game over and a flag disabling installing more malware using one out of many possible methods is not going to help much.
However, not having the setting may help for users that get tricked into toggling it through some web page telling them to and then installing a malicious extension, but that's a different scenario than an already compromised system.
I wouldn't know about Chrome. But I do know I've never had a problem with malware extensions. And I know I edit mine. So I know Firefox is no longer the browser to use.
I get that Mozilla's response is, "Don't let the door hit you." But it can't pretend to still be for power users.
> pageActions can now be shown and/or hidden automatically for specific pages via pattern matching using the “hide_matches” and “show_matches” manifest properties. This is a nice performance win for users.
When writing an extension that shows a page action only for certain domains/URLs, this allows to replace about 15 lines of javascript code with a single line in manifest.json. Nice!
Mozilla should fix no exit confirmation for Ctrl+Q. It's just too easy to close the browser this way, and extensions that offered this feature aren't working anymore.
It's really a problem in general, there is no way to make an extension that customizes browser behavior itself (rather than page behavior), since WebExtensions can't do that.
I thought the gaining philosophy here was to make "destructive" operations easy to undo, rather than having warnings and confirmations before carrying them out?
Quitting Firefox and then starting again and restoring all tabs fits well with easy to undo.
Forget confirmation, Ctrl-Q shouldn't exist in the first place. An keystroke that can close your whole session and is near-identical to another, very common keystroke is a design flaw, period.
Same with the backspace key activating the back button. Using these keystrokes for these purposes should be considered harmful.
Ctrl-Q is so harmful that I've long fantasized about hacking whatever driver in the kernel that controls the keyboard and having it ignore whatever signal the keyboard sends out whenever you press Ctrl-Q and not even pass it on to userspace.
On OSX I have a tiny applescript running inside Butler[1] that's active when firefox is foregrounded, and just intercepts Ctrl-Q and runs:
tell application "Firefox"
set buttonStr to "Ooops"
set errMsg to "Close with ?-Q disabled. Use the menu."
display dialog errMsg buttons {buttonStr} cancel button buttonStr default button buttonStr with icon stop giving up after 5
end tell
I'd imagine similar options exist for other OSes. AutoHotkey for windows, maybe? Not sure what linux/x has by way of systemwide handlers that can both intercept and cancel propagation of offending bindings, though.
I don't see how it can undo everything, if you'll lose data in the process. Not every open page is static and some can have user input and what not. Exiting the browser will wipe it all out, and restarting it isn't going to help.
So confirmation for Ctrl+Q is a must, there is no question about it. And if you don't want it - they can make an option that can turn it off.
"if you'll lose data in the process. Not every open page is static and some can have user input and what not. Exiting the browser will wipe it all out, and restarting it isn't going to help."
Not only that, but it can take a significant amount of time to restart the browser and reload the tabs you had open.
So just in terms of time wasted, accidentally quitting the browser and having to restart it is awful and painful compared to just canceling the quit.
Something that drives me nuts is how stateful about:config options are. If you set them once, either through about:config or using a user.js, they will stay like that forever unless you explicitly unset them.
Oh no, persistency is great. But the problem is how non-functional their implementation is.
Say I write a user.js file with a few options. I can't have the typical dotfile model, where removing options from this file will lead to defaults on the next run. I need to unset them. Explicitly.
Thus, using a dot file to set up Firefox (user.js) is incredibly clunky and people don't use this much.
I agree that in most cases an easy undo is much better than confirmations, but in this case is just such a huge pain in the ass to restart all your tabs that the confirmation is a better solution.
It's not binary. Both solutions can coexist as long as we choose the right tool for the job.
Unfortunately, restoring state after quitting on MacOS is not trivial. Specifically, restoring all your windows to the right spaces. No browser on MacOS (not even Safari) manages to do this...
+1. We already have multiple ways to close Firefox window from keyboard: Alt-F4, Alt-Space, and by mouse and menus. Why we need yet another keyboard shortcut for that functionality? Is it so important?
Was hoping to see Web SQL make its way back into Firefox.
Yes, it's been deprecated for years, but that hasn't stopped the browser makers with majority of market share (Google > Chrome, Apple > Safari) from continuing to ship it along with the strictly worse alternative (IndexedDb).
Now that pretty much every language compiles to Javascript it's a shame to lose SQL functionality on the client. Shared model, shared validation, shared SQL layer, etc. -- it could all be a unified whole, but no, now one has to wait for sqlite-lite to be built on top of IndexedDb; that or throw everything out and go NoSQL on client and server.
Thanks for the link, I've been hunting around everywhere looking for a cross platform solution.
In a sibling comment I mentioned the fact that most languages compile to Javascript, the primary benefit being able to share code across client and server. So, if you've got a query DSL on the server that hooks into an SQL database you can use the same code on the client, hooking into an SQL database on the frontend.
All of the IndexedDb wrappers I've seen do essentially their own thing; in Lovefield's case, "The difference is that Lovefield does not accept raw SQL statements; instead, it has a builder-pattern API to build queries", which means it's effectively a client-side only solution if pure SQL is the output target of your query DSL.
The problem with Web SQL was that the spec was effectively just "whatever SQLite does". That isn't good enough for the Web. Imagine if the GIF specification had been "whatever GIFLIB does". Libraries like Lovefield can be built way faster than specifications can be written.
> Libraries like Lovefield can be built way faster than specifications can be written.
That may be true, but when said library uses a builder pattern rather than sql statements you can throw out all of your server-side query DSL code and waste time reimplementing everything on the client.
Since SQL has been around for several decades it's not surprising that mature server-side SQL libraries are available in abundance. And these days every language under the sun compiles to javascript -- wouldn't it be great to share the same query DSL code on client and server?
The answer is, emphatically, yes! Current state of affairs makes this virtually impossible to do in a widely supported manner.
I don't know, is my choice of SQL engine (sqlite) via WASM a realistic solution? How does one compile sqlite to WASM, and how is this made available to the end user?
sql.js[1] is a pure JS implementation of sqlite and it weighs a ton (2.6MB) compared to browser supplied native sqlite. Ideally the user doesn't have to pay the price of downloading a large binary (on top of already large SPA).
Sure, but that's the JS version. wasm is meant to produce smaller, less resource-intensive versions (and there is a wasm version of sqlite I believe [1]). I'd much rather see CDN and caching tech improve along with other low-level tools such as wasm and CSS Houdini to let us build whatever we'd like. I can see that being better for devs than waiting for vendors to standardize a watered-down spec for each feature we might want like SQL (and there's a lot of them).
Sure, same with Haskell's Esqueleto, Scala's Slick and Quill, F#'s LINQ, etc., these would all be wonderful to run in the browser, but that's not the reality, nothing is ready yet.
Mentat, for example, is built on sqlite, and in order to use it you have to run an Electron app. If there was a native version of sqlite (or other sqlite-like database) then there would be no such restriction.
It seems the best bet all of the above projects have for a friction-free implementation is WASM. When that's widely supported then one can ship whatever one wants (e.g. WASM sqlite) with their client-side application. Then, finally, it will be possible to use the same query DSL on client and server.
To perform efficient storage and querying of client-side data. I'm having a hard time understanding why one wouldn't want SQL in the browser given the alternatives.
> You cannot sync it to any SQL backend.
Sure you can, most client-side frameworks these days (React, Angular, ...) keep track of application state. On state change push to client and/or server database via REST API depending on network connectivity.
Totally different API, Sqlite is SQL based while IndexedDb is a key/value store with indexing and transaction capabilities (essentially the bare minimum on which a relational database could be built, the irony).
If your model is highly relational then it doesn't matter that querying for one entity is fast when what you really need is to, for example, efficiently join together multiple entities, grouping on N columns to produce some aggregate result. This is completely straightforward in SQL, but a convoluted inefficient, error prone mess in the alternative.
> IndexedDb is a key/value store with indexing and transaction capabilities (essentially the bare minimum on which a relational database could be built, the irony).
It's not ironic at all, it's just a good application of the extensible web manifesto : the browser support minimum necessary building blocs and then libraires can enhance the developer experience.
No, the old Tab Groups extension does something different. It allows you to switch between different groups like you can switch between virtual desktops.
You can't assign an already open tab as that would require cookie merging in a lot of cases, but there is a related solution. It took me a few weeks to realize what it was (but once I did, it all clicked, and works well now).
You select a container to open a new tab, then open what you want in it (type/paste link).
After you are on that URL in a container, the container control panel has an option to always open that domain (path too?) in that container. Check that.
Next time you paste a URL/link or follow a link to that domain, there will be an interim page asking you whether you want to open in the container the link came from, or the one you specified you always want it to open in. You can check a box to make that the default from then on.
Before I realized this is how it works, I was looking for a way to submit something like this as a feature request. After I realized it, the number of containers I used exploded, since I just default domains to always open in their containers and it's fairly transparent now.
As a real world example, I have a "Reddit" container, and a "Google - Personal" container (and a "Google - Work" for work G Suite stuff). I don't have Google default to anything (but I have some containerized pinned gmail tabs), but I do have youtube default to "Google - Personal". I have reddit default to "Reddit". I can view /r/videos and stream embedded and the views and tracking is in Reddit's container, but if I click to follow a youtube video to youtibe.com, it loads in the "Google - Personal" container and I can like or subscribe as I want.
At this point I have containers for banking, shopping, github+stackoverflow, facebook (I don't use it much at all, but at least this allows me to be logged in and worry less about tracking), Pandora, Reddit, Work/Home google, News (for a recent WaPo subscription), and I'm probably going to add a few more (including HN) within the next few weeks.
I really appreciate your taking the stime to spell this out in such detail. I deal with an insane number of open tabs (70-100 most of the time) and multiple discrete social media identities so this could be a huge productivity boost now that I understand it better. Thanks!
No problem! I actually spent some time trying to get the right type of access to submit a feature request for the containers addon for this issue (with problems exacerbated by teeing to use containers the hard way while using that access) until in double checking that I wasn't submitting a duplicate request I ran across the features I outlined previously on accident, so I know from experience the frustration of thinking is almost what you need and it would take so little extra work to finish it.
Luckily, the devs seem to have worked out a pretty good system, there's just a disconnect between what it can do and what's obvious on first usage, which is a problem that should only get better as time goes on.
I'll probably be updating it in 59 to use this new API though. It almost completely removes the need for a settings page and should allow you to set all the complex proxy config you want using the firefox UI. It does seem to need a broader permission than I would have liked though.
Not really related to extensions, but one thing I've been curious of for a while now: Does the Firefox team have any plans to implement something like Chrome's expensive background timers throttling feature?
There are still tons of APIs missing from WebExtensions that are required for many features of Tab Mix Plus. For instance, there is no way to get click events of any kind on tabs, so things like "reload tab on double-click" are not possible. You also can't control things like whether a new "window" opens in a tab or an actual window (to implement TMP's "open popups in tabs" feature), where tabs open (to have new tabs open next to the active one), what shows in their right-click context menus, etc.
So no, we're quite a long ways away from having a real Tab Mix Plus replacement. Having said that, I have faith that we will eventually get there, and hopefully be able to implement at least half of the functionality of TMP using WebExtensions within the next two years.
You probably don't want to keep using a version of Firefox that isn't going to get security updates... If keeping Tab Mix Plus is that important to you, try Waterfox[0] instead. It's a fork of Firefox 56 with security patches backported and a few small changes.
Personally, I've installed add-ons for the bits of functionality that are possible with WebExtensions, and otherwise learned to deal with it. The performance and stability improvements are worth it.
Tab Mix Plus is pretty much essential for me. I have over 900 tabs at the moment, and all other tab extensions I've tried have been very ordinary in comparison.
I recently tried to switch back to Firefox from Chrome because I was missing how Vimperator was able to hide all of the UI and just give me a small statusbar at the bottom like in Vim. However, I found that's no longer possible with WebExtensions, so now I'm wondering if anyone has any suggestions if I want a browser with absolutely minimal UI and Vim controls?
Seems like we're getting closer with this version though. I might just have to be patient.
Minor note, the mouse gesture config flag they speak about in this article, allowing mouse gestures to work on Linux and MacOS, was actually added in Firefox v58.
I hope FavTab will be able to work again. That is the one thing that has really messed up my usage of Firefox (I'm using AutoPinTab to pin everything as a replacement, but it causes flashing when it overlaps the favicon bookmarks I have to the right of the tabs and makes Ctrl-w not work).
Thank you! That text wasn't there when I looked. It is still too wide but at least much better than AutoPinTab and with a few adjustments I got something that behaves a little strangely but uses less space.
> To better support mouse gestures, browserSettings.contextMenuShowEvent() has been added in this version. This new API can be set to “mouseup” or “mousedown” by extensions to determine when context menus should be shown.
Looking forward to using FireGestures in Linux again.
Now if only they could come up with something that means I don't have to wait for a page to load before regaining control with custom hotkeys / gestures.
If you have an existing Chrome extension that relies on just the WebRequest API, how much effort is it to port to Firefox? Do things generally work without significant modifications? Are there lots of gotchas and small differences?
The only thing I’m missing in FF is the easiness of Google Translate, baked into Chrome. I know there are a few extensions, but it’s less smooth. Other than that, Chrome became bloated.
Found there were
About three words
laid out in the
Column so I flipped
My phone for a less
Arduous reading
Experience but there
Was just more padding
And I found the eye
Tracking experience
Exhausting so I stopped
reading.
Too bad the new model to not review and approve extensions made me stop installing and experimenting with them (except uBlock and a couple more). Same BS as Chrome but what can you do. My browser is very boring now.
its painful see most of the extensions don't work yet in latest firefox
keychain access manager
ublock and others
why do every Firefox version break extensions ?
Starting with Firefox 59, several protocols that support decentralized architectures are available for use by extensions. The white-listed protocols are:
+ Dat Project (dat://)
+ IPFS (dweb:// ipfs:// ipns://)
+ Secure Scuttlebutt (ssb://)