Google Plans to Deprecate FTP URL Support in Chrome(pulltech.net)
pulltech.net
Google Plans to Deprecate FTP URL Support in Chrome
https://www.pulltech.net/article/1566007822-Google-plans-to-deprecate-FTP-URL-support-in-Chrome
349 コメント
There was a time when www was just a part of the Internet and we had www search and ftp search engines. The one I used to use was called "ftpsearch" and the only thing (besides the name) I remember is that it used to say "This server is located in Trondheim" on the front page. A quick web search turns out that it still seems to exist in some form [1]. Unfortunately it apparently doesn't really work anymore.
Maybe it's time to bring ftp search engines back.
[1] http://www.mi.uni-koeln.de/~jbe/ref/ftpsearch/
Maybe it's time to bring ftp search engines back.
[1] http://www.mi.uni-koeln.de/~jbe/ref/ftpsearch/
I just hope this isn't like how Google basically killed off RSS when they killed off the best client that everyone was using (which I've still never heard a good reason why) which I believe played a role in the decline of everyone having a blog.
And yes I know there's some niche support still, just as FTP will live on.
And yes I know there's some niche support still, just as FTP will live on.
RSS is still alive and well. Podcasting depends on it.
Don't jinx it! Luminary and Apple Podcasts are trying to add exclusive content now.
Podcasts that only work if you buy Apple's hardware? That sounds terrible.
RSS/Atom is alive but not well. It needs more support.
Funny, I use RSS constantly for podcasts and I never made that connection. Good call.
>I believe played a role in the decline of everyone having a blog.
Is that really the case though? Wordpress ( Love it or Hate it ), both .com and self hosted is still thriving.
And if people are writing less blog, I think it has more to do with Social Media ( Facebook ) than RSS or Google Search / Reader.
Is that really the case though? Wordpress ( Love it or Hate it ), both .com and self hosted is still thriving.
And if people are writing less blog, I think it has more to do with Social Media ( Facebook ) than RSS or Google Search / Reader.
Incredible how that happened. I used Google Reader a lot, adding any interesting blogs I would find. Now I can't find any of them again :/ I think I've got a list saved somewhere, but it was just so easy to go through Reader.
I recommend https://bazqux.com/ -- The death of Reader sprung the life of many pre-existing RSS reader replacements.
Where was this when Reader died! Looks great.
The big problem at the time was there was no good options, even a year or so after and I gave up trying. Everything was 90% of the way or too fancy for such a simple service.
The big problem at the time was there was no good options, even a year or so after and I gave up trying. Everything was 90% of the way or too fancy for such a simple service.
I found it in one of the many HN threads where alternatives were being advertised left and right just as Reader's death was being announced ;) theoldreader is another one I remember from back then.
Ah, apparently I didn't try hard enough then.
Looks good, but having to sign in with a third party - yuk.
I use RSS every day, I have 3 stops when I want to check on current events, my RSS Feeds, Reddit, and here...
Please share your favorite RSS client
Bazqux, basically a GoogleReader clone if Google would still develop it. Works really well on mobile as PWA. Not free, but worth 20-30$ sub a year. Not affiliated, but a happy subscriber for 5-6 years. Everybody who still misses GoogleReader should try it.
https://github.com/bazqux/ https://bazqux.com/
https://github.com/bazqux/ https://bazqux.com/
Miniflux for me. There's a paid hosted SaaS option, or you can host it yourself.
https://miniflux.app/
https://miniflux.app/
Right now I am mainly using Feedly.
However I have been wanting to selfhost more so evaluating moving to either FreshRSS or TinyRSS,
However I have been wanting to selfhost more so evaluating moving to either FreshRSS or TinyRSS,
Weirdly after switching between many self hosted options, including Nextcloud News which lasted the longest, I ended up putting rss2email [0] in docker and configured it to SMTP (it can also deposit them onto an IMAP server directly) articles to my address. I then have an inbox rule that puts it all into a folder and another that deletes items after 7 days. If I want to save an article, I just move it into my "Archive" folder.
Why using email? I switch between phones, OSs etc and it was a bitch to find decent clients for the self hosted options on each OS. I can generally get my email everywhere, via ActiveSync on my phone, WebUI, thunderbird etc. And since I host my mail, the data never leaves my network :) It works really well, though I do sometimes feel like RMS having web pages emailed to me lol
[0] https://github.com/wking/rss2email
Why using email? I switch between phones, OSs etc and it was a bitch to find decent clients for the self hosted options on each OS. I can generally get my email everywhere, via ActiveSync on my phone, WebUI, thunderbird etc. And since I host my mail, the data never leaves my network :) It works really well, though I do sometimes feel like RMS having web pages emailed to me lol
[0] https://github.com/wking/rss2email
RSS is not a feed to distribute content (podcasts excepted of course!), it is another way to pull you into the same ad infested ecosystem that still thrives today. Google is indeed killing reading but google reader is such an odd product to place blame on.
Xarchie for me
> 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 drivers I downloaded were over http(s), from constructor websites.
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 drivers I downloaded were over http(s), from constructor websites.
> Google is optimizing its browser for the majority, chrome is not a power-user browser.
That is a problem. We have browser engine duopoly, and really everyone is doing whatever Google wants anyway. So as they're optimizing against power users, they're making the whole web much worse.
That is a problem. We have browser engine duopoly, and really everyone is doing whatever Google wants anyway. So as they're optimizing against power users, they're making the whole web much worse.
Can you please explain to me why you believe optimising against power users is making the internet worse.
I tend to agree with you, but would you mind fleshing this out a bit. Or, if you've written this before please point to it.
I tend to agree with you, but would you mind fleshing this out a bit. Or, if you've written this before please point to it.
I think the term "power users" is not appropriate. I believe we're encountering some kind of "curse of multidimensionality" problem here: every time Google adds a feature, they add one dimension to the space of utility of their product. And every time they remove a feature, they reduce the relative volume of people who still find the product useful. So it's not "power users" in general, but "power users of feature X". There are not the power users who use all the advanced features on one side, and the regular users who use none on the other. The more features you add or cut, the more each of those categories tend to zero. Actual users are somewhere in between, and if you optimize against "power users" you in fact optimize against your users in general.
I'm not TeMPOraL, but to my understanding:
Chrome is a duopoly, and Firefox tends to get forced in the same direction as Chrome over time -- it's not powerful enough to push the web as a whole in a different direction.
If Chrome was not a duopoly, this would not be a problem. There's nothing fundamentally wrong with having a browser that's highly optimized for nontechnical users. However, because Chrome has such control, pushing technical users out of Chrome has the effect of pushing technical users out of the web entirely. By putting itself into a dominant market position, Chrome has put itself in the (unenviable) position of needing to be everything for everyone.
In other words, if Chrome doesn't support power users, and if Firefox doesn't have the guts to refuse to make the changes they advocate for, then power users have no where to go. This is why monopolies and duopolies are bad even if the companies behind them are good. Its completely unrealistic for a single product to be everything for everyone, so single products by their very nature exclude certain users.
----
So who cares if power users abandon the web?
This is a problem because historically, power users have been incredibly important for the web's development. They've been important not just in the sense that they've pushed the web forward technically, but also because the web was designed to be a democratizing medium. The web is designed to be a publishing platform where people can build weird things without asking anyone's permission.
Even non-technical users benefit from this -- it's in their best interest to have lots of providers providing lots of solutions for publishing because (repeating what I said above) no one platform can be everything for everyone. A non-technical web that is optimized for ordinary people to the exclusion of power users is going to be less creative, less interesting, and less useful even for ordinary people.
Whether or not FTP in particular is critical to that -- I don't know. I don't know enough about FTP to make a strong argument on that. I will say I have used FTP a lot as a consumer, especially when downloading packages, and I have used FTP on internal networks. I'm not an expert, but the arguments package maintainers make about why SSL is unimportant to FTP ring true to me. My understanding is that package signing prevents modification attacks, and that looking at request sizes is enough to identify resources even with SSL.
As a policy, deprecating URL types that don't support encryption seems at first glance to be a really dumb move, and I'm not sure the security arguments justify it. But I'm not an expert.
----
I'm on Firefox, and I'm hopeful that Firefox is going to see a resurgence of usage pretty soon, particularly among power users. If Firefox refuses to deprecate FTP, I'm not so worried, since honestly I think it's probably in everyone's best interest for Chrome to do a few dumb things that make more power-users jump ship to Firefox. A lot of power users aren't willing to make the switch on ideological grounds; Chrome as a browser needs to get much, much worse to encourage them to use competitors.
Thankfully, it appears that (especially recently) the Chrome dev team has been thinking the same thing.
Chrome is a duopoly, and Firefox tends to get forced in the same direction as Chrome over time -- it's not powerful enough to push the web as a whole in a different direction.
If Chrome was not a duopoly, this would not be a problem. There's nothing fundamentally wrong with having a browser that's highly optimized for nontechnical users. However, because Chrome has such control, pushing technical users out of Chrome has the effect of pushing technical users out of the web entirely. By putting itself into a dominant market position, Chrome has put itself in the (unenviable) position of needing to be everything for everyone.
In other words, if Chrome doesn't support power users, and if Firefox doesn't have the guts to refuse to make the changes they advocate for, then power users have no where to go. This is why monopolies and duopolies are bad even if the companies behind them are good. Its completely unrealistic for a single product to be everything for everyone, so single products by their very nature exclude certain users.
----
So who cares if power users abandon the web?
This is a problem because historically, power users have been incredibly important for the web's development. They've been important not just in the sense that they've pushed the web forward technically, but also because the web was designed to be a democratizing medium. The web is designed to be a publishing platform where people can build weird things without asking anyone's permission.
Even non-technical users benefit from this -- it's in their best interest to have lots of providers providing lots of solutions for publishing because (repeating what I said above) no one platform can be everything for everyone. A non-technical web that is optimized for ordinary people to the exclusion of power users is going to be less creative, less interesting, and less useful even for ordinary people.
Whether or not FTP in particular is critical to that -- I don't know. I don't know enough about FTP to make a strong argument on that. I will say I have used FTP a lot as a consumer, especially when downloading packages, and I have used FTP on internal networks. I'm not an expert, but the arguments package maintainers make about why SSL is unimportant to FTP ring true to me. My understanding is that package signing prevents modification attacks, and that looking at request sizes is enough to identify resources even with SSL.
As a policy, deprecating URL types that don't support encryption seems at first glance to be a really dumb move, and I'm not sure the security arguments justify it. But I'm not an expert.
----
I'm on Firefox, and I'm hopeful that Firefox is going to see a resurgence of usage pretty soon, particularly among power users. If Firefox refuses to deprecate FTP, I'm not so worried, since honestly I think it's probably in everyone's best interest for Chrome to do a few dumb things that make more power-users jump ship to Firefox. A lot of power users aren't willing to make the switch on ideological grounds; Chrome as a browser needs to get much, much worse to encourage them to use competitors.
Thankfully, it appears that (especially recently) the Chrome dev team has been thinking the same thing.
I wanted to but I'm AFK for most of today. I'll try to comment some more later today, and I'll likely blog on this in the future.
EDIT: 'danShumway and 'ajnin together essentially summarized my thinking here.
Web is built and maintained by technically proficient people so it needs them to be comfortable. There is no unified group of "power users"; everyone doing something regularly becomes a "power user" in that context to the extent they are able to. If you remove their ability to grow, you're condemning them to wasting their time and reducing utility of the web for them.
EDIT: 'danShumway and 'ajnin together essentially summarized my thinking here.
Web is built and maintained by technically proficient people so it needs them to be comfortable. There is no unified group of "power users"; everyone doing something regularly becomes a "power user" in that context to the extent they are able to. If you remove their ability to grow, you're condemning them to wasting their time and reducing utility of the web for them.
Its a strange thing how co-incident "optimizing for the majority" is with "killing open standards" and "Google specific features"
A real strange thing...
Not to worry though, I'm sure Google is just doing it for everyone's best interests, like the charitable organization for humanity that they are.
A real strange thing...
Not to worry though, I'm sure Google is just doing it for everyone's best interests, like the charitable organization for humanity that they are.
This is silly.
FTP is an awful protocol and there are other perfectly fungible open standard replacements for it, like HTTP/HTTPS. FTP dates from the era before NAT and firewalls and makes a bunch of problematic design choices, like having the server establish a separate port connection to the client (or vice versa, for passive mode) to transfer the file. It's super chatty, requiring multiple waits for response, and therefore slow. There's no length check, so if your socket gets closed you silently save a half-finished file.
FTP should just die off.
FTP is an awful protocol and there are other perfectly fungible open standard replacements for it, like HTTP/HTTPS. FTP dates from the era before NAT and firewalls and makes a bunch of problematic design choices, like having the server establish a separate port connection to the client (or vice versa, for passive mode) to transfer the file. It's super chatty, requiring multiple waits for response, and therefore slow. There's no length check, so if your socket gets closed you silently save a half-finished file.
FTP should just die off.
> Google is optimizing its browser for the majority, chrome is not a power-user browser.
Yet they are positioning it as the only browser
Yet they are positioning it as the only browser
This'll happen when the major ideology held by most people is competition.
One wouldn't expect Google to say "We recommend you use our browser, Google Chrome, but there's also these others that work fine to."
It's probably the case that back when the number of internet users was smaller the place had a more community oriented vibe, whereas now there is huge sums of money and power at stake.
One wouldn't expect Google to say "We recommend you use our browser, Google Chrome, but there's also these others that work fine to."
It's probably the case that back when the number of internet users was smaller the place had a more community oriented vibe, whereas now there is huge sums of money and power at stake.
I wouldn’t expect Google to say ‘here’s our web app, it doesn’t work properly in any browser expect Chrome’. But they do.
> Google is optimizing its browser for the majority, chrome is not a power-user browser.
Well, I think there is enough people like us, where a proper 'power-user' browser is worth maintaining. Any takers?
Well, I think there is enough people like us, where a proper 'power-user' browser is worth maintaining. Any takers?
> Maybe they'll add an option to enable ftp or something.
I guess not. More likely there'll be plugin to add this functionality back.
I guess not. More likely there'll be plugin to add this functionality back.
Chrome addons are not capable of doing FTP.
Really? Given there are a chrome apps capable of doing ssh[0], I'd be very surprised if FTP is not implementable.
[0]: https://chrome.google.com/webstore/detail/iodihamcpbpeioajje...
[0]: https://chrome.google.com/webstore/detail/iodihamcpbpeioajje...
That uses NaCl, so while what I said is not accurate, NaCl appears to have no future.
https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...
https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...
It uses NaCl but that's not necessary; it just needs the chrome.socket API, which allows arbitrary TCP and UDP services to be built. There is no reason one couldn't implement FTP or SSH with it in JS.
https://developer.chrome.com/apps/socket
https://developer.chrome.com/apps/socket
Indeed; by the same "security" logic, why not get rid of HTTP too then? (Or SMTP, for that matter?)
The point of "organize the world's information and make it universally accessible and useful" is to do precisely that: to organize the world's information and make it universally accessible and useful -- long tails included. But I guess for them it's not...
(Also, I can't believe the Chrome team is so strapped it can't afford to support or harden the feature, as some in the bug tracker suggest [1]. This is Google we are talking about, not some tiny open source project!)
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=333943
The point of "organize the world's information and make it universally accessible and useful" is to do precisely that: to organize the world's information and make it universally accessible and useful -- long tails included. But I guess for them it's not...
(Also, I can't believe the Chrome team is so strapped it can't afford to support or harden the feature, as some in the bug tracker suggest [1]. This is Google we are talking about, not some tiny open source project!)
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=333943
If I imagine I'm in a position as a developer / project manager / whatever working for Google trying to advocate Google committing resources to the FTP protocol in Google Chrome, I'm struggling to think of a way of promoting it that shows it will have a return on investment.
How do you display ads while someone is accessing an FTP server?
ftp://example.com/directory/file.extension can be a link in a website, where the website displays ads.
I'm just imagining some people having a conversation that goes something like this:
"The funding for this feature has been removed because we can't serve ads on a page like this https://imgur.com/20ooI9f "
Edit: grammar
How do you display ads while someone is accessing an FTP server?
ftp://example.com/directory/file.extension can be a link in a website, where the website displays ads.
I'm just imagining some people having a conversation that goes something like this:
"The funding for this feature has been removed because we can't serve ads on a page like this https://imgur.com/20ooI9f "
Edit: grammar
Chrome, being a browser made by an advertising company, could show ads on ftp directory listings.
In that sense, it's somewhat strange that Chrome isn't already presenting us with ads in the tab-/addressbar and the menu. Perhaps some pop-ups from the bottom and sides as well while they are at it? The original free/shareware version of Opera had that too, and it wasn't that intrusive.
I thought you were joking for a minute and then sadly realized you weren’t.
Mozilla certainly would like that new influx of users. I think user retention is one of Googles most immediate issues.
> Indeed; by the same "security" logic, why not get rid of HTTP too then? (Or SMTP, for that matter?)
I believe those will happen, in the long run.
The next HTTP spec includes mandatory SSL, and Google had a hand in designing QUIC, and Google has been deprecating traditional SMTP authorisation.
I believe those will happen, in the long run.
The next HTTP spec includes mandatory SSL, and Google had a hand in designing QUIC, and Google has been deprecating traditional SMTP authorisation.
They don't have resources to fix cross-origin network request debugging either. It's quite sad.
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
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-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
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
----
> Funny thought. Imagine if, to this day, the internet consisted of pretty much that.
That's pretty much Gopher. Another protocol that Chrome no longer supports.
That's pretty much Gopher. Another protocol that Chrome no longer supports.
You could write native apps on top of your proposed directory layouts, and it would be better than whatever people do today.
You’ve just described e-commerce circa 1990!
On Usenet newsgroups and BBS conferences, sellers would post forms that looked exactly like that, except for the ads of course. Buyers would then send in their completed order form via either email/netmail or, preferably, via fax for added security.
I remember always choosing to fax in my orders; even way back then, sharing credit card details via email seemed like a very bad idea.
On Usenet newsgroups and BBS conferences, sellers would post forms that looked exactly like that, except for the ads of course. Buyers would then send in their completed order form via either email/netmail or, preferably, via fax for added security.
I remember always choosing to fax in my orders; even way back then, sharing credit card details via email seemed like a very bad idea.
> Imagine if you had to upload a text file like this
I would love this. This has better UX than the food ordering sites we have to deal with in the real world.
I would love this. This has better UX than the food ordering sites we have to deal with in the real world.
Yes but if one of those files was
ADSENSE-one-wierd-trick.jpg
Nobody would actually bother to download it would they!
Nobody would actually bother to download it would they!
>Imagine if you had to upload a text file like this
Sounds like a total improvement over websites I have suffered... not to mention allows all kinds of third parties to create their own fancier ordering systems on top!
Sounds like a total improvement over websites I have suffered... not to mention allows all kinds of third parties to create their own fancier ordering systems on top!
FTP support is still a big attack surface for the client that has to be managed, regardless of wire security.
But my gut reaction to reading this concern is actually: why do you think this is “bullying” and not “opening the door for a niche competitor”?
But my gut reaction to reading this concern is actually: why do you think this is “bullying” and not “opening the door for a niche competitor”?
Because a 'niche competitor' is not really a competitor and would be invisible to almost everyone. And because sich a competitor would require extra work to use, so it would be unpopular.
What big attack surface? The client? FTP is an ugly/stupid protocol, but it's not really complex (I suspect it's far simpler than HTTP).
FTP has some pretty serious quirks. Active-mode FTP is probably the craziest one by modern standards -- the client opens a port and asks the server to connect to it to send a file. Needless to say, this is effectively unusable on the modern Internet. Its replacement, passive-mode FTP, has the server open a port instead; this configuration is merely incompatible with most load balancers.
Active ftp is dead. I wouldn't be surprised if browsers don't support it out at least don't default to it since as you said it would break things for 99% of users. Running a server that's not configured properly for passive transfers is effectively a server that's useless. So if it would make someone sleep better at night I'd be fine with removing active transfer support from browser clients. Switch to filezilla if you're a power user or want to do some 1337 FXP tricks.
It's not much different than old versions of TLS.
In ftp, the ftp server is designed to act as the load balancer. (Just have the firewall point each port to a different IP.)
Also, this enables linear scale out, since not all ftp data nodes (not sure what the correct term was) need to store all of the data that’s being served, and you can store multiple copies of each file.
Come to think of it, I’m not sure why HDFS exists, given that you can just use a ftp server cluster for the same effect.
Also, this enables linear scale out, since not all ftp data nodes (not sure what the correct term was) need to store all of the data that’s being served, and you can store multiple copies of each file.
Come to think of it, I’m not sure why HDFS exists, given that you can just use a ftp server cluster for the same effect.
Oh, absolutely! I said it was ugly/stupid from personal experience:) But it's a form of stupid that can be condensed into a single state diagram that would fit on half a sheet of paper, so I'm not super concerned about it.
I'm surprised the article claims there are still bugs, because one would think (hope) that a protocol over 30 years old with an implementation over a decade old should've received its last bugfix long ago and become truly stable by now.
What? Like OpenSSL:
https://en.wikipedia.org/wiki/Heartbleed
(I mean, I'm not overjoyed at the deprecation of FTP support because I used it just yesterday, but let's at least be honest here. The protocol might be decades old but the implementations aren't necessarily, and if they're being actively maintained there's always the possibility of introducing new bugs.)
https://en.wikipedia.org/wiki/Heartbleed
(I mean, I'm not overjoyed at the deprecation of FTP support because I used it just yesterday, but let's at least be honest here. The protocol might be decades old but the implementations aren't necessarily, and if they're being actively maintained there's always the possibility of introducing new bugs.)
It was introduced into the software in 2012
That's not the "stable protocol that's been around for decades" situation that FTP is in.
That's not the "stable protocol that's been around for decades" situation that FTP is in.
> That's not the "stable protocol that's been around for decades" situation that FTP is in.
That is literally the point I was making when I said, "if they're being actively maintained there's always the possibility of introducing new bugs."
Moreover, just because a library had its last fix a decade (or whatever) ago is no guarantee that unfixed bugs do not lie undiscovered in it.
That is literally the point I was making when I said, "if they're being actively maintained there's always the possibility of introducing new bugs."
Moreover, just because a library had its last fix a decade (or whatever) ago is no guarantee that unfixed bugs do not lie undiscovered in it.
The protocol is buggy AF. All that crap about sending data over a separate TCP connection, the weird way you have to deal with state and authentication; ftp is an utter shitshow. Just because a protocol is old doesn't mean it's matured to perfection. Telnet is old, so is RCS, and UUCP.
Many protocols evolve not by being replaced by incrementally better point releases, but rather by being supplanted entirely by a better designed alternative.
FTP effectively evolved into HTTP for this use case, and scp/sftp for the authenticated file transfer use case.
Many protocols evolve not by being replaced by incrementally better point releases, but rather by being supplanted entirely by a better designed alternative.
FTP effectively evolved into HTTP for this use case, and scp/sftp for the authenticated file transfer use case.
Can you give an example of a piece of software of reasonable complexity (network/file handling, etc) that has solidified like this?
Everything in the openbsd base image.
qmail
Sqlite
The other ones I might give a pass to as I can't find where the update history lives, but this is untrue - https://www.sqlite.org/changes.html
Are you referring to this bit:
and there are other bugs in the implementation which further demotivates the FTP support.
To me that reads as there are bugs in Chrome's implementation of FTP.
Did you take that to mean the author intended to convey the message that the FTP protocol has bugs?
and there are other bugs in the implementation which further demotivates the FTP support.
To me that reads as there are bugs in Chrome's implementation of FTP.
Did you take that to mean the author intended to convey the message that the FTP protocol has bugs?
FTP can be implemented in such away that it exposes no more potential for attack than html/http.
I’m really unhappy with Chromes roadmap as of late. Particularly their effort to kill the URL. At one point Chrome was the gold standard and I think it’s gotten to their head.
I never considered Chrome the gold standard. They advanced the state of the art with their sandbox model and their performance advantage, but they are losing the advantage in the former and lost it in the latter. It was always painfully obvious (to me) that it's an extremely bad idea to trust an ad megacorporation with building a browser.
> this seems like another move to bully the Internet into what Google wants it to be
Bully them back. Don't use Google search and don't use Chrome.
Bully them back. Don't use Google search and don't use Chrome.
Easier said than done, especially when most of the population doesn't care either because they're too young or too nontechnical; actually, I already don't use Chrome, but their search (which still shows FTP sites...) is, despite slowly getting worse too, still giving a wider breadth of sites most of the time. Bing and DDG help fill in the gaps.
Try switching to ddg and append !g every time the results seem to suck. That's how I did it and after about a month it was just fine. In fact over time I felt like I did the !g thing less and less, because you somehow get a feel for when ddg actually sucks or not. Or maybe I unconsciously started formulating queries differently.
But if you really think it would be right to switch away from Google, give yourself a month of pain and then decide if you can live this new life. ;-)
But if you really think it would be right to switch away from Google, give yourself a month of pain and then decide if you can live this new life. ;-)
IE was superseeded by Firefox in the early 00's at scale, and there's no reason to assume Chrome can't equally be replaced by FF or another browser today. FF got a little help from the EU by requiring MS not to bundle IE with Windows back then and list browser choices for download on install; I think the same would work well on Android today (and in general with Google services such as maps/navigation, email, and search).
We'll hit a tipping point soon enough and Google will either die or have to adapt.
I personally hope they continue exhibiting monopolistic behaviour. Same with Cloudflare and other company's who choose business models that are hostile to an open and decentralized Internet.
I personally hope they continue exhibiting monopolistic behaviour. Same with Cloudflare and other company's who choose business models that are hostile to an open and decentralized Internet.
startpage.com gives me better results than Google itself, because of the missing personalization bubble.
Really? I find that their cache of Google results is very old on average, so new sites don’t appear for a very long time compared to Google. DDG seems to be better than Startpage on that front, but a Google takes the cake in result recency. Even my not-horribly-popular web site is indexed by Google within ten minutes of me publishing anything.
I switched my default search engine in FF to Qwant a few months back. You have to re-learn to formulate clear search queries (no magic pixie dust^H years of browsing history to help it read your mind) but I find that it mostly works.
> Easier said than done
It's real easy to do. It is not the case that you are dependent on Google search. You're imposing artificial limits on yourself. Break free of this limiting mindset.
It's real easy to do. It is not the case that you are dependent on Google search. You're imposing artificial limits on yourself. Break free of this limiting mindset.
What do you mean? It's very easy to install an FTP client and even in heyday, noone sane ever used a browser for FTP access anyway.
These kind of comments are so strange... why do you want Google to own your FTP client instead of having an independent one?
These kind of comments are so strange... why do you want Google to own your FTP client instead of having an independent one?
The drive towards "HTTPS everything" has merely caused users to forget what it is and therefore simply trust Google. Needless to say, this is exactly what they would want.
thrwyway9448(1)
There are 100,000s of resources on publicly accessible FTP servers and the removal of direct access to these files via one of the worlds most used browsers is major blow for information storage and retrieval on the internet.
It is obvious that the next FTP related headline we see from Google is when (not, if) they drop FTP links from all Google search results. There's no point them listing FTP urls in the results if their own browser can't connect to them.
(I don't understand why they can't just keep FTP support in, but with a security dialog that warns users the connection and data will be non-encrypted)
So much is going to be lost when this happens, it's really sad. All because Google want to recreate the internet as the Googlenet, with HTTPS URLs only, most of which link to their own walled garden servers (AMP etc.)
The internet started off as a wonderful limitless information sharing platform, now it's just a shopping mall controlled by corporates. The worse thing is... the general public just don't care.
It is obvious that the next FTP related headline we see from Google is when (not, if) they drop FTP links from all Google search results. There's no point them listing FTP urls in the results if their own browser can't connect to them.
(I don't understand why they can't just keep FTP support in, but with a security dialog that warns users the connection and data will be non-encrypted)
So much is going to be lost when this happens, it's really sad. All because Google want to recreate the internet as the Googlenet, with HTTPS URLs only, most of which link to their own walled garden servers (AMP etc.)
The internet started off as a wonderful limitless information sharing platform, now it's just a shopping mall controlled by corporates. The worse thing is... the general public just don't care.
Its not just Chrome, Firefox is planning to deprecate it as well (https://www.bleepingcomputer.com/news/google/chrome-and-fire...). Relevant Bugzilla ticket (http://bugzilla.mozilla.org/show_bug.cgi?id=85464)
Whaaat? They came for the RSS feeds and I said nothing...
Bugzilla.mozilla.org is offline, here's a mirror: https://web.archive.org/web/20190520010425/http://bugzilla.m...
and relevant quotes posted there (a year ago!): "I think we should mark this bug as WONTFIX. We have a vague plans of deprecating FTP completely in Firefox, there is no point in adding more code in this area." "Since we (sooner or later) would like to deprecate FTP completely, we should not add more code in that area to our codebase."
Bugzilla.mozilla.org is offline, here's a mirror: https://web.archive.org/web/20190520010425/http://bugzilla.m...
and relevant quotes posted there (a year ago!): "I think we should mark this bug as WONTFIX. We have a vague plans of deprecating FTP completely in Firefox, there is no point in adding more code in this area." "Since we (sooner or later) would like to deprecate FTP completely, we should not add more code in that area to our codebase."
Not Surprising given Mozilla Stance to duplicate and support everything Google does in a effort to chase relevancy again
Mozilla has lost the ability to be an independent protector of the Open Web
Mozilla has lost the ability to be an independent protector of the Open Web
It's sad because they don't need to. Quantum is great, and you can remap your keybinds and use MaterialFox to get (almost) the exact same experience. Of course your average pleb won't go through this effort, but people need to know how good Firefox has gotten.
And to the people who disagree: Firefox has always been great, but it often came with a lot of bugs and inconveniences. It didn't use to be as accessible.
https://github.com/muckSponge/MaterialFox
And to the people who disagree: Firefox has always been great, but it often came with a lot of bugs and inconveniences. It didn't use to be as accessible.
https://github.com/muckSponge/MaterialFox
> Quantum is great, and you can remap your keybinds
Please explain how. Since firefox 57 (quantum), there's precisely no way to do that properly...
Please explain how. Since firefox 57 (quantum), there's precisely no way to do that properly...
Have they fixed the issue with excessive resource consumption when using Firefox on a Retina MacBook?
+1
I tried to switch to FF on multiple occasions, but it's a CPU hog on MacBook. Why is this issue ignored for so long?
I tried to switch to FF on multiple occasions, but it's a CPU hog on MacBook. Why is this issue ignored for so long?
"Resource consumption" in the parent comment refers to power efficiency, specifically GPU blits. That issue has not been ignored. I don't know what "CPU hog" refers to; the issue is not about CPU usage.
It's consuming ~20% CPU in idle on my machine (MacBook Pro Retina, 13-inch, Early 2015, 2.7 GHz Intel Core i5, 8 GB 1867 MHz DDR3, macOS Mojave 10.14.6)
Based on what I saw the last time I checked Mozilla's bug tracker, the issue has a low priority and no one is actively working to resolve it.
From what I understand, it's a low level rendering issue.
From what I understand, it's a low level rendering issue.
That's not true. There was a roadmap posted yesterday and patches to begin to address the issue landed this week, including a new preference to opt into Core Animation. This is Markus' top priority at present. https://bugzilla.mozilla.org/show_bug.cgi?id=1429522
Source: I wrote the initial version of those patches, though I think Markus has basically rewritten them all at this point.
Source: I wrote the initial version of those patches, though I think Markus has basically rewritten them all at this point.
My mistake, I hadn't checked on the status in nearly a year. Glad to hear that progress is being made. Thanks for the update and patches!
By following Chrome every time Google wants to removes access to parts of the web not sufficiently encrypted (to thwart ISP competition for ads and data) or not serving ads (like FTP) Firefox is working to keep Chrome relevant.
It has been going on for years.
It has been going on for years.
Nah. Average consumers almost never touch ftp anymore. I'm a tech pro and even I haven't used ftp in years. Having ftp servers accessible from a browser is a fairly useless luxury at this point. Dedicated ftp clients are very easy to come by for anyone.
I'm a tech pro too and I need it to pull down large FCC and census datasets, but I'm not too concerned about it being removed from the browser. Anyone who still is utilizing FTP is probably savvy enough to install a better tool that's feature-rich like Filezilla.
Do dedicated ftp clients include crawling and indexing?
Neither does the browser. The search engine does that. What should happen here is the search engine still crawls and indexes resources accessible by ftp, and the ftp:// url gets passed to the operating system to launch an appropriate native program. This happens for protocols like magnet:// and discord:// .
Whether Google's search engine will continue to do so for ftp:// resources once Google's web browser no longer handles them remains to be seen.
Whether Google's search engine will continue to do so for ftp:// resources once Google's web browser no longer handles them remains to be seen.
Worth noting here, if you open an FTP url in Safari on Mac, it will open the Finder and connect to the server there.
Since we’re talking about utilities built into the OS, I’ve never had a problem with this.
Since we’re talking about utilities built into the OS, I’ve never had a problem with this.
Yeah, they won't, which is the point. Magnet links are not in Google results either. So having the browser support the protocol is pretty important in this case.
I don't think I've ever come across a web search that led directly back to a ftp site. How much do they actually currently index ftp anyway?
> I'm a tech pro and even I haven't used ftp in years.
That's why you haven't. Ask regular non-tech people doing office jobs in non-tech companies. Some FTP use will show up. Random example I've seen recently: a sports clothing vendor giving seasonal copy bundles for marketing posters to its partners via a password-protected FTP server.
That's why you haven't. Ask regular non-tech people doing office jobs in non-tech companies. Some FTP use will show up. Random example I've seen recently: a sports clothing vendor giving seasonal copy bundles for marketing posters to its partners via a password-protected FTP server.
Time to bust out FileZilla again!
> There are 100,000s of resources [...] major blow for information storage
Thats a very small fraction of all the resources.
> It is obvious that the next FTP related headline we see from Google is when (not, if) they drop FTP links from all Google search results. There's no point them listing FTP urls in the results if their own browser can't connect to them.
This is a worthy concern, for sure. Although how do you know they haven't already done this? Do you have a search that shows ftp: urls?
> The internet started off as a wonderful limitless information sharing platform, now it's just a shopping mall controlled by corporates.
I'm trying to think of the period when the internet wasn't driven by corporate interests. Before the dot com boom, I suppose? When newsgroups thrived, and email servers roamed free without spam? That was fun but theres a fuckton more information on the internet now.
Thats a very small fraction of all the resources.
> It is obvious that the next FTP related headline we see from Google is when (not, if) they drop FTP links from all Google search results. There's no point them listing FTP urls in the results if their own browser can't connect to them.
This is a worthy concern, for sure. Although how do you know they haven't already done this? Do you have a search that shows ftp: urls?
> The internet started off as a wonderful limitless information sharing platform, now it's just a shopping mall controlled by corporates.
I'm trying to think of the period when the internet wasn't driven by corporate interests. Before the dot com boom, I suppose? When newsgroups thrived, and email servers roamed free without spam? That was fun but theres a fuckton more information on the internet now.
> Do you have a search that shows ftp: urls?
Sure, searching for "rfc 1337 inurl:ftp" returns FTP urls for the top four results for me.
Sure, searching for "rfc 1337 inurl:ftp" returns FTP urls for the top four results for me.
Thanks
I wonder if any FTP was spoken by the spider to discover those resources, or whether those are just opaque FTP links discovered embedded in HTTP resources, that were not crawled further.
They're crawled, and the full content is indexed. (You can see a text snippet, and some of the results aren't actually RFC 1337 but other RFCs referring to it).
Yes, google has a cache of some FTP links, as found by GPs query.
http://webcache.googleusercontent.com/search?q=cache:TaTfcCq...
http://webcache.googleusercontent.com/search?q=cache:TaTfcCq...
True. They're very much the new Microsoft and Chrome is the new IE. But the general public also doesn't know what it used to be like. I logged in just to up vote you. I wish we had functioning anti-trust laws.
the US govt has google on points one and two currently. this has been building since the last round of FTC comments: https://drive.google.com/file/d/1GK8YUqQUHYqfmulKuDUwhYG2_GS... although many including google are evading. they dont care for some reason: https://cicilline.house.gov/press-release/cicilline-criticiz...
> It is obvious that the next FTP related headline we see from Google is when (not, if) they drop FTP links from all Google search results. There's no point them listing FTP urls in the results if their own browser can't connect to them.
Why would it? Seems like the relevant model is file types the browser can't open, and there are lots of search results for those?
https://support.google.com/webmasters/answer/35287?hl=en
Lots of worry in this thread from people who apparently don't use ftp enough to know that your OS will already open ftp links for you.
It's also a shame that the actual technical discussions are like half a page down.
Why would it? Seems like the relevant model is file types the browser can't open, and there are lots of search results for those?
https://support.google.com/webmasters/answer/35287?hl=en
Lots of worry in this thread from people who apparently don't use ftp enough to know that your OS will already open ftp links for you.
It's also a shame that the actual technical discussions are like half a page down.
You're mixing up file types and protocols. No, my OS won't open ftp links for me.
> mixing up file types and protocols
"relevant model"
> my OS won't open ftp links for me.
What OS? Because I bet you it does.
"relevant model"
> my OS won't open ftp links for me.
What OS? Because I bet you it does.
It reminds me of when they bought the deja archive and wrecked usenet, mixing it up with google groups
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.
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.
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.
> I'm of the mindset that code written 20 years ago should run today.
I'm of the mindset that it should be possible to rub code written 20 years ago, but not always the same way you run code written more recently. Emulation, virtual machines etc all allow access to old work without hobbling future development with backwards compatibility concerns (see: Windows).
In this case, there are plenty of free and open source options for FTP clients. No one is going to have the world closed off to them as a result of this.
I'm of the mindset that it should be possible to rub code written 20 years ago, but not always the same way you run code written more recently. Emulation, virtual machines etc all allow access to old work without hobbling future development with backwards compatibility concerns (see: Windows).
In this case, there are plenty of free and open source options for FTP clients. No one is going to have the world closed off to them as a result of this.
A large number of academic labs share data by hosting it over FTP. You can harp on about better methods or whatever but these people do not care and don't have time/energy to start caring.
Can’t Chrome just hand the ftp:// link over to a dedicated client?
Sure Chrome can. However this reduces accessibility. What if someone has never heard of FTP? Learning about it and installing an FTP client is a large barrier compared to starting a download. Reducing accessibility is a breaking change IMO.
The same argument could be used for not showing PDF files in the browser.
IMO, browsers need to concern themselves with HTTP. Anything else gets handed off to an application that's designed for it.
IMO, browsers need to concern themselves with HTTP. Anything else gets handed off to an application that's designed for it.
They can also just not upgrade their browser, then. If they don't have the time/energy they're probably still on IE anyway.
> They can also just not upgrade their browser, then
This is a very silly response.
New versions are released with security fixes, not just new features.
This is a very silly response.
New versions are released with security fixes, not just new features.
They wouldn't be using FTP is they care about security.
I don't get why there is so much resistance. It's an old, outdated technology that has to be replaced eventually. Yes, change is always painful. But this isn't like with RSS were the tech provided clear benefits we would loose.
I don't get why there is so much resistance. It's an old, outdated technology that has to be replaced eventually. Yes, change is always painful. But this isn't like with RSS were the tech provided clear benefits we would loose.
> They wouldn't be using FTP is they care about security.
????
Using FTP doesn't put your computer at increased risk of being hacked.
Not updating your browser _DOES_ put your computer at increased risk of being hacked.
????
Using FTP doesn't put your computer at increased risk of being hacked.
Not updating your browser _DOES_ put your computer at increased risk of being hacked.
FTP is not a secure protocol. That's why SFTP was made, even though it isn't really anything like FTP.
In any case, integrating FTP in your browser absolutely increases your chances of an exploit, though. When was the last time the FTP code was tested? Or worked on at all? I suspect it will have been a very long time.
In any case, integrating FTP in your browser absolutely increases your chances of an exploit, though. When was the last time the FTP code was tested? Or worked on at all? I suspect it will have been a very long time.
> They can also just not upgrade their browser, then.
Even aside from everything else, Chrome auto-updates and it’s very difficult to disable.
Even aside from everything else, Chrome auto-updates and it’s very difficult to disable.
Brb, forgot to rub my code today.
>I'm of the mindset that code written 20 years ago should run today.
Given that chrome didn't exist 20 years ago, this seems like a fairly absurd position to apply to this situation. No code from 20 years ago relies on chrome having ftp support.
Given that chrome didn't exist 20 years ago, this seems like a fairly absurd position to apply to this situation. No code from 20 years ago relies on chrome having ftp support.
The number 20 is probably an upper bound.
Web browsers existed 20 years ago. We should be able to visit and use a website written in 1999 on any modern browser.
and you can. but an FTP dump is not a website, and a browser not having native support for non-http protocols does not break websites.
FTP links will still work, they just won't be displayed in a browser anymore. People are blowing this way out of proportion, as if FTP is some critical underpinning of the web or web browsers are a critical part of FTP. Web browsers have always been terrible FTP clients, anybody who uses FTP on a regular basis uses a better client. The most tangible impact of this change is to give grumpy internet commenters something to complain about.
FTP links will still work, they just won't be displayed in a browser anymore. People are blowing this way out of proportion, as if FTP is some critical underpinning of the web or web browsers are a critical part of FTP. Web browsers have always been terrible FTP clients, anybody who uses FTP on a regular basis uses a better client. The most tangible impact of this change is to give grumpy internet commenters something to complain about.
Chrome didn't exist 20 years ago, but you can trace its lineage back that far. Khtml dates back to 1998 apparently.
Frankly, I take the opposite view. Code that is not supported from a developer standpoint should be deprecated. If an organization doesn't want to spend the resources to support part of a code base, I support excising that part of the code base from the product. Especially in open source, others are free to fork.
Google Chrome is proprietary. Chromium is open source. You cant just directly fork Google Chrome itself. However, Chromiums development goals are hijacked by Google Chromes motives. Embrace, Extend, Extinguish.
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.
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.
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.
FTP in PASV mode operates very similarly to HTTP, and is no more insecure. With an organization the size of Google and the Chrome team, they should be able to make it work.
Honest question: Has anyone not used FTP in PASV mode in the last 20 years over the internet?
I think it's pretty much a given since most clients change to PASV mode as a first step. And it's rare that people have a port open to them (behind all firewalls, etc)
I think it's pretty much a given since most clients change to PASV mode as a first step. And it's rare that people have a port open to them (behind all firewalls, etc)
Not all servers work with passive mode. For active, the onus on keeping it working is on me -- and that's easy, it's a trivial bit of firewall config. (conntrack_ftp)
The same was said of Gopher. When Mozilla dropped support for the protocol in Firefox 4.0, there was a brief outcry, followed by silence as everyone realized that the protocol had been effectively unused for decades already.
Except ftp is alive.
>The same could have been said of Gopher.
I don't think Chrome ever supported Gopher, but if some other browser removed something that worked fine before I wouldn't like it either.
I don't think Chrome ever supported Gopher, but if some other browser removed something that worked fine before I wouldn't like it either.
Firefox did remove its support for it, but the support could easily be added back with an extension.
I am more worried about the very realistic that that Google would be dropping FTP from search results, seeing as how their users won't be able to open them in the Google browser.
I am more worried about the very realistic that that Google would be dropping FTP from search results, seeing as how their users won't be able to open them in the Google browser.
> I'm of the mindset that code written 20 years ago should run today
I believe otherwise. Let the old die, so we can alleviate ourselves to create something more suitable to our times.
I believe otherwise. Let the old die, so we can alleviate ourselves to create something more suitable to our times.
You are considering only one aspect of a complex decision they have made. It costs real people-hours to maintain any software. Is it the best use of the time of some very capable people? Like, they might develop some software instead that will save your life a year from now. Then you would think differently.
We should stop telling others what they SHOULD do. (Crap I just did.) Anyways, why not contact Google and offer them to pay the costs of maintaining every piece of software they ever decide to deprecate? Or just go on and build a better browser if you can.
We should stop telling others what they SHOULD do. (Crap I just did.) Anyways, why not contact Google and offer them to pay the costs of maintaining every piece of software they ever decide to deprecate? Or just go on and build a better browser if you can.
>I'm of the mindset that code written 20 years ago should run today.
So you would have cp/m, MS-DOS, PDP-11 RSX-11M, Coherent, Vax VMS, old broken compilers for dead languages, IBM 360 TOS (yes, tape operating system), IBM 360 DOS, Sigma 5 Real-Time-Batch monitor, autocoder, 1401 software, Palm OS?
But for the love of all that is Balloons and Seashells, why?
More to the point--did Chrome have FTP 20 years ago? No, it did not.
In my opinion, they should have never put it there in the first place.
So you would have cp/m, MS-DOS, PDP-11 RSX-11M, Coherent, Vax VMS, old broken compilers for dead languages, IBM 360 TOS (yes, tape operating system), IBM 360 DOS, Sigma 5 Real-Time-Batch monitor, autocoder, 1401 software, Palm OS?
But for the love of all that is Balloons and Seashells, why?
More to the point--did Chrome have FTP 20 years ago? No, it did not.
In my opinion, they should have never put it there in the first place.
> Many well maintained webpages will have to expend resources to migrate off ftp
Really, though? Are there any examples of any web pages that are strictly available from FTP instead of HTTP? If so, why? Isn’t HTTP made specifically for the purpose of transporting hypertext? Why use another, more general protocol when you can use the one made specifically for your use case?
I’m sure there’s good stuff on FTP still. I really, really doubt people are throwing SPAs and PWAs on FTP servers though.
Really, though? Are there any examples of any web pages that are strictly available from FTP instead of HTTP? If so, why? Isn’t HTTP made specifically for the purpose of transporting hypertext? Why use another, more general protocol when you can use the one made specifically for your use case?
I’m sure there’s good stuff on FTP still. I really, really doubt people are throwing SPAs and PWAs on FTP servers though.
I scrape municipal data sources of food and building code violations for a side project, much of the data is only available over FTP. I discovered several other cities’ data URLs by searching Google’s FTP index.
Then use a different browser, because Chromium is not and never has been of the preservationist mindset you're talking about.
I do. Chromium/Chrome has a huge impact on the entire web ecosystem, to the point that they have an impact on people that do not use their products.
I'm grateful for that. Why should I cheerlead efforts to keep technology mired in the 1970s? That's what FTP is: a 1970s design, and not in a good way.
> I'm of the mindset that code written 20 years ago should run today.
It's OK if some of the more antiquated parts of the web die off. I don't want to have to support old Flash loading screens, I don't need AOL instant messenger status badges, or iFramed in MySpace comments, and I don't need to open FTP in my browser. Most users these days wouldn't even know how to use this via browser... ftp://myname:[email protected]... it's just a relic.
Anyone who wants to use FTP knows how to download a program for it. We don't need it in Chrome.
It's OK if some of the more antiquated parts of the web die off. I don't want to have to support old Flash loading screens, I don't need AOL instant messenger status badges, or iFramed in MySpace comments, and I don't need to open FTP in my browser. Most users these days wouldn't even know how to use this via browser... ftp://myname:[email protected]... it's just a relic.
Anyone who wants to use FTP knows how to download a program for it. We don't need it in Chrome.
I think a lot of people see it as a slippery slope. Of course FTP is not so common, but what if at some point they remove the ability to visit general URLs and just let you either google search or go to a page you've already visited.
Sadly a decent fraction of users might just accept something like this, even though it would be a major step backwards for internet freedom.
Sadly a decent fraction of users might just accept something like this, even though it would be a major step backwards for internet freedom.
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?
> 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?
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.
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.
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.
And it's not a great protocol.
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.
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.
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.
https://github.com/drakkan/sftpgo#features does that I think. It was recently on HN: https://news.ycombinator.com/item?id=20531541
_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.
Read only isn't a problem, as denying writes and allowing reads is a trivial part of unix filesystems.
You could do all that, but what's the advantage over a very simple web server behind TLS?
"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.
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.
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.
> 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.
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.
A lot of Google hate in this thread. Normally I'm on board, but I think you guys are making a big deal out of nothing.
When I click magnet:// links, my bittorrent client opens. When I click slack:// links, my slack client opens. With this change, when I click ftp:// my ftp client will open. Chrome has simply decided it only wants to spend resources focusing on http:// and make the unrelated protocols separate. I see 0 problem with this, it's not like they're killing the only or even the most popular ftp client out there. We should all be using sftp anyways...
When I click magnet:// links, my bittorrent client opens. When I click slack:// links, my slack client opens. With this change, when I click ftp:// my ftp client will open. Chrome has simply decided it only wants to spend resources focusing on http:// and make the unrelated protocols separate. I see 0 problem with this, it's not like they're killing the only or even the most popular ftp client out there. We should all be using sftp anyways...
I've always felt browsers are gimped FTP clients and found it weird they had support for the protocol in the first place. In fact the first time I used an FTP url in Netscape I was surprised it actually worked.
That said, I find the viewpoint "users should not be impacted by this deprecation" the height of arrogance. Note that phrase is lifted from the article, and is not present in the dev team's post.
That said, I find the viewpoint "users should not be impacted by this deprecation" the height of arrogance. Note that phrase is lifted from the article, and is not present in the dev team's post.
I know for a fact that HP distributes software and drivers over FTP files that they link to on their website.
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.
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.
The FTP link can still use xdg-open or whatever the local equivalent is to spawn the user's FTP app and connect to that URL. I think that's how most URLs with unsupported (by the browser) protocols are handled nowadays anyway.
What average user has a ftp app installed?
On desktop, almost everyone. Windows Explorer speaks FTP, MacOS finder speaks FTP, I think all major Linux desktop file managers do.
(Of course there's no guarantee they'll keep support for it, based on similar arguments)
(Of course there's no guarantee they'll keep support for it, based on similar arguments)
Agreed completely, but Google don't care about "nice to have"; if it doesn't ultimately make them money, they couldn't care in the slightest, yet people here will often applaud this attitude as if it were progress.
It is progress though. FTP is insecure, and worse still it breaks the security model of HTTPS (see article for more info). Plus additional code paths could be sources of bugs/exploits, particularly old/rarely updated ones.
You can justify removing anything with "less code paths." I hate that argument. Don't care about FTP being insecure either. Google's just being hostile to the open web as usual and getting the usual applause.
> Don't care about FTP being insecure either.
Well, then its probably a good thing that you aren't a browser developer.
Well, then its probably a good thing that you aren't a browser developer.
"Insecure" is the new "is a witch". Too coarse to be used as a valid argument.
Alright. It's not encrypted and not origin-verifiable then. I think we all knew that though... anyway it should be abundantly clear at this point that no one should be using protocols that can trivially be MITM'ed to access anything over the internet.
>...anyway it should be abundantly clear at this point that no one should be using protocols that can trivially be MITM'ed to access anything over the internet.
This is a specious argument because HTTP/HTTPS is regularly (and legally) MITM'ed[0, 1].
If we shouldn't use anything that can be MITM'ed, shouldn't we just shut down the internet? Wouldn't that stop MITM attacks permanently-like? What about phones? Or letters? Or even talking? Where does this scare-tactic of the MITM "boogey-man" end (for you)?
[0] - https://www.symantec.com/products/proxy-sg-and-advanced-secu...
[1] - https://www.occrp.org/en/daily/10431-kazakh-officials-delay-...
This is a specious argument because HTTP/HTTPS is regularly (and legally) MITM'ed[0, 1].
If we shouldn't use anything that can be MITM'ed, shouldn't we just shut down the internet? Wouldn't that stop MITM attacks permanently-like? What about phones? Or letters? Or even talking? Where does this scare-tactic of the MITM "boogey-man" end (for you)?
[0] - https://www.symantec.com/products/proxy-sg-and-advanced-secu...
[1] - https://www.occrp.org/en/daily/10431-kazakh-officials-delay-...
Or involves the plain text transmission of passwords by design.
Moreover it's not implausible (I'd wager it's actually likely) that HP and other websites still relying on FTP will be pressured to actually fix their sites and switch to something more secure once Chrome drops support.
They'll switch to links which require proper cookies and referers to be set making them impossible to wget. As they always do.
Now that's so much better and more secure!
Now that's so much better and more secure!
So HP is now on notice to fix that. It's not happening until 2020Q2, so that gives them plenty of time.
HP has nothing broken to fix.
They do though:
1) They are distributing executables to their users over a MITM-able channel. That is not acceptable.
2) A bunch of their users will have a much tougher time downloading their drivers when Chrome stops supporting FTP.
The drivers are cryptographically signed so the MitM-able channel is absolutely irrelevant.
The users will just have to stop using Chrome. Supporting Google software is always just a pain in the ass (and I've gotta know as developer of Android apps)
The users will just have to stop using Chrome. Supporting Google software is always just a pain in the ass (and I've gotta know as developer of Android apps)
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 ensure it's kept up to date.
There's a period of several years where Linux distros split into two camps: One camp used HTTPS and so it was fine, and the other camp would have a bug where bad guys could cause something unexpected with a MitM attack, and they'd patch it, and then some new bug would be found, and they'd patch that and repeat...
It isn't _impossible_ to get there, Fedora can safely update over insecure protocols today as far as we know. Or, you can skip all that noise and just do HTTPS as RHEL itself had been doing for many years by that point.
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 ensure it's kept up to date.
There's a period of several years where Linux distros split into two camps: One camp used HTTPS and so it was fine, and the other camp would have a bug where bad guys could cause something unexpected with a MitM attack, and they'd patch it, and then some new bug would be found, and they'd patch that and repeat...
It isn't _impossible_ to get there, Fedora can safely update over insecure protocols today as far as we know. Or, you can skip all that noise and just do HTTPS as RHEL itself had been doing for many years by that point.
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/
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/
I'm not sure if you remember, but soon after that site hit the HN frontpage several CVEs where discovered in the way APT uses http that would have been mitigated if they used HTTPS.
The CVE mentioned at the beginning of the page you linked is one of the reasons why TLS is still nice to have, security-wise. Saying that TLS is the only option may be an overstatement, but saying that it definitely provides some benefits is not.
This.
I've seen a lot of naive designs where signed data is downloaded via an unsigned control channel. At the very least, they are vulnerable to replay attacks. Beyond that, it enables more selective blocking/filtering to prevent clients from accessing specific data.
Let's not forget the lost "confidentiality" aspect of TLS either. Your request for HP_Drivers_2019_Update.exe is now broadcasting to the Internet: "Hey I'm running a vulnerable, unpatched device! Last chance to hack me!"
I've seen a lot of naive designs where signed data is downloaded via an unsigned control channel. At the very least, they are vulnerable to replay attacks. Beyond that, it enables more selective blocking/filtering to prevent clients from accessing specific data.
Let's not forget the lost "confidentiality" aspect of TLS either. Your request for HP_Drivers_2019_Update.exe is now broadcasting to the Internet: "Hey I'm running a vulnerable, unpatched device! Last chance to hack me!"
You can repackage the real driver together with your own (signed by you) trojan in a new (signed by you) installer.
How many users do you think check which entity signed an executable?
How many users do you think check which entity signed an executable?
Sure. You can't easily replace the driver with a self-written, malicious driver without exploiting some sort of deep Windows vulnerability. However, executable code can perform all manner of mischief without being a driver. Anyway, I don't think HP's TechOps underachievement is going to convince anyone to switch their browser. Instead, HP'll just have someone spend a week or two setting up an HTTPS file server and everyone will move on. It's better for their users and it's less effort than trying to have a battle to defend FTP of all things.
Not bothered by this.
No one should be running FTP in 2019. It sends passwords in plain text for christ's sake.
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.
I work at a bank (opinions my own) and nearly everything we do (including modernization, but especially partnership communications) is FTP-based. It's just about the only real standard available when the code is older than most of the devs. We do use modern encryption and mutual TLS to authenticate and encrypt everything, including before password transmission when that's even an option, but FTP is still the backbone of a ton of big older businesses.
I too work at a company/in an industry where FTP (incl. sftp/ftps) is still crucial, for both inbound and outbound transfers. A great many of our partners would find using other protocols more cumbersome. Automating the download/upload of entire directories of arbitrarily named files seems considerably easier/to require less code than any solution over HTTP might (log in, perhaps change directory, `prompt`, then `mget/mput *`). Albeit I've not done much research into alternative means recently, but a dedicated protocol beats a hand rolled solution and anyway inertia is strong - especially as (for us) nothing is transferred in either direction that isn't destined to be made public by one party.
This is tangential to whether support for FTP is still worth keeping in a web browser, mind.
This is tangential to whether support for FTP is still worth keeping in a web browser, mind.
You're probably using dedicated FTP clients, right? FTP browsing on a web browser is a hack. Uploading files, downloading multiple files at a time, doing _anything_ is just pure pain.
> 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.
reply
So...no reason for FTP in the browser, since it already supports HTTP?
So...no reason for FTP in the browser, since it already supports HTTP?
Once every site serving FTP makes their files available on HTTP, sure.
I guess many old website maintenance workflows still rely on ftp'ing HTML and assets to the web server (though not through browsers). I personally have recommended clients to switch over to ssh/scp 15 years ago if they can help it but their hosting package might not support it. The optimal, made-for-purpose protocol for this use case is WebDAV but I'm not sure it's still supported out-of-the-box by all major OSs and/or hosting packages.
You know what is a made for purpose protocol for transferring files? The File Transfer Protocol.
Ok :) but WebDAV has the advantage that it's integrated with .htaccess permissions on Apache shared hosting.
Ugh... WebDAV itself is a nasty can of worms, full of half-assed optional extensions and specification warts.
[deleted]
You would think that no one would, in 2019. I hope that you never have to witness otherwise.
All modern FTP servers support TLS.
SFTP? Not to be confused with FTPS.
The same could be said for HTTP... FTPS and SFTP do exist.
That said, I agree that its outmoded today.
That said, I agree that its outmoded today.
You'd think it's outmoded, but when the systems you're integrating with provide and expect multi-gigabyte files, the ability to append to a single file in a straightforward way and get some posix-ish APIs becomes a real life saver.
Where is your use case involving Chrome?
SFTP (SSH) gives you greater control over that, not less. In fact with SFTP you can append to any location in a file, not just the end.
How do you spend to amultigigabyte file in chrome?
It's kind of ok for anonymous downloads, but then, HTTP is even better for the purpose.
Sensible move. I'm sure they have data showing it's used by an absolutely tiny number of users, and getting rid of it removes a source of potential security issues down the line.
That's how I switched to Firefox years ago. Chrome's data had showed them a particular feature I liked wasn't used by a ton of people so they removed it.
Using Chrome these days is like Internet Explorer in 1999. You are at the mercy of a giant corporation.
The difference is that IE in 1999 was made by a giant corporation that profited from selling software, and not from monetising/tracking/advertising.
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.
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.
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.
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.
> 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.
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.
I think you missed my point.
Before, a huge portion of the population was using computers and had to peek under the hood. This means you got a lot more people who got curious about how the machine worked very early on.
I am teaching STEM stuff to kids these days-- programming in Scratch and python, etc. My friends and I, back in the day, were all poking around memory, rekeying Basic programs from magazines and moving on to writing Turbo Pascal programs, etc, at a pretty early age. I don't see this with the kids I teach. There's not as good of a path/funnel there, and I'm not sure whether the stuff we do to e.g. teach programming in elementary school, etc, are analogous exercises in computational thinking.
Before, a huge portion of the population was using computers and had to peek under the hood. This means you got a lot more people who got curious about how the machine worked very early on.
I am teaching STEM stuff to kids these days-- programming in Scratch and python, etc. My friends and I, back in the day, were all poking around memory, rekeying Basic programs from magazines and moving on to writing Turbo Pascal programs, etc, at a pretty early age. I don't see this with the kids I teach. There's not as good of a path/funnel there, and I'm not sure whether the stuff we do to e.g. teach programming in elementary school, etc, are analogous exercises in computational thinking.
I agree with you. I was in high school a couple years ago, and lucky enough to take cs classes. What I experienced was not good. Most of the kids just showed up, did the projects, passed tests, and got A's. But they were not good programmers. They were just going through the motions, if you gave them something slightly outside their knowledge, they would likely just give up.
I think there's something fundamentally wrong with the way cs is taught, but its hard to teach computers in a class setting. You really need to inspire that deep interest that so many of us have in computers, and it's very tough to get at that in the modern day. Because of the overload of information and media that kids are getting thrown at them these days. It's very easy to sit down 20 kids and make a game in scratch, and call it computer science.
We should have kids use technologies that professionals use in their work. Setup a flask web server, write a scraper, use apis, etc. Stop dumbing down things, expect more from the younger generation. Those coding bootcamps sure as heck don't teach scratch right?
I think there's something fundamentally wrong with the way cs is taught, but its hard to teach computers in a class setting. You really need to inspire that deep interest that so many of us have in computers, and it's very tough to get at that in the modern day. Because of the overload of information and media that kids are getting thrown at them these days. It's very easy to sit down 20 kids and make a game in scratch, and call it computer science.
We should have kids use technologies that professionals use in their work. Setup a flask web server, write a scraper, use apis, etc. Stop dumbing down things, expect more from the younger generation. Those coding bootcamps sure as heck don't teach scratch right?
I get your point.
I've also taught primary school kids (elementary) similar things, though fairly limited. Overwhelming what I've seen is most of them are fine with the tool they're shown and not much more, but those who do want to learn more aren't hampered by lack of exposure to the command line. Maybe a bit further behind, but they can figure it out quickly.
I think the trade off between this and computers being far more accessible is worth it.
I've also taught primary school kids (elementary) similar things, though fairly limited. Overwhelming what I've seen is most of them are fine with the tool they're shown and not much more, but those who do want to learn more aren't hampered by lack of exposure to the command line. Maybe a bit further behind, but they can figure it out quickly.
I think the trade off between this and computers being far more accessible is worth it.
The percentage of such people was, is and is going to be minuscule who care the slightest amount about peeking under the hood or truly understanding. By your logic every computer user from previous generation should know more about computers, but actually they don't.
I firmly believe that the best technology can do both. Tools should be designed firstly for the 95% of users who only need them at a surface level, but provide pathways that encourage users to explore deeper, as they become ready.
macOS kind of does this, whether intentionally or not. On the surface, it's a basic consumer machine, with a web browser, media player, and office suite. But dig a little deeper, and you'll discover Automator, a great little tool for automating menial tasks which puts you in a programmer mindset. Probe deeper still, and you may discover the Terminal icon, full of secrets to be discovered.
It could be taken further. Imagine if TextEdit had built-in syntax highlighting whenever it detected code. "Regular" users would never see the highlighting, and professional programmers would stick to real IDE's or more advanced editors. But as a hidden built-in, it could be a wonderful stepping stone.
Now compare all of this to iOS. Yes, it's true, no one really wants to program on an iPhone anyway—but what happens if you give a child an iPad instead of a laptop? There's now much less opportunity for them to grow and discover more. This isn't to say that every child with a Mac will discover the terminal and become a power user, but some will, and be thankful for the opportunity.
macOS kind of does this, whether intentionally or not. On the surface, it's a basic consumer machine, with a web browser, media player, and office suite. But dig a little deeper, and you'll discover Automator, a great little tool for automating menial tasks which puts you in a programmer mindset. Probe deeper still, and you may discover the Terminal icon, full of secrets to be discovered.
It could be taken further. Imagine if TextEdit had built-in syntax highlighting whenever it detected code. "Regular" users would never see the highlighting, and professional programmers would stick to real IDE's or more advanced editors. But as a hidden built-in, it could be a wonderful stepping stone.
Now compare all of this to iOS. Yes, it's true, no one really wants to program on an iPhone anyway—but what happens if you give a child an iPad instead of a laptop? There's now much less opportunity for them to grow and discover more. This isn't to say that every child with a Mac will discover the terminal and become a power user, but some will, and be thankful for the opportunity.
I encourage you to spend some time getting to know the linux command line. I had a similar path and I gained the most enlightenment (and productivity) when a got some help from a good mentor and learned how to find my way around. Menial digital tasks that most people suffer through all day turn into small puzzles with big rewards: you get your day back. Sure, maybe half of it went to figuring out a syntax error, but then the rest of the days get to benefit from that work. Moreover, you learn the most when trying to fix that little bug, and you're better for it the next time.
Stuff like renaming 200 files, or converting 200 images to a different size, or normalizing 200 audio files you recorded yesterday, or finding the right few words in 200 files all can be done with minutes of effort once you unlock those powers. I use 200 because that's about how many times people are willing to sit there and bang out something manually. Tasks larger than that people tend to give up on, or buy a tool to help. The neat thing is, the same solution for 200 items could be applied to 200 million items without changes.
I would love for the full power of the CLI to be available to everybody without training. Until that gift comes from on high, we use the tools we have, GUI or text or SMS or whatever. Today you can pick your path.
The internet does unlock all of those doors to those who want to learn. There are incredible resources for learning new things and fixing problems that others have ran into. Reading man pages and printed manuals may be fun for some, but I'd rather search for answers, and chip in some when I can.
Stuff like renaming 200 files, or converting 200 images to a different size, or normalizing 200 audio files you recorded yesterday, or finding the right few words in 200 files all can be done with minutes of effort once you unlock those powers. I use 200 because that's about how many times people are willing to sit there and bang out something manually. Tasks larger than that people tend to give up on, or buy a tool to help. The neat thing is, the same solution for 200 items could be applied to 200 million items without changes.
I would love for the full power of the CLI to be available to everybody without training. Until that gift comes from on high, we use the tools we have, GUI or text or SMS or whatever. Today you can pick your path.
The internet does unlock all of those doors to those who want to learn. There are incredible resources for learning new things and fixing problems that others have ran into. Reading man pages and printed manuals may be fun for some, but I'd rather search for answers, and chip in some when I can.
I do all my work in vim ;)
I'm not saying the command line isn't useful, it's insanely useful to me, but I and presumably you are the 0.5% of people that do things like batch organising thousands of files. Most people will just have a basic folder structure on a cloud service somewhere and they're fine with that.
My point is that the general population doesn't need to be exposed to the command line to be able to go deeper into learning computers. Those who need it will hopefully find it.
I'm not saying the command line isn't useful, it's insanely useful to me, but I and presumably you are the 0.5% of people that do things like batch organising thousands of files. Most people will just have a basic folder structure on a cloud service somewhere and they're fine with that.
My point is that the general population doesn't need to be exposed to the command line to be able to go deeper into learning computers. Those who need it will hopefully find it.
I don't know what it is about a black, mostly blank screen, but for the first 30 years of my life it was a source of anxiety, a 'thar be dragons...' kind of feeling. I was convinced I would make one wrong keystroke and do some terribly destructive operation. Hell, there are still some directories I'm reticent to visit.
I wish there were guard rails for learners (I guess a proper permissions scheme would do) or a safe place to explore (probably lots online at this point). Agreed that for most people, storing files in Dropbox lets them get real work done without a second thought, and that in itself is A Good Thing.
I wish there were guard rails for learners (I guess a proper permissions scheme would do) or a safe place to explore (probably lots online at this point). Agreed that for most people, storing files in Dropbox lets them get real work done without a second thought, and that in itself is A Good Thing.
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?
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.
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.
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."
Isn't this a good thing?
Understanding the inner workings of computers is not a fundamental good. Solving problems and achieving one's goals are the important thing. If people can use computers to solve problems better today but they don't understand how bootloaders work then I think that is a good trade off.
Understanding the inner workings of computers is not a fundamental good. Solving problems and achieving one's goals are the important thing. If people can use computers to solve problems better today but they don't understand how bootloaders work then I think that is a good trade off.
I hope he didn’t download the adware/malware infested version of FileZilla though.
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?
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.
There is[1], but yeah it doesn't apply in this context.
[1] https://en.wikipedia.org/wiki/File_eXchange_Protocol
[1] https://en.wikipedia.org/wiki/File_eXchange_Protocol
Why do we need a separate legacy protocol for file transfers?
What’s the benefit in keeping protocols for the sake of it?
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.
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.
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?
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?
> 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.
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.
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.
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.
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.
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.
SFTP is actually not just FTP over SSH. The protocol is different precisely to get rid of a lot of the outdated nuisances.
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.
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.
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.
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.
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.
That’s not the point we are discussing though; This is specifically regarding Chromium supporting FTP.
And that’s also why SFTP is slower than FTP: because it’s a separate protocol implementing its own windowing which interferes with TCP’s, thus performance goes down the toilet when using SFTP over a high latency connection.
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.
Ftp is fast
Genuinely curious. Why do you think a bitstream from an FTP server is faster than from a HTTP server?
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.
That’s all well and good, and has nothing to do with Chromium keeping ftp support.
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.
Why do you assume this is driven by some desire for "pliant consumers", vs a desire to build a simpler and more secure browser?
Correct me if I'm wrong, but Windows and most Linux distros both come with usable ftp clients in general. So an ftp link will result in the OS handling it, right? And so it opens in IE or Filezilla or whatever.
That's fine... Except on a Chromebook or Android, where it will be a pain.
That's fine... Except on a Chromebook or Android, where it will be a pain.
> And so it opens in IE or Filezilla or whatever.
Aren't you forgetting that IE is a web browser, so are you suggesting it should just offload ftp:// links to another browser?
Also, IE is deprecated and replaced by Edge which is now essentially Chrome, so eventually won't work there as well.
Aren't you forgetting that IE is a web browser, so are you suggesting it should just offload ftp:// links to another browser?
Also, IE is deprecated and replaced by Edge which is now essentially Chrome, so eventually won't work there as well.
You can actually navigate FTPs (and transfer files) with Explorer too. Quite handy when you don't have an dedicated client installed.
Windows comes with an ftp client? Not that I know of. Unless you mean MS Edge? Oh or I guess there's a command line one. It's not integrated into Windows Explorer, though.
Windows Explorer can navigate (and transfer files) on FTPs. Type "ftp://ip.addr.of.ftp" in explorer and you're in. :-)
Woah... I stand corrected. I guess I had only tried sftp!
Huh, so it can. I never knew that.
Wouldn't this just make a ftp:// url fallthrough to the ftp client in Dolphin/Finder/Explorer/xdg?
Like, worst-case ChromeOS loses ftp?
Like, worst-case ChromeOS loses ftp?
Will FTP links prompt to open another program? I'm for the change if Google provides an extension/recommends a viewer.
If suddenly the links stop working and there isn't a way view the contents, it will be a frustrating transition
If suddenly the links stop working and there isn't a way view the contents, it will be a frustrating transition
Good. Honestly it was always weird to me that browsers ever supported FTP in the first place, it seemed so arbitrary. (Why not gopher and telnet too?)
You'll still be able to download an ftp: link by your browser opening your local FTP client, same as a magnet: opening your local torrenting client -- as it should be.
And honestly, if you're one of the few people who actually need to regularly download files with FTP, don't you want a better standalone client anyways?
You'll still be able to download an ftp: link by your browser opening your local FTP client, same as a magnet: opening your local torrenting client -- as it should be.
And honestly, if you're one of the few people who actually need to regularly download files with FTP, don't you want a better standalone client anyways?
Early browsers did in fact support gopher. (some still do)
FTP isn't such a good protocol anyways (and there are better programs for accessing FTP than most web browsers); there is Gopher, HTTP(S), Plan9, TFTP, SSH, and other protocols.
(I also invented a httpdirlist format (I have been told that httpdirlist is like WebDAV but not as bad; but I don't know WebDAV so I cannot say if it is or not). But, sometimes, the other protocols is better than HTTP(S) anyways.)
I think it is fine to have them implemented in separate programs, although sometimes you might want to display the result in the browser; one possibility is that the user can configure a program to execute and can configure it to treat the data that program writes to stdout as a HTTP response (possibly with different permissions than normal; it might allow some things that are normally disallowed, and some things that are normally allowed might not work). You might then also want to support other MIME types. You can do this also with external programs; so one configuration option could be to allow treating the program as a filter to convert it into a format the browser understands (e.g. plain text, HTML, PNG, etc; perhaps farbfeld should be supported too, even only for the purpose of these external filters).
(I also invented a httpdirlist format (I have been told that httpdirlist is like WebDAV but not as bad; but I don't know WebDAV so I cannot say if it is or not). But, sometimes, the other protocols is better than HTTP(S) anyways.)
I think it is fine to have them implemented in separate programs, although sometimes you might want to display the result in the browser; one possibility is that the user can configure a program to execute and can configure it to treat the data that program writes to stdout as a HTTP response (possibly with different permissions than normal; it might allow some things that are normally disallowed, and some things that are normally allowed might not work). You might then also want to support other MIME types. You can do this also with external programs; so one configuration option could be to allow treating the program as a filter to convert it into a format the browser understands (e.g. plain text, HTML, PNG, etc; perhaps farbfeld should be supported too, even only for the purpose of these external filters).
My take is that they didn't want to invest resources into making the FTP client secure in Chrome because it's usage is low, so they just decided that it'd be better to just remove it entirely. Whatever.
Anyway, it's not like Chrome couldn't send the URL to a dedicated FTP client. Hell, it could even be another browser like Firefox. It's not going to be the end of the world -- just not as seamless of an experience and one would like.
Anyway, it's not like Chrome couldn't send the URL to a dedicated FTP client. Hell, it could even be another browser like Firefox. It's not going to be the end of the world -- just not as seamless of an experience and one would like.
I've used FTP for many years, and I still use it to manage the file system of my blog, which is running on a cheap VPS. I doubt, though, that even 1 in 100 non-technical Internet users knows what it is. There are several good clients available. I think you can even still use Windows Explorer. I can't think of a strong argument for Google to maintain support in Chrome.
Referenced post: https://chromestatus.com/feature/6246151319715840
I always liked FTP support as a part of the browser platform. Of course, it would not have the capabilities of a standalone FTP client. And for those who needed those capabilities, lots of tools exist.
The web is not just HTTP. FTP has been the binary companion to the text-based HTTP protocol, and I think that for the sake of the browser being a platform and not just a viewing tool, it should stay.
The web is not just HTTP. FTP has been the binary companion to the text-based HTTP protocol, and I think that for the sake of the browser being a platform and not just a viewing tool, it should stay.
Not for this reason alone (mostly because I can never sign out of the browser and it's trying to auto-sign-me-in to sites I don't want tracking me) I uninstalled chrome yesterday.
End of an era. I imagine it would take the better part of a decade to earn my loyalty back if they ever pulled a 180, but seeing their direction the writing has been on the wall for a while.
End of an era. I imagine it would take the better part of a decade to earn my loyalty back if they ever pulled a 180, but seeing their direction the writing has been on the wall for a while.
Why don't they remove the bloat in source code, reducing its compile time from 2/3 hours to roughly minutes?
Second best reason to move away from Chrome.
Ridiculous, Firefox removed support for FTP far before chrome.
Firefox has not removed support for ftp. I just browsed to ftp://ftp.osuosl.org/ in Firefox 68 just before submitting this comment.
Mozilla stopped running ftp://ftp.mozilla.org quite a while ago. Maybe that is what you were remembering?
Mozilla stopped running ftp://ftp.mozilla.org quite a while ago. Maybe that is what you were remembering?
What I said was erroneous!
This is what I remembered badly, https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-res...
FTP as a protocol doesn't have interesting metadata to collect (which would be technically challenging in the first place, without redirection and JavaScript tricks) and doesn't allow advertisement, while FTP as content is hard to index and promote in ways that generate "value".
[deleted]
After this change, will Chrome still be able to support FTP through extensions?
Given that extensions are just JavaScript code and they constantly restrict what they can do, I doubt it.
Extensions can communicate with a native helper app actually.
This looks like an FTP capable extension.
https://chrome.google.com/webstore/detail/sftp-client/jajcol...
Not sure if it uses a proprietary proxy though.
https://chrome.google.com/webstore/detail/sftp-client/jajcol...
Not sure if it uses a proprietary proxy though.
[deleted]
Unicorn startup idea: Build a FTP search engine!
Takes me back to the shitty ISP I had which decided to block port 21 to reduce traffic and increase security.
Good. An easy feature for competitor browsers to implement.
Firefox used to support FTP too and removed support for it far before chrome.
Source?
I just opened ftp://ftp.gnu.org/pub/gnu/ in firefox 68.
I just opened ftp://ftp.gnu.org/pub/gnu/ in firefox 68.
I was mostly wrong.
https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-res...
Just as a reminder, Firefox did this (a year ago?).
Is that true? I just opened an FTP URL in Firefox 68 just fine.
No what I said was in fact erroneous!
https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-res... But FTP still is.
https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-res... But FTP still is.
First they came for Gopher ...
What alternatives to Chrome are people here using other than Firefox or safari?
What can I say except "fuck Google"? I don't think there's anything constructive to be said here because this is so obviously a bad move (for users).
I feel like Google is quickly moving in the footsteps of IE; embrace, extend, extinguish and all that. I don't like how Google now has so much market share in the browser space that they can essentially unilaterally make decisions that are user-unfriendly and have a real impact. I switched (back) to Firefox for this reason. I switched away from them when they essentially purged Brendan Eich for political reasons, but they're the lesser of two evils now.
I guess in summary, all browsers suck and we're all fucked.
I feel like Google is quickly moving in the footsteps of IE; embrace, extend, extinguish and all that. I don't like how Google now has so much market share in the browser space that they can essentially unilaterally make decisions that are user-unfriendly and have a real impact. I switched (back) to Firefox for this reason. I switched away from them when they essentially purged Brendan Eich for political reasons, but they're the lesser of two evils now.
I guess in summary, all browsers suck and we're all fucked.
Isn'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?
Why should we keep FTP or other legacy non-HTTP protocols around? What are we buying? Slightly lower connection setup byte counts?
That's a naive statement. Take streaming protocols, as an example, and that alone is reason enough for why you shouldn't it over HTTP. HTTP is inherently stateless. There are many use-cases that are stateful. This leads to high latencies for HTTP streaming since the full state (HTTP headers to tell me who you are and what you want) is sent for every request.
HTTP these days (via WebSockets) allows for the creation of stateful connections. My idea is that HTTP will just expand to encompass any remaining non-HTTP use cases. HTTP isn't even coupled to TCO anymore!
Websockets use HTTP only for the initial handshake. The rest of the channel uses the Websocket protocol.
Yes. That protocol is effectively part of HTTP now.
The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request.
Effectively.
If you do connection setup, service disambiguation, redirects, and so on with HTTP and switch to a non-HTTP interactive protocol, what you've effectively done is create an HTTP sub-protocol, and I don't care what the document you quoted says.
If you do connection setup, service disambiguation, redirects, and so on with HTTP and switch to a non-HTTP interactive protocol, what you've effectively done is create an HTTP sub-protocol, and I don't care what the document you quoted says.
Nobody is advocating publishing new resources via FTP and neglecting HTTP. I hope every FTP server starts supporting HTTP as well. But that's not how it works. Dropping support is willfully causing link rot.
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.
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.
Also, I can't be the only one who's absolutely sick of hearing that bloody "security" argument again. Yes, everyone knows FTP is plaintext, and so is HTTP. But drivers, which I'd say are a significant part of FTP use, are almost always themselves signed anyway, and I don't think malware is widely distributed via FTP either (I'm curious why FTPS/SFTP doesn't see to be indexed, or why they didn't decide to add that to the browser instead --- or at least I've never come across a search result that links to one.)