I also find the incredibly vague and nonspecific "but security!" scaremongering language to be quite hyperbolic, a repeat of the borderline lies mozilla peddled when they decided to dump xul for webextensions.
It seems to me that the removal of features like this amounts to "I don't use/understand it, therefore I'm going to assume it's not useful to anybody".
Of course, Mozilla being out of touch with its user base is hardly news, so this comes as no surprise at all to me.
(While I'm talking about browsers and particularly mozilla, I'd just like to take a moment to congratulate them on finally getting their market share down below that of edge. They've been working hard at driving firefox into the ground for a long time now, and I'm sure they must be feeling very proud to have finally achieved this important milestone in their seemingly unending quest to achieve that holy grail of 0 users. So I'd just like to say: Nice work, Mozilla!)
Parts of it are, sure, but parts of it are an absolutely horror show (The client opens a port, and then the server connects back to it!?), text conversion and binary modes that's based on ASCII, different list formats, etc. It's not great. Worse, it doesn't support the good stuff like implicit TLS extensions
> Supporting FTP isn't some big technical challenge. The code has been there in the firefox codebase for nearly 20 years now, running just fine. All you need to do to continue to support ftp is nothing at all.
Not at all. Continuing to support FTP means continuing to defend attack surface that's implemented as 20 year-old code, to deliver a feature that in 2021 the majority of people do not use.
It's a cost-benefit analysis. I want Mozilla to do more. If they believe removing FTP support enables them to do more, I'll all for it.
It's simpler than a pdf viewer.
>It's a cost-benefit analysis
If it were, they'd have never added a pdf viewer in the first place. Everyone already had one. Near-zero benefit, huge cost.
>I want Mozilla to do more.
At this point I'm afraid we're just going to have to agree to disagree. For the last 5+ years, Every time Mozilla "do more", I throw up in my mouth a little.
Every time I clicked a PDF online, I dreaded the external viewer opening (especially Adobe Reader). I very much liked when they integrated a PDF viewer. Chrome also has one.
I'm willing to bet the internal PDF viewer has at least 100x (more likely 1000x) the users the FTP client had.
Why was I forced to install a substandard, feature-poor, ridiculously slow pdf viewer that I never wanted and which took over as the default pdf viewer against my wishes and without asking me, just because you couldn't be bothered to install a decent one?
>I'm willing to bet the internal PDF viewer has at least 100x (more likely 1000x) the users the FTP client had.
Yeah, that tends to happen when you change the defaults without asking.
but you didn't address my question
Multiple web browsers have embedded PDF viewers because the PDF viewing experience for most people sucked so much. That's not a product decision taken lightly.
Your personal experience does not reflect that of many other browser users, it seems. Even on mobile I dread clicking a PDF link.
But it's nowhere close to the complexity of the entire web stack, not within an order of magnitude. It's much, much simpler.
I'd respond to the rest of your vague and incorrect opinions, but why would I do that if you're not even going to bother to address my points despite me asking you to repeatedly?
If I must spell it out, there you go:
> Why was I forced to install a substandard, feature-poor, ridiculously slow pdf viewer that I never wanted and which took over as the default pdf viewer against my wishes and without asking me, just because you couldn't be bothered to install a decent one?
Because you are part of a minority of Chrome and Firefox users and I'm probably part of the majority of users, in this regard. I don't know this for sure, but if a Google program manager decided to back building and embedding an entire PDF reader into a browser, I'm 99% convinced this is true.
We're dumb and you have to live with us.
Life's tuff.
BUT: you do have to concede that it's not a technical reason. It boils down to "Adobe are goddamn useless, let's just do their job for them because it will make our life a bit easier". There's no requirement for pdf viewing in the HTML spec or anything like that. It's not required for web browsing and it doesn't really have any place in the browser in a technical/engineering sense - from an "engineering purity" perspective these two things should be separate, even if you do like your pdf viewers written in javascript. The "correct/pure" engineering solution would have been for them to bundle their awful javascript pdf viewer in an electron(ish) app and release it as the "google pdf viewer", with all the requisite spam in gmail and the technical press, and to have chrome default to it if it's installed. Hell, you could make it a separate application and still bundle it with chrome.
There must have been a LOT of support enquiries about "the adobe doesn't work" for it to survive a cost/benefit analysis for implementing an entire pdf viewer. That's not a trivial piece of work that somebody churned out in an afternoon (despite the performance of the thing feeling like it ;) )
If I was that product manager, I would not make that decision lightly. First I'd have built a special page into my support area that redirects the user to adobe.com/support if they type "pdf" or "adobe" into the "search support" bar. (You know what I mean - you've seen it in action on help desk sites where they try to fob you off rather than just giving you a "contact us" box straight away).
This is all a whole lot easier to implement than a pdf viewer. In fact if you're using something like zendesk you get it for free. For me to decide to build a pdf viewer into my browser, I'd have to be getting a high volume of support emails about it after I'd implemented the change above.
I don't think that's what happened.
In the post i largely ignored, you said:
>Multiple web browsers have embedded PDF viewers because the PDF viewing experience for most people sucked so much
Allow me to give you an alternate explanation / interpretation, which I admit might come across as "a little bit cynical" or paranoid, but which I believe to be more fully borne out by the facts than the "cost/benefit analysis" theory you advocate. I don't think "multiple browsers" did that at all. Here's my theory:
1. Google decided to build a pdf viewer into chrome because they were busy trying to turn chrome into an operating system (see also: chrome os), and they knew that would mean including a pdf viewer, since a pdf viewer is a fairly essential tool for an operating system if it wants any kind of mainstream adoption. This had the added side-effect that for many users their pdf viewing experience would improve, because adobe are basically incapable of doing software. So it was really a "two-fer" for google.
2. Mozilla, seeing google's announcement for a pdf viewer built into their browser, did what Mozilla has been doing for the past decade: copy Chrome without giving any thought at all to any of the considerations you and I are discussing today. Or indeed any consideration other than "what is google doing with chrome this week?".
Now, I do try to keep my paranoia and cynicism in check, but to me this seems like a far more likely explanation. Perhaps I'm wrong. It would be kind of nice if I was. If you have some data to support your theory I'd love to see it.
I don't have much data to back up my theory. I can't be bothered looking into what chrome's support site was like pre-pdf-support. But I do have one data point: I can confirm that chrome added pdf support first, with Mozilla aping them almost immediately (they were pretty much at parity within a year or two).
Maybe Mozilla had coincidentally already done a full cost/benefit analysis of adding a pdf viewer before google went live with theirs. It's not impossible. But it seems a little unlikely to me.
</rant> ;)
This was the justification for removing RSS support.
And look at what Mozilla has chosen to develop instead.
Your reasoning, that "Continuing to support $x means continuing to defend attack surface that's implemented as $y year-old code, to deliver a feature that in $z the majority of people do not use," would ultimately consign every feature on the web to the book-burners' flames, except for the worthless minority of features that the majority of people do use. Chinese HTML text support, I suppose, and biometric authentication, and whatever the latest video codec is.
After all, it's 02045. Who watches videos encoded in VP9 now anyway? It's been obsolete since 02028! Or reads English text? Much less Hebrew? The majority of people do not use those features. Why should we continue to defend that attack surface?
Let's pick something else from this golden age of "browsing HTML pages via the FTP protocol" that people on this thread keep professing: XBM images, the very first image format ever supported by browsers, and used when Marc Andreessen literally invented the IMG tag [0].
XBM is a crazy simple image format [1]. Yet, because it is essentially C code that defines a buffer size and then gives you a char array, caused security bugs over and over [2] in all major browsers. Since virtually no one was using XBM images, the browsers all removed support for it [3].
The browsers removed code that was already written, and abandoned functionality that had already existed, because it reduced attack surface supporting something that virtually no website was using. Exactly like FTP support.
0 - https://eager.io/blog/to-what-extent-did-marc-andreessen-inv...
1- https://en.wikipedia.org/wiki/X_BitMap
2- https://www.cvedetails.com/google-search-results.php?q=xbm+i...
You're contradicting yourself here; Hebrew is a language used by millions of people (about ten million, so 99.9% of the world's population does not use it) and also an old format (about 3000 years old). "Pruning" support for old formats makes history inaccessible; "pruning" support for old protocols requires constant effort to keep your servers compatible with whatever is fashionable with today's cascade of attention-deficit teenagers [CADT].
And if we follow your originally stated reasoning, "Continuing to support $x means continuing to defend attack surface that's implemented as $y year-old code, to deliver a feature that in $z the majority of people do not use," we ineluctably arrive at the conclusion that we should remove support for languages used by millions of people.
Taken literally, we should remove support for all languages, since no language is used by more than 50% of the world population, but in keeping with the principle of charity, I interpreted your "majority" as "vast majority". I'm not sure where exactly the vast-majority cutoff lies: a feature that 90% of people do not use? That would include all natural languages except English and Chinese. 95%? All languages except those, Hindi, and Spanish. (In particular, it leaves out all those RTL languages that cause so much complication in text rendering, like Arabic.) 99%? That leaves 20 languages, but not, for example, Persian, Swahili, Italian, or Thai. Even a cutoff of 99.9% might leave out Hebrew, Uighur, and Greek.
What percentage of users do you think use View Source? The web inspector? Printing?
That's not a strawman argument; it's a slippery-slope argument. And, I think, it's a valid slippery-slope argument. If we are going to avoid removing support for these things, we need a better basis on which to make the decision than, "Continuing to support $x means continuing to defend attack surface that's implemented as $y year-old code, to deliver a feature that in $z the [vast] majority of people do not use."
I do agree that there needs to be some kind of cutoff. Gopher is probably below it; WAIS and XBM certainly are. But FTP?
XBM was never very widely used in web pages because it didn't support color, grayscale, or compression, although for a little while it was the only image format supported by browsers that supported transparency. I did put it on a few of my web pages, but as soon as Netscape added support for transparent pixels in GIFs, I switched over and never looked back. This would have been about 01994.
By contrast, there are about 1.1 million anonymous FTP servers today, one out of every 4000 public IP addresses, and about one for every 30 HTTP(S) servers: https://zakird.com/papers/dsn-ftp.pdf That's more than the number of HTTP servers that existed for the first seven years of the Web, up to 01997: https://news.netcraft.com/archives/2021/05/31/may-2021-web-s...
You can be sure that there's millions of people using them. Probably more people than speak Hebrew, in fact.
Hopefully the browser makers will be transparent with this telemetry.
Popularity is not a valid measure of value. The July 02021 issue of People magazine sold 3 million copies, in a single month, and is almost completely devoid of value. (Maybe in 02068 it will provide valuable insights into vapid 02020s US popular culture.) Amazon tells me Claude Shannon's Mathematical Theory of Communication is outsold by 185,210 other books at present, so perhaps it has sold 100 copies this month, but it is the foundation of data compression, error correction, and significant amounts of artificial intelligence work. One Hundred Years of Solitude has sold about 50 million copies—over the past 54 years, so perhaps it sells 80,000 copies a month, 40 times less than the July 02021 issue of People. (But probably less; it probably doesn't sell as much as it did 30 years ago.)
40:1 is more than the ratio between the number of HTTPS servers and the number of anonymous FTP servers.
Well said. And the more they fail, the more they double down.
But their decisions go beyond incompetence. They might as well be controlled opposition, actively undermining open web technologies.
They deprecated RSS support with very flimsy justifications, but they make supporting the latest DRM standards a top priority, because they are terrified of losing the blessing of Netflix.
Yeah, this pretty much sums it up. A conspiracy minded person might accuse them of all kinds of nasty shenanigans, especially given who their primary finding source is these days.
>They deprecated RSS support with very flimsy justifications, but they make supporting the latest DRM standards a top priority, because they are terrified of losing the blessing of Netflix.
Oh now you're just being cynical. RSS support was like 150 lines of code! A huge attack surface! And it was invented before the year 2000! That makes it useless!
As for DRM, I'm sure that encryption algorithms are much simpler to implement and have less attack surface than an RSS reader, and that Mozilla added this tech for my own good, and that I just don't understand how it's useful to me because I'm a dumb.
Well, there is nothing vague here: FTP is a cleartext protocol, and we're migrating towards protocols that provide integrity and encryption.
Sometimes I think it's a generational thing. I find it hard to accept this, growing up with testing all protocols with Telnet and so on. But unfortunately the Internet has changed a lot, and especially bad and unscrupulous people learned how to find all possible and sometimes very creative ways to abuse whatever had been created in the past. So I understand that cleartext POP3, IMAP, SMTP and FTP authentication should go away.
Anonymous FTP is a slightly different beast though. Security-wise, it has the same weaknesses as regular HTTP. But nobody is removing HTTP support from web browsers (yet). So I'm a bit sorry to see it removed from FireFox. There are many better things to copy from Chrome.
HTTP is a cleartext protocol. Why does your browser quietly navigate to any HTTP site you throw at it? Anonymous FTP isn't any less secure than HTTP.
Why does your browser scream at you for connecting to an encrypted but unverified site, such as a self signed certificate on a closed network, but have no warnings at all for an unverified and unencrypted HTTP connection?
How do you know the context that I am using a plaintext protocol in? How do you know I'm not connecting over a patch cable to the computer next to me? How do you know I'm not connecting over an SSH tunnel?
The user should easily be able to override these safety measures.
The only argument I have heard this is that the user could be tricked into disabling security mechanisms. But that is true of anything in computing. The user could be tricked into typing in rm -rf.
When there is inconstancy like this, it usually implies there is something else going on that we aren't seeing. I have a feeling that companies like Google and Apple have an agenda to move people away from having too much outside of their influence.
I think it's both. For one thing, I think they genuinely do care about security, because any high-profile incident involving their products is a cause of embarrassment for them. At the same time, I have a feeling they would prefer people not inspect the traffic moving in and out of their apps, for example.
This is true, but it ignores the fact that the web has been moving towards depreciation of HTTP in favor of HTTPS.
While FTP is an established standard, FTPS is kind of a nightmare with different and incompatible variants.
The parent explicitly mentions that there are no warnings for a cleartext http connection, but warnings for an encrypted connection to a self-signed certificate.
This is security theatre, not actual security.
Sometimes there's nothing wrong with transferring stuff in cleartext.
Screaming vague and meaningless "for security!" mantras isn't helpful.
I asked how many times you saw this exploited in the wild, not "how would an attack theoretically work".
Today few resources are found on http though.
I cannot for the life of me remember the last time I landed on a page with FTP or had to use FTP in any way. Even lists of file downloads are http pages where I just click on the file.
* ftp://ftp.isc.org/isc/ – also available as http://ftp.isc.org/isc/
* ftp://ftp.oreilly.com/pub/ – only available as FTP
For the O’Reilly URI, it’s convenient to be able to click on directory links in the browser and then open HTML and PDF files without requiring another program.
So, it’s nice to have native FTP handling in Firefox for the odd time I’d use it but I can understand why Mozilla decided to remove it.
Seems legit.
I mean, it's opposed by the argument that it used to be popular. It's a pretty low bar.
FTP is a protocol that dates to when NCP was the protocol suite that ran the Internet. It was retrofitted to TCP/IP. That's why there's a command session and a data session. The protocol is so old that it dates to a time when IP+port was the unique identifier for a half-duplex connection. Nobody even uses active FTP anymore because everyone has firewalls now.
It's not like web browsers have added SFTP support. They haven't even added FTPS support (either flavor) as far as I'm aware. I just don't see many use cases for FTP anymore. Why would you choose FTP at this point over HTTP(S), SFTP, BitTorrent, etc.?
The last system I used that required FTP actually used implicit FTPS. Worse, when the vendor implemented SFTP to replace FTPS like their customers had been demanding, they actually implemented Simple File Transfer Protocol (i.e., RFC 913) and not SSH File Transfer Protocol. I wish I were joking.
I'm seeing this a lot today. It's almost like people have forgotten what FTP stands for.
The use case is transferring files.
>Why would you choose FTP at this point over HTTP(S), SFTP, BitTorrent, etc.?
Because I don't have a client for any of the others installed
Yes, and it's not particularly unique or well suited to that task over any other protocol.
> Because I don't have a client for any of the others installed
Then I guess you can use telnet for FTP as well as web browsing.
When the files are on an FTP server it is. And given that there are more than a million anonymous FTP servers on the internet today, there are a lot of files that are on FTP servers.
I can’t think of a scenario where I would need FTP in 2021. Can you point me at one?
ftp://ftp.kontron.com/Products/Motherboards/Industrial/D3544-S_Mini-STX/Documentation/ ftp://ftp.panasonic.com/pub/panasonic/call_center/firmware/
One advantage of ftp is that it is much easier to have access control on different resources than dealing with .htaccess files so it was popular with customer service.
The consequence will be that many ftp servers still hosting software/firmware for legacy products will be taken down and their content lost.
> The consequence will be that many ftp servers still hosting software/firmware for legacy products will be taken down and their content lost.
Even if all the browsers dropped support for FTP, Finder and Explorer both have native FTP support, and there are plenty of clients otherwise. I doubt those resources will be taken offline.
No, because it opened automatically and was nearly seamless. I didn't even notice that I'd been moved to Finder at first.
>I didn't even notice that I'd been moved to Finder at first.
You... can't tell finder from a web browser??
There goes 100% of your credibility with regard to UX.
Of course I can tell the difference between a browser and the finder. My point was the transition was so seamless that I thought Safari was embedding the finder in the Safari window until I looked up at the app bar and realized it had actually switched apps.
But feel free to go on dismissing me, since it's clear from your comments that you think no one in the world is right but you.
What's the "good" interpretation? That you suffer from an attention deficit disorder, so it's not your fault that you have no clue what you're looking at and the things you're saying are patently ridiculous?
> I thought Safari was embedding the finder in the Safari window
So, to summarise, your argument is that you have no idea about how your software works or what it does. It felt "seamless" to you because you had no idea what to expect and think your browser magically embeds other applications now.
Just in case I wasn't clear last time: If you think that switching to an entirely different different application is a reasonable thing to miss, you have zero credibility where UX is concerned.
>it's clear from your comments that you think no one in the world is right but you.
Lots of people who aren't me are right. It's just that statistically speaking those people tend to agree with me on most things.
Kragen, for example, has been saying things that are right all day (In particular I found this treatise on security stuff to be damn near sexy: https://news.ycombinator.com/item?id=27900935).
Even some people who disagree with me on a bunch of points have said things that are right. It's happened today. And you'll see me acknowledge them when they happen if you look.
The reason you haven't seen that is because you haven't said anything that was right.
But if you really believed this assertion you could easily prove it accurate: All you'd need to do is say "OK, yes, I had no clue what I was looking at. I don't know why I thought the finder was in a web browser. I guess I was just confused. That was dumb and inattentive of me". If your theory is accurate I won't be able to agree with that.
You know, you're really not in a good position to criticize other people in this conversation with exaggerated complaints about their intellectual arrogance.
"my UX wasn't diminished"
"nearly seamless"
That's pretty funny.
Archive of apple 2 software and documentation. I use it a lot.
Oh Wow! cool! I'm so impressed!
So what you're saying is that because you "use the internet a lot" that you know everything about the requirements, hardware, software, and most importantly limitations of every single internet user on (and off!) the planet.
I guess I should at least give you some credit for not having any problems with self-doubt.
I had to use it this past weekend to get some firmware from the vendor for a network switch. ¯\_(ツ)_/¯
Not that I'll really miss it in Firefox but still...
That's not two important services you've named, but only one, and at some point it will be destroyed; it's only temporary. Hopefully it will last a few decades.
Brewster Kahle, the founder of archive.org, has a saying:
Governments burn libraries.
If you want to know what 02017 was like, you can ask pretty much anybody; most of them will remember pretty well. You may remember yourself. But if you want to know what 01997 was like, well, most people have pretty much forgotten. Did you know they didn't check your ID at the airport in 01997? People would resell non-refundable airline tickets in newspaper classified ads. Airlines wanted to stop this practice, but competition prevented them from instituting mandatory ID checks. Until 02001, when the US entered a permanent state of war on abstract concepts.
It's true that there are a lot of things that are true today that weren't true in 01997. But most of those things are not worth knowing, because they won't be true in 02045 either. In fact, a lot of them won't be true in 02022.
So, losing access to a web page from 02020 is bad, but losing access to one of the few remaining web pages from 01997 is much worse.
Why are there people who think otherwise? Because they never learned to think of the World Wide Web as the greatest library in human history, probably because they don't value libraries or learning; instead they think of it as a way to dunk on their political opponents and consume up-to-date memes from Instagram or Netflix.
> More broadly, this is a tradeoff between the traditional vision of the WWW as a vast library, in which human knowledge accumulates over time and becomes accessible to all, and the strip-mall vision of the WWW as a means to sell people things they don't need.
I don't get this at all.
* Are you saying FTP is a fundamentally better protocol to download files than HTTP?
* Are you saying that it would be easier to run a FTP server than a HTTP server?
* Do you think that FTP-only-sites generally depend on HTML-over-FTP for browsing? Because that's something I've never seen AFAIK, either they use HTTP-only or HTML-over-HTTP for browsing and FTP for download.
I get the "strip-mall vision of the WWW as a means to sell people things they don't need" complaint, but that does not seem related to the protocol discussion of HTTP and FTP at all.
Web pages that are profit-making ventures, with employees dedicated to working around the latest browser featurectomies, will have no trouble with this sort of constant change. Web pages that are just HTML files that someone uploaded to a server in 02003 will disappear into the memory hole. They're already hard to find, but now they'll be totally inaccessible.
FTP is a bad protocol. HTTP servers are generally easier to run than FTP servers, and especially to run in a secure fashion. None of that is relevant to whether we should break functionality that has been core to the WWW project for 31 years.
No, I mean that a lot of FTP servers by default want you to do password authentication (yes, in cleartext); by default they grant access to your whole filesystem; and a minimal FTP server is significantly more complicated than a minimal HTTP server, and so it's more likely to contain vulnerabilities. Also, by default, most FTP servers support writing to files, and HTTP servers don't. I'm not talking about eavesdropping on the protocol itself or packet spoofing, which I agree are equally easy with FTP and unencrypted HTTP.
This HTTP server I wrote is, I think, 324 instructions of machine code, and it doesn't use any libraries: http://canonical.org/~kragen/sw/dev3/server.s. I think it's plausible that it contains no security vulnerabilities, other than a DoS by flooding it with connections. I have a fair bit of confidence that it doesn't have an exploitable RCE vulnerability. I'm not sure if there's ever been an FTP server we could say that about.
But none of that is relevant to whether we should break functionality that has been core to the WWW project for 31 years.
Do they? Do FTP servers usually just open up everything to any host? That's not the way I've used them. Don't they usually default to sharing one directory and nothing else?
> Also, by default, most FTP servers support writing to files
That's kinda what file system permissions are there for, and it is usually pretty configurable in the server, right?
> This HTTP server I wrote
Love it, but I have no experience writing assembly, and almost no experience writing C, so I cannot say anything more (I just don't have the experience or knowledge). I still have to ask though, is this relevant to something that asks if FTP is needed over HTTP on the protocol level?
> But none of that is relevant to whether we should break functionality that has been core to the WWW project for 31 years.
I think the question here is if it needs to be in the browser though? There are plenty of protocols in wide use on WWW that are not browser supported and considering that none of the "secure" variants of FTP are supported in browsers it does not seem out of the question to remove this.
If this was a priority then I'm guessing that over the last decade or so getting ftps or sftp working in the browser would have been worked on.
Typically they do not allow anonymous access by default, but do not discriminate by host.
> That's not the way I've used them. Don't they usually default to sharing one directory and nothing else?
That's a good default, but historically speaking you had to chroot them to get that behavior. Nowadays you could use Docker.
> [Writing to files] is kinda what file system permissions are there for, and it is usually pretty configurable in the server, right?
Running a server that includes code to write to files is unnecessary for serving up web pages, and it's more likely to accidentally result in the server writing to files than running a server that doesn't. You're more likely to misconfigure a server that's pretty configurable than one that isn't. Filesystem permissions are generally far looser than you want for anonymous access over the internet; I don't want random strangers to read my /etc/passwd or see which versions of what Python modules I have installed, much less create files in /tmp. Filesystem permissions are only usable in the first place (for uploading files) if the FTP server has the authority to set its user ID to the user ID of the authenticated FTP user, which means it needs to run as root until after they've authenticated. Also it means I need to add my FTP users to my real /etc/passwd and /etc/shadow.
> is this relevant to something that asks if FTP is needed over HTTP on the protocol level?
My point with the two-kilobyte secure (?) HTTP server is that FTP is a bad protocol. The reason browsers should continue to support FTP is not that FTP possesses some kind of unparalleled technical excellence, the way NNTP and IRC could be argued to; it's that FTP, however janky it may be, is still useful, and providing better access to existing FTP repositories is one of the main reasons the WWW was created in the first place.
> If this was a priority then I'm guessing that over the last decade or so getting ftps or sftp working in the browser would have been worked on.
There's relatively little advantage to ftps or sftp over unencrypted FTP for anonymous access—you aren't sending the FTP server any files or credentials, just the names of files you want—and no advantage for backward compatibility, since the existing FTP servers you want backward compatibility with aren't running ftps/sftp.
Of course they do, it's quite normal. Here's Netscape Navigator:
Firefox supported this completely until Fx61, when it disabled FTP subresources on HTTPS. Even then, you could still view HTML pages served over FTP until Fx70.
Not allowing FTP subresources on HTTPS is basically the same as not allowing HTTP subresources on HTTPS, that is just logical.
What I'm saying is: is there a meaningful difference? Both need to bind to a port that is privileged and read files from the served directory. There is no difference between a ftpserver and a webserver from a permissions/privilege perspective.
There are a few people commenting with nonsense like this:
> You can configure Firefox to open "ftp://" links with the client of your choice. This is a non-issue.
That's absolutely useless if the client of your choice can't render HTML and the ftp:// link is to an HTML file.
The fundamental idea of the WWW project was that it provided a universal, uniform interface to all the information on the internet, regardless of protocol. This move amounts to Firefox abandoning that vision. Abandoning Gopher was maybe reasonable—there just aren't that many Gopher servers out there—but FTP is still a widely used protocol.
More broadly, this is a tradeoff between the traditional vision of the WWW as a vast library, in which human knowledge accumulates over time and becomes accessible to all, and the strip-mall vision of the WWW as a means to sell people things they don't need. This move amounts to burning down a wing of the library (or, at least, its card catalog) because it wasn't profitable enough. Or because people keep getting mugged there, I guess.
This kind of intentional functionality regression is precisely the kind of thing I use free software to avoid.