3 ms·

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 br

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.

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.