21–30 of 350 posts
Not bothered by this. No one should be running FTP in 2019. It sends passwords in plain text for christ's sake.
No one really uses FTP to transmit anything secret or confidential. Most of the time the password to that FTP server is just "guest" and the same file can also be retrieved by HTTP without authentication.
Not bothered by this. No one should be running FTP in 2019. It sends passwords in plain text for christ's sake.
The same could be said for HTTP... FTPS and SFTP do exist. That said, I agree that its outmoded today.
Not bothered by this. No one should be running FTP in 2019. It sends passwords in plain text for christ's sake.
No one really uses FTP to transmit anything secret or confidential. Most of the time the password to that FTP server is just "guest" and the same file can also be retrieved by HTTP without authentication.
So...no reason for FTP in the browser, since it already supports HTTP?
Google don't want users, they want pliant consumers. The idea that young people know more about tech than their parents will become less and less true in the future.
Earlier quoted context omitted.
Why do we need a separate legacy protocol for file transfers? What’s the benefit in keeping protocols for the sake of it?
We need a protocol for file transfers because having a protocol makes it more standardized and interoperable than if everyone rolls their own solution. Do we need browser support for it? It still happens now and then that a link will have an ftp target. That could be handled in the browser or it could open a separate url-handling application, as e.g. email or magnet urls do.
It uses separate "command" and "data" channels. The data channel is usually in the other direction, i.e. the client listens to a connection from the server when downloading a file. Passive mode, and an extra command for that, had to be implemented, and if the stars don't align right, it still ends up being a pain.
FTP also used to default to 7bit. If you did not explicitly switch to 8bit mode, you got corrupted downloads. This maybe made sense in a world with fundamentally different encodings, line endings, and where connection speeds were slow enough that downloading text files was a big task, but now?
Then, if I remember correctly, the file listing you got was not actually standardized, it could just be the output of the "ls" command on the server! FTP clients used to be dumb and just passed that output through to you, so it did not matter much. For smarter clients later, it did start to matter.
Finally, what does FTP actually offer that, in most cases, HTTP, and, in niche cases, rsync, scp or sftp do not offer?
I'm personally fine with this. FTP is a different protocol, just like BitTorrent. It's not part of the modern web, so it's just another loose end to tie up. Even though it will be around for a while, it's not relevant to Chrome's user audience/usecase.
FTP isn't used much anymore, but IMO/IME, it's still nice to have for those rare times when you come across a file that you need to download and it's served over FTP.
Like, worst-case ChromeOS loses ftp?
Google don't want users, they want pliant consumers. The idea that young people know more about tech than their parents will become less and less true in the future.
Why do we need a separate legacy protocol for file transfers? What’s the benefit in keeping protocols for the sake of it?