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.
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.
Google Plans to Deprecate FTP URL Support in Chrome
181–190 of 350 posts
Re: Google Plans to Deprecate FTP URL Support in Chrome
#182Earlier quoted context omitted.
I would say that the reason is not FTP insecurity or anything else technical. They see no monetization in it as they cant put their ads in it, they cant track you (well this is wrong, they track you with chrome) and nobody is buying adwords for FTP. Why keeping it?
On the contrary. It’s a data only with maybe a motd. plenty of space to put ads. Especially if you’re looking for a driver
FTP in the browser typically looks something like this https://imgur.com/20ooI9f
Plenty of space for ads.
HTTP is basically FTP with ads.
Funny thought. Imagine if, to this day, the internet consisted of pretty much that.
You go to ftp://nytimes.com and it just has a directory structure that consists of yyyy/mm/dd and the file names where things like statement-from-chinese-ambassador-to-australia.txt
And maybe a directory named breaking-news
Imagine if Twitter was a list of text files named yyyy-mm-dd-hh-mm-ss-username.txt
Ha.
Imagine if you had to upload a text file like this
---
Please place an x between the brackets as desired
[ ] Whopper Meal
[ ] Super sized Whopper Meal
[ ] Coke
[ ] Sprite
[ ] Eat-in
[ ] Takeaway
etc
Name on card:
Card number:
Expiry:
Card Security Code:
Sponsored by Nike and the Ford Motor Company
----
Edit: changes 'threat' to 'thread' in first line, typo could have been confusing. Second edit: made list verbatim.Re: Google Plans to Deprecate FTP URL Support in Chrome
#183Isn't it clear to everyone now that HTTP is the new IP and TCP? That all future protocols will subsist on a web tech substrate? Is that such a bad thing? The vocabulary of URLs and cookies is much richer and less centralized than the vocabulary of port numbers and connection tuples. Why should we keep FTP or other legacy non-HTTP protocols around? What are we buying? Slightly lower connection setup byte counts?
HTTP is objectively better then FTP for downloading files. For remote file management and uploading there are other options besides WebDAV (itself a HTTP protocol extension), such as SSH/SFTP. Basically the only case I can think of that needs FTP are people wanting to access a shared-webhost web-space. And FTP works fine for them already, and they aren’t using Chrome to update their site either - so no loss.
If I want to use FTP I will use FTP.
Google should be able to do what they want with their browser, and I may choose to use another browser (already done).
Re: Google Plans to Deprecate FTP URL Support in Chrome
#184Google 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?
Re: Google Plans to Deprecate FTP URL Support in Chrome
#185Earlier quoted context omitted.
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. Se…
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.
Re: Google Plans to Deprecate FTP URL Support in Chrome
#186Considering that Google (search) still lists plenty of FTP results, many of which have been extremely useful to me, this seems like another move to bully the Internet into what Google wants it to be. Will it start removing those results, effectively censoring another huge chunk of the Internet? It's already hard enough to find older/more obscure information, and FTP sites are more likely to be in that category. Also,…
> everyone knows FTP is plaintext You mean no one knows that FTP is plaintext except a minority of users which happens to be on HN. Google is optimizing its browser for the majority, chrome is not a power-user browser. Maybe they'll add an option to enable ftp or something. > drivers, which I'd say are a significant part of FTP use I'm not sure how that's true. Every time I used FTP, it was not for drivers. All the d…
I guess not. More likely there'll be plugin to add this functionality back.
Re: Google Plans to Deprecate FTP URL Support in Chrome
#187Earlier quoted context omitted.
Actually a MitMable channel makes the "it's just cryptographically signed" thing into a heap more trouble. Bad guys can now replay old drivers, which were cryptographically signed, as the latest drivers. So then you need to build cryptographically signed metadata structures, so that you can tell that these were the latest drivers as of some recent moment. You need to have this idea of freshness, and a mechanism to en…
Drivers have versions in them, it's part of the driver itself and therefor cryptographically signed. People like to cargo cult TLS as if it's the only option but it's really not, even debian doesn't use https (and gets quite a bit of backlash despite understanding very well their security model): https://whydoesaptnotusehttps.com/
Re: Google Plans to Deprecate FTP URL Support in Chrome
#188Earlier quoted context omitted.
Actually a MitMable channel makes the "it's just cryptographically signed" thing into a heap more trouble. Bad guys can now replay old drivers, which were cryptographically signed, as the latest drivers. So then you need to build cryptographically signed metadata structures, so that you can tell that these were the latest drivers as of some recent moment. You need to have this idea of freshness, and a mechanism to en…
Drivers have versions in them, it's part of the driver itself and therefor cryptographically signed. People like to cargo cult TLS as if it's the only option but it's really not, even debian doesn't use https (and gets quite a bit of backlash despite understanding very well their security model): https://whydoesaptnotusehttps.com/
Re: Google Plans to Deprecate FTP URL Support in Chrome
#189Earlier quoted context omitted.
On the contrary. It’s a data only with maybe a motd. plenty of space to put ads. Especially if you’re looking for a driver
This is an amusing thread. FTP in the browser typically looks something like this https://imgur.com/20ooI9f Plenty of space for ads. HTTP is basically FTP with ads. Funny thought. Imagine if, to this day, the internet consisted of pretty much that. You go to ftp://nytimes.com and it just has a directory structure that consists of yyyy/mm/dd and the file names where things like statement-from-chinese-ambassador-to-aus…
Nobody would actually bother to download it would they!
Re: Google Plans to Deprecate FTP URL Support in Chrome
#190Earlier quoted context omitted.
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 mo…
> 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.