9 ms·

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

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.

m463 7y ago
And it's not a great protocol.
- Someone1234 7y ago
  It is definitely a product of its time. Even FTPS isn't very good. SFTP is though (poorly named, it is based on SSH rather than the FTP protocol), but no web browser that I know of supports SFTP.
  - anyfoo 7y ago
    Yeah. Even though I remember a lot of the reasons for FTPs weirdness back then, looking at it below the cover today, it's a similar feeling as operating a mechanic calculating machine. Interesting, weird, with unfamiliar concepts, but you wouldn't do it like that anymore.
  - m463 7y ago
    Yeah, I think multiplexing commands and data was probably not as well solved a problem as it is now. Having worked with ssh/scp/sftp, I think sftp could be better too, and therefore more useful. It's intimately entwined with ssh, which means that instead of just transferring files, you have to give out ssh permissions where they're not required. Really, there should be an sftp client and server, strictly dealing with files. - You could have "accounts" that weren't real users on the machine - You wouldn't have to deal with users and shells and groups and permissions - You wouldn't have users running commands on your machine - You could have read-only sftp (sort of a repository with access controls) - You could have write-only sftp (sort of a dropbox) - You could make these formal, with daemons like read-only-sftpd or write-only-sftpd that were securely purposed to prevent unexpected file operations.
    - namibj 7y ago
      _nothing_ prevents you from doing that though. It's already implemented, even. Write-only might be hard, and could require eBPF hooking of open(2) with a filter to check if the permissions are correct. Read only isn't a problem, as denying writes and allowing reads is a trivial part of unix filesystems.
    - Dylan16807 7y ago
      You could do all that, but what's the advantage over a very simple web server behind TLS?
    - 1wd 7y ago
      https://github.com/drakkan/sftpgo#features https://github.com/drakkan/sftpgo#features does that I think. It was recently on HN: https://news.ycombinator.com/item?id=20531541 https://news.ycombinator.com/item?id=20531541
  - rsync 7y ago
    "SFTP is though (poorly named, it is based on SSH rather than the FTP protocol), but no web browser that I know of supports SFTP." For a time I was using Konqueror with fish:// URLs as a SFTP browser and it worked very well and made me happy ... I am not sure if that workflow still works but most rsync.net customers that I interact with are using sshfs on top of FUSE and mounting ssh resources as a local filesystem - so no browser involved.
tim58 7y ago
I'm not fine with this. I'm of the mindset that code written 20 years ago should run today. This is a breaking change on a critical piece of internet infrastructure. Google, by nature of operating the most popular web browser, has a moral obligation to the community to provide a stable environment. There are something like 10^9 webpages out there. How many of these will become less accessible because of this change? Many well maintained webpages will have to expend resources to migrate off ftp. Less maintained webpages with FTP links will not be updated and put the burden of installing an FTP client on the user, reducing accessibility. This is Google externalizing the cost of updating their software by forcing everyone else to update their webpages to following Google's specification.
- paulryanrogers 7y ago
  The same could have been said of Gopher. FTP is typically insecure and painful to use with it's varying port maps. Transferring files over HTTP or more modern protocols is the future.
  - userbinator 7y ago
    Transferring files over HTTP or more modern protocols is the future My direct and blunt rebuttal is "I don't care". The future is worthless without the present, and more importantly, the past. The continued effective destruction of history that these big tech companies are doing with their actions is a disturbing trend.
    - UncleMeat 7y ago
      Why doesn't HN support http login then? It's part of the spec.
      - tim58 7y ago
        A platform should support the entire spec. An app should correctly implement the parts of the spec it chooses.
  - 7y ago
tastroder 7y ago
Chrome still displays bitmap images. (S)FTP is still used, there's a lot of legacy stuff on the internet, and Google does not dictate what technology people use. It's still a web browser after all, not an Instagram viewer. > It's not part of the modern web, so it's just another loose end to tie up. While I see that it is shared by many here, I do not get this sentiment. It's still out there and rarely used, yes. But similarly would not require much maintenance for the time being, remove it when users decide it's dead, not just your shiny modern partners. The codebase cannot be that burdened by support for the protocol, why even take action? I guess what I'm trying to figure out is the reason why this even came up, is that to soothe some weird code base / maintenance metric?
- UncleMeat 7y ago
  Are you sure it wouldn't require much maintenance? "We have to support this other weird crap that nobody uses anymore" is like pain point #1 for nontrivial surgery.
  - tastroder 7y ago
    I could not honestly judge that since I'm not familiar with the code base / project leadership at all. Given the project's reach I'd figure they have that part of the code thoroughly covered by tests and well enough separated to keep maintenance efforts on the low burner. The linked Google Doc says that usage in a 28-day window was at 0.01-0.03% of users (not sure which figure to use there). Sure, that sounds horrid at first but think about how many users Chrome has, that's not nothing either. Instead of implementing encrypted connections to make their software better, they jump to deprecate yet another protocol. I just find this really hard to grok. How many people used the profiling features of the developer tools in that time frame for example? Not many? That's cool, do we get to keep those anyway? Browsers are complex, yes, it just would be nice if we could expect a bit more of a graceful deprecation process with better communication. If you don't feel like supporting it, move it to an extension/plugin to separate it and put it somewhere the community can pick it up easily.
abdullahkhalids 7y ago
> it's not relevant to Chrome's user audience/usecase. Rather, there are no ads on FTP pages, so Google is going to use it's power to stop countless people to stop using FTP.

m463 7y ago

And it's not a great protocol.

Someone1234 7y ago
It is definitely a product of its time. Even FTPS isn't very good. SFTP is though (poorly named, it is based on SSH rather than the FTP protocol), but no web browser that I know of supports SFTP.
- anyfoo 7y ago
  Yeah. Even though I remember a lot of the reasons for FTPs weirdness back then, looking at it below the cover today, it's a similar feeling as operating a mechanic calculating machine. Interesting, weird, with unfamiliar concepts, but you wouldn't do it like that anymore.
- m463 7y ago
  Yeah, I think multiplexing commands and data was probably not as well solved a problem as it is now. Having worked with ssh/scp/sftp, I think sftp could be better too, and therefore more useful. It's intimately entwined with ssh, which means that instead of just transferring files, you have to give out ssh permissions where they're not required. Really, there should be an sftp client and server, strictly dealing with files. - You could have "accounts" that weren't real users on the machine - You wouldn't have to deal with users and shells and groups and permissions - You wouldn't have users running commands on your machine - You could have read-only sftp (sort of a repository with access controls) - You could have write-only sftp (sort of a dropbox) - You could make these formal, with daemons like read-only-sftpd or write-only-sftpd that were securely purposed to prevent unexpected file operations.
  - namibj 7y ago
    _nothing_ prevents you from doing that though. It's already implemented, even. Write-only might be hard, and could require eBPF hooking of open(2) with a filter to check if the permissions are correct. Read only isn't a problem, as denying writes and allowing reads is a trivial part of unix filesystems.
  - Dylan16807 7y ago
    You could do all that, but what's the advantage over a very simple web server behind TLS?
  - 1wd 7y ago
    https://github.com/drakkan/sftpgo#features https://github.com/drakkan/sftpgo#features does that I think. It was recently on HN: https://news.ycombinator.com/item?id=20531541 https://news.ycombinator.com/item?id=20531541
- rsync 7y ago
  "SFTP is though (poorly named, it is based on SSH rather than the FTP protocol), but no web browser that I know of supports SFTP." For a time I was using Konqueror with fish:// URLs as a SFTP browser and it worked very well and made me happy ... I am not sure if that workflow still works but most rsync.net customers that I interact with are using sshfs on top of FUSE and mounting ssh resources as a local filesystem - so no browser involved.

tim58 7y ago

I'm not fine with this. I'm of the mindset that code written 20 years ago should run today. This is a breaking change on a critical piece of internet infrastructure. Google, by nature of operating the most popular web browser, has a moral obligation to the community to provide a stable environment. There are something like 10^9 webpages out there. How many of these will become less accessible because of this change? Many well maintained webpages will have to expend resources to migrate off ftp. Less maintained webpages with FTP links will not be updated and put the burden of installing an FTP client on the user, reducing accessibility. This is Google externalizing the cost of updating their software by forcing everyone else to update their webpages to following Google's specification.

paulryanrogers 7y ago
The same could have been said of Gopher. FTP is typically insecure and painful to use with it's varying port maps. Transferring files over HTTP or more modern protocols is the future.
- userbinator 7y ago
  Transferring files over HTTP or more modern protocols is the future My direct and blunt rebuttal is "I don't care". The future is worthless without the present, and more importantly, the past. The continued effective destruction of history that these big tech companies are doing with their actions is a disturbing trend.
  - UncleMeat 7y ago
    Why doesn't HN support http login then? It's part of the spec.
    - tim58 7y ago
      A platform should support the entire spec. An app should correctly implement the parts of the spec it chooses.
- 7y ago

tastroder 7y ago

Chrome still displays bitmap images. (S)FTP is still used, there's a lot of legacy stuff on the internet, and Google does not dictate what technology people use. It's still a web browser after all, not an Instagram viewer. > It's not part of the modern web, so it's just another loose end to tie up. While I see that it is shared by many here, I do not get this sentiment. It's still out there and rarely used, yes. But similarly would not require much maintenance for the time being, remove it when users decide it's dead, not just your shiny modern partners. The codebase cannot be that burdened by support for the protocol, why even take action? I guess what I'm trying to figure out is the reason why this even came up, is that to soothe some weird code base / maintenance metric?

UncleMeat 7y ago
Are you sure it wouldn't require much maintenance? "We have to support this other weird crap that nobody uses anymore" is like pain point #1 for nontrivial surgery.
- tastroder 7y ago
  I could not honestly judge that since I'm not familiar with the code base / project leadership at all. Given the project's reach I'd figure they have that part of the code thoroughly covered by tests and well enough separated to keep maintenance efforts on the low burner. The linked Google Doc says that usage in a 28-day window was at 0.01-0.03% of users (not sure which figure to use there). Sure, that sounds horrid at first but think about how many users Chrome has, that's not nothing either. Instead of implementing encrypted connections to make their software better, they jump to deprecate yet another protocol. I just find this really hard to grok. How many people used the profiling features of the developer tools in that time frame for example? Not many? That's cool, do we get to keep those anyway? Browsers are complex, yes, it just would be nice if we could expect a bit more of a graceful deprecation process with better communication. If you don't feel like supporting it, move it to an extension/plugin to separate it and put it somewhere the community can pick it up easily.

abdullahkhalids 7y ago

> it's not relevant to Chrome's user audience/usecase. Rather, there are no ads on FTP pages, so Google is going to use it's power to stop countless people to stop using FTP.