> even the security part seems to be about HTTPS, right?
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.
> by default they grant access to your whole filesystem
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.
> Do FTP servers usually just open up everything to any host?
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.
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.