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.
> 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.