I think what really hurts, for me, is that this has become the general tone from Mozilla - whether the changes are ones I'd agree with or not.

I remember back when the Spread Firefox campaign was still around - at the time, Firefox and Mozilla in general felt grassroots, fun, and human. Like a club anyone could join and that anyone would want their friends, family, coworkers, and even strangers or people they didn't like to get in on: an all-in-this-together effort for a better internet.

Anymore, Mozilla feels more and more corporate, more like a company - even as Google Chrome (and the many browsers built from Chromium) eats away more and of their market share and they move toward being "the little guy" again - and less and less like a group of people.

I think what I really miss is having a browser that made me care about it beyond just wanting alternatives.

>I remember back when the Spread Firefox campaign was still around - at the time, Firefox and Mozilla in general felt grassroots, fun, and human.

That was long long time ago. I think something like early 00s when Firefox was just launched. Things changed. Mozilla is no longer the same.

While I agree with removing FTP support, I also agree that phrasing is pretty disgusting.

Especially because "The FTP protocol itself has been disabled by default since version 88", so any user that hadn't opted in to FTP protocol already had the "benefit" of the "security enhancement", no?

But, hey, if you are not yet a FF user, here's where you can download it, in case you're looking for a browser that... lacks FTP support. Something many users are likely to be seeking out.

To be fair, most non-technical users have no clue what FTP is. Twenty years ago, some non-technical people knew, because a lot of downloading was going on involving FTP servers, but that was... well, twenty years ago.

I do not see the benefit of removing FTP. For security concerns, a big warning as with expired TLS certificates would be an acceptable compromise, IMHO.

But as someone who knows what FTP is and still uses it on occasion, I don't think FF dropping FTP support is going to impact me very much.

I too agree with the comment I was replying to, "While I agree with removing FTP support", but the marketing-speak is still notable.

I don't think anyone who hasn't heard of FTP is seeking out a browser that specifically does not support it.

We'd be even more secure if they took away HTTP and HTTPS support

Way ahead of you: https://blog.mozilla.org/security/2015/04/30/deprecating-non...

With us all being secured from Gopher already, that’s all that remains to establish a 100% secure browser.

Mozilla have been working hard on that for years now. Haven't you been watching their market share? One day they'll get to their holy grail of 0 users and no security problems.

Describing ads ("sponsored tiles") as "user-enhancing" is arguably worse.

https://twitter.com/dherman76/status/433320156496789504

7 years, wow. Is that the oldest example of Mozilla selling out?

I am fine if Mozilla explains that FTP usage is now very low, based on telemetry and that there are FTP clients available for users.

However, there is no need to characterizes FTP being dangerous by jumping from FTP is old and is in plaintext, to FTP servers are being exploited and used to distribute malware, to FUD-type statement implying that there are [unspecified] exploits now available to attack Firefox if FTP was enabled.

This is just plain disgusting and it leaves a bad taste in my mouth.

I thought we should be familiar with this kind of corp speak from Firefox team. This is what they say every time they break or remove useful features in the pursuit of chromification.

This on the same line like " Our new CP and terrorism law is for your protection". I already feel much safer knowing that nobody can interfere with my downloads which will be supplied securely by Microsoft, Google and Cloudfare.

At this point Google is the sole source of Mozilla income, how do you know this line didnt come directly from them?

but why?

maintaining features is cost

Perhaps one day we can have a programming language that allows us to write software that doesn't rot or corrode.

We can start by writing software that doesn't have any features at all, and save ourselves the trouble of removing them later. /s

Here you go: https://github.com/kelseyhightower/nocode

As long as code connects to other code, it will need to be updated whenever the other code is updated.

Maintenance-free code is a chimera.

Maintenance-free code exists. I'm sorry you haven't experienced work at an org that has 10+ year old code which hasn't changed at all, easily verified by source control. (Has Mozilla published something anywhere about exactly how much work it is to keep FTP support around?) And while not technically 100% free, something closely related that's basically free is lots of 10+ year old code which does need to change sometimes but only as part of a batch of the same change in many places, and that's basically free because it's done automatically by tooling.

Small code segments may indeed be maintenance free.

If a large codebase that interacts with any other system/code (either through usage of shared libraries, network connection or a common file format) has not changed, that means there's likely technical debt that hans't been addressed (or needed to address).

You can continue to use most command-line FTP programs without problem. Since the terminal is a fairly stable interface, programs written long ago often have no problem compiling and running on modern systems, or only require small changes.

I wouldn’t actually say that, but it may be more of a problem of ecosystem maturity and priorities than it is one of interface stability: I work under Linux and love it, but getting a 20- or 30-year-old program to compile or run under it is surprisingly more painful than doing the same for a Win32 program of similar age, despite the ostensible stability and undeniably better documentation, including that of historical issues, in the former case. (To be fair, getting an old DOS program to compile or run anywhere except a full VM is an absolute nightmare, even if it can sometimes be offloaded to DOSBox maintainers.)

I would say it—getting a 20-year-old CLI program to compile and run is often not much trouble at all. Not always, but often.

Even if the program was never written from Linux, you can often get it to compile and run by fixing up headers and making some other minor changes to the source code. I’ve had plenty of success compiling and running programs that were only ever designed to run on IRIX or Solaris or other Unix systems.

You can do that in any language; just write software that no one uses. The rest of it needs to be maintained regardless of what language was used.

The main issue with old code, is that it slows down refactoring.

Refactoring new code is not faster

refactoring no code (because it was removed) is certainly faster.

Firefox removing support for non-encrypted data protocols makes me more confident in them, so consider me a fan of this messaging.

ftps exists. The solution to http wasn't getting rid of it, it was pushing for more https.

I'm not saying there weren't good reasons to get rid of ftp support, but that doesn't seem like one.

Surprising how many people don't know about ftps. FTP with SSL.

It's very obscure. Most things (mostly shared hosting lol) went straight to SSH's SFTP instead.

SFTP is mainly a *NIX thing. And it's a terrible hack built on top of a protocol meant to be something really different.

Also, while in theory SFTP can be as secure as FTPS, in practice it's not. How many people really check that the server public key signature it's the correct one? You know that annoying message that appears the first time you connect to a server and you have to say yes and if you don't it will not let you continue?

Not checking that give you the same security as having a HTTPS/FTPS server with a self signed certificate. You trust blindly the identity of the server, but there could be someone doing a man in the middle and stealing all your data. In that situation, FTPS is more secure, mainly because you need a valid TLS certificate that will give you some guarantee about the identity of the server.

At least in the pre-Let'sEncrypt era, lots of the shared hosting providers that gave you SFTP as an upgrade over plaintext FTP also used self-signed certs for their HTTPS admin panels :D

Server identity keys can be checked using SSHFP DNS records signed with DNSSEC, but that is not really mainstream unfortunately.

It's because there's multiple versions which are fundamentally incompatible.

http, dns, and other things are unencrypted.

What would happen if they rip it out?

What should be done is push for things like ftps or add big warnings around it.

That wasn't the decision. Maintaining this was.

they will surely rip them out when they have fallen to the levels of usage that FTP is at now

Edit: not sure why this is being downvoted... if you read the actual link, it says they intend to deprecate HTTP.

So good luck configuring your firewall or NAS that don't have a valid certificate.

Seems like a great opportunity to secure your server rather than training humans to ignore security warnings, doesn't it?

Secure how?

Obtaining a public certificate from a well-known registrar requires Internet connectivity for the ACME protocol, and that's at odds with the other best-security-practice of isolating internal systems like NAS devices well away from general Internet connectivity.

The problem is even worse for home routers. They need Internet connectivity to have a chance of obtaining a certificate, but since they provide that connectivity to a network they can't obtain the certificate until they're set up. But setup generally happens via a web browser and captive portal, so we're right in the middle of a bootstrapping problem.

https/TLS everywhere on the public Internet is a great thing, but it's not a reasonable expectation for private networks with private devices.

Solved if DNSSEC is deployed and root certificates are available as they should be pinned.

What, you're using old unsigned DNS and complaining about security? Or software so old that pinned certificates are outdated?

Virtually none of the DNS hierarchy signed with DNSSEC, and it's unlikely it ever will be. It's a strange best practice to appeal to, since it's been categorically rejected by almost every security team in the industry.

There are lots of perfectly good (well, suited to their purpose, anyway) appliances (as in: pieces of hardware that cost money) out there that have web interfaces that don't speak 100% valid https. In part, this is because achieving fully-valid https on a machine on a local network, without a static domain name, with a machine & network config that you (the vendor) don't fully control, potentially without an Internet connection, and without installing root certs on client devices is, to put it mildly, inconvenient, and used to be even worse.

Getting rid of http or insecure-https support completely would render either them, or your browser, useless, and require that one or the other be replaced.