6 ms·

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 f

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.

georgebarnett 7y ago
Why do we need a separate legacy protocol for file transfers? What’s the benefit in keeping protocols for the sake of it?
- im3w1l 7y ago
  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.
  - anyfoo 7y ago
    Yes, but as someone who's been around when FTP was a big thing, and HTTP only just came into fruition... what, really, is the benefit of FTP? In fact, FTP is actually a horrible protocol, that caused me much pain even back then: 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?
    - viraptor 7y ago
      > It uses separate "command" and "data" channels This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
      - anyfoo 7y ago
        Yes. Just like the text conversion thing, or the non-standardizes file listing thing (not everything was UNIX-ish, VMS was still around), at the time it made sense. Today it's just clunky hindrances, and the protocol has lost its benefits.
      - ZWoz 7y ago
        I would argue, that separate control/data channels makes protocol more secure. You can't sneak commands on data and you don't need worry, how do terminate data transmission and switch back to control mode.
- big_chungus 7y ago
  FTP is basically useful as a single-use protocol: file transfer only. File transfer only allows a more stripped-down, dedicated server with better security. Vsftpd and others have excellent security specifically tailored to permission-based file transfers with access control lists etc. You will rarely find a comparable http option. It's not perfect, but there are also good partes and reasons why it's still around. Secure FTP is still a good option for some cases.
  - anyfoo 7y ago
    As written in another comment, you will find FTP to actually be a truly horrendous protocol, at least from today's perspective. I'm not sure there is anything that FTP offers, that the rsync or sftp, for example, offer much better (or simply HTTP if it's only in one direction), and then some. SFTP is actually not just FTP over SSH. The protocol is different precisely to get rid of a lot of the outdated nuisances.
    - takeda 7y ago
      FTP became a nightmare to use thanks to introduction of NAT, it was developed before NAT existed so it wasn't designed with it in mind. As for rsync, sftp, scp those are heavily tied to ssh, rsync to the point that you actually ssh to host and call rsync command. rsync has a server mode as well, but almost no one uses it.
    - big_chungus 7y ago
      Yes, there are lots of issues with FTP. I've worked with it, and it is in many ways a nightmare. That aside, you can use FTP for auth and ACL in of which HTTP and rsync just aren't capable. I'm not sure this is a flaw in the core protocol so much as the tooling, but there you have it. FTP config syntax may often be byzantine. But it's widely supported (especially on old, low-spec, or embedded devices). For newer stuff, yeah sftp is probably better. But it's still got its uses.
      - georgebarnett 7y ago
        Completely agree it still has its uses. So does Cobol and any number of older legacy tooling. That’s not the point we are discussing though; This is specifically regarding Chromium supporting FTP.
- lazylizard 7y ago
  Ftp is fast
  - georgebarnett 7y ago
    Genuinely curious. Why do you think a bitstream from an FTP server is faster than from a HTTP server?
    - ZWoz 7y ago
      Whole solution and experience is different, even if some point uploading file by bytes over TCP is similar. HTTP server itself isn't solution. You need code implementing upload functionality, probably support for uploading many files at once and tracking progress. Now you client uses javascript and that client is remote, you need to "download" it from HTTP server. FTP client is small, local and don't have much overhead, HTTP with its stateless form needs headers retransmitted with every request.
      - georgebarnett 7y ago
        That’s all well and good, and has nothing to do with Chromium keeping ftp support.
        ZWoz 7y ago
        Indeed, but your question wasn't about Chromium ftp support. Note, I am not lazylizard, so I don't really know, what he meant by "Ftp is fast", but I have my own thoughs and general dislike to webify everything on internet.
- layoutIfNeeded 7y ago
  How would you download a folder of files via HTTP? I don’t want to wait 10 minutes for the server to zip them, thank you.
kadoban 7y ago
Both of those may be true, but does it have anything to do with ftp going away? It's a pretty bad protocol that's rarely used, why should browsers still support it?
systematical 7y ago
Use a proper client like Filezilla for this and go over SFTP, no reason for FTP these days and even less so in a browser.
- takeda 7y ago
  There is[1], but yeah it doesn't apply in this context. [1] https://en.wikipedia.org/wiki/File_eXchange_Protocol https://en.wikipedia.org/wiki/File_eXchange_Protocol
kart23 7y ago
I saw a 6th grader using filezilla to update his website the other day. 99% of people didnt know what ftp was 10 years ago, that hasn't changed. Every generation loves to trash the one below it, that certainly will never change.
- mlyle 7y ago
  I think it's a lot harder to become technically competent these days. Before, computers compelled you to have a certain level of technical competence to be a user. Now, the barrier to entry is a lot lower, but there aren't many of the very young learning their way around command lines, etc. The resources once you are on the track to doing technical stuff are far better, but you're less likely to end up on that track-- especially at an early age.
  - sophiebits 7y ago
    You used to need a certain amount of technical competence to be literate. Now we teach everyone to read and write! What is the world coming to?
    - mlyle 7y ago
      That's hardly what I said. It's good that computers are more accessible. But by making it easy, we're providing less opportunity for people who are curious about innards at an early age. Of course, now we're teaching computational thinking in schools, but IMO it's a really big open question whether our attempts to teach that work, especially in elementary school.
    - userbinator 7y ago
      It's more like "now we don't have to teach everyone to read and write, we do the (filtered/censored/etc.) communication for them."
  - cameronbrown 7y ago
    > Now, the barrier to entry is a lot lower, but there aren't many of the very young learning their way around command lines, etc. I'm a fairly young person. What I've seen over the past few years is technology is finally useful and accessible to everyone. Forcing people to use the command line isn't a useful skill for 99.5% of people anymore, it's just senseless gatekeeping to make it a computer requirement. I got into computers by ripping into Windows XP internals and learning how it worked when I was a kid, no command line needed. There will always be people who are more curious about how things work. Have faith that kids are smart enough to use the internet to learn for themselves. Just because technology is easier does not mean it's harder to learn how to be "technically competent". Remember that the definition of technically competent moves with the times, too.
ahupp 7y ago
Why do you assume this is driven by some desire for "pliant consumers", vs a desire to build a simpler and more secure browser?

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.

georgebarnett 7y ago

Why do we need a separate legacy protocol for file transfers? What’s the benefit in keeping protocols for the sake of it?

im3w1l 7y ago
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.
- anyfoo 7y ago
  Yes, but as someone who's been around when FTP was a big thing, and HTTP only just came into fruition... what, really, is the benefit of FTP? In fact, FTP is actually a horrible protocol, that caused me much pain even back then: 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?
  - viraptor 7y ago
    > It uses separate "command" and "data" channels This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
    - anyfoo 7y ago
      Yes. Just like the text conversion thing, or the non-standardizes file listing thing (not everything was UNIX-ish, VMS was still around), at the time it made sense. Today it's just clunky hindrances, and the protocol has lost its benefits.
    - ZWoz 7y ago
      I would argue, that separate control/data channels makes protocol more secure. You can't sneak commands on data and you don't need worry, how do terminate data transmission and switch back to control mode.
big_chungus 7y ago
FTP is basically useful as a single-use protocol: file transfer only. File transfer only allows a more stripped-down, dedicated server with better security. Vsftpd and others have excellent security specifically tailored to permission-based file transfers with access control lists etc. You will rarely find a comparable http option. It's not perfect, but there are also good partes and reasons why it's still around. Secure FTP is still a good option for some cases.
- anyfoo 7y ago
  As written in another comment, you will find FTP to actually be a truly horrendous protocol, at least from today's perspective. I'm not sure there is anything that FTP offers, that the rsync or sftp, for example, offer much better (or simply HTTP if it's only in one direction), and then some. SFTP is actually not just FTP over SSH. The protocol is different precisely to get rid of a lot of the outdated nuisances.
  - takeda 7y ago
    FTP became a nightmare to use thanks to introduction of NAT, it was developed before NAT existed so it wasn't designed with it in mind. As for rsync, sftp, scp those are heavily tied to ssh, rsync to the point that you actually ssh to host and call rsync command. rsync has a server mode as well, but almost no one uses it.
  - big_chungus 7y ago
    Yes, there are lots of issues with FTP. I've worked with it, and it is in many ways a nightmare. That aside, you can use FTP for auth and ACL in of which HTTP and rsync just aren't capable. I'm not sure this is a flaw in the core protocol so much as the tooling, but there you have it. FTP config syntax may often be byzantine. But it's widely supported (especially on old, low-spec, or embedded devices). For newer stuff, yeah sftp is probably better. But it's still got its uses.
    - georgebarnett 7y ago
      Completely agree it still has its uses. So does Cobol and any number of older legacy tooling. That’s not the point we are discussing though; This is specifically regarding Chromium supporting FTP.
lazylizard 7y ago
Ftp is fast
- georgebarnett 7y ago
  Genuinely curious. Why do you think a bitstream from an FTP server is faster than from a HTTP server?
  - ZWoz 7y ago
    Whole solution and experience is different, even if some point uploading file by bytes over TCP is similar. HTTP server itself isn't solution. You need code implementing upload functionality, probably support for uploading many files at once and tracking progress. Now you client uses javascript and that client is remote, you need to "download" it from HTTP server. FTP client is small, local and don't have much overhead, HTTP with its stateless form needs headers retransmitted with every request.
    - georgebarnett 7y ago
      That’s all well and good, and has nothing to do with Chromium keeping ftp support.
      - ZWoz 7y ago
        Indeed, but your question wasn't about Chromium ftp support. Note, I am not lazylizard, so I don't really know, what he meant by "Ftp is fast", but I have my own thoughs and general dislike to webify everything on internet.
layoutIfNeeded 7y ago
How would you download a folder of files via HTTP? I don’t want to wait 10 minutes for the server to zip them, thank you.

kadoban 7y ago

Both of those may be true, but does it have anything to do with ftp going away? It's a pretty bad protocol that's rarely used, why should browsers still support it?

systematical 7y ago

Use a proper client like Filezilla for this and go over SFTP, no reason for FTP these days and even less so in a browser.

takeda 7y ago
There is[1], but yeah it doesn't apply in this context. [1] https://en.wikipedia.org/wiki/File_eXchange_Protocol https://en.wikipedia.org/wiki/File_eXchange_Protocol

kart23 7y ago

I saw a 6th grader using filezilla to update his website the other day. 99% of people didnt know what ftp was 10 years ago, that hasn't changed. Every generation loves to trash the one below it, that certainly will never change.

mlyle 7y ago
I think it's a lot harder to become technically competent these days. Before, computers compelled you to have a certain level of technical competence to be a user. Now, the barrier to entry is a lot lower, but there aren't many of the very young learning their way around command lines, etc. The resources once you are on the track to doing technical stuff are far better, but you're less likely to end up on that track-- especially at an early age.
- sophiebits 7y ago
  You used to need a certain amount of technical competence to be literate. Now we teach everyone to read and write! What is the world coming to?
  - mlyle 7y ago
    That's hardly what I said. It's good that computers are more accessible. But by making it easy, we're providing less opportunity for people who are curious about innards at an early age. Of course, now we're teaching computational thinking in schools, but IMO it's a really big open question whether our attempts to teach that work, especially in elementary school.
  - userbinator 7y ago
    It's more like "now we don't have to teach everyone to read and write, we do the (filtered/censored/etc.) communication for them."
- cameronbrown 7y ago
  > Now, the barrier to entry is a lot lower, but there aren't many of the very young learning their way around command lines, etc. I'm a fairly young person. What I've seen over the past few years is technology is finally useful and accessible to everyone. Forcing people to use the command line isn't a useful skill for 99.5% of people anymore, it's just senseless gatekeeping to make it a computer requirement. I got into computers by ripping into Windows XP internals and learning how it worked when I was a kid, no command line needed. There will always be people who are more curious about how things work. Have faith that kids are smart enough to use the internet to learn for themselves. Just because technology is easier does not mean it's harder to learn how to be "technically competent". Remember that the definition of technically competent moves with the times, too.

ahupp 7y ago

Why do you assume this is driven by some desire for "pliant consumers", vs a desire to build a simpler and more secure browser?