Google Plans to Deprecate FTP URL Support in Chrome

Can you give an example of a piece of software of reasonable complexity (network/file handling, etc) that has solidified like this?

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

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?

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.

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.

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.

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.

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.

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.

Yes but if one of those files was ADSENSE-one-wierd-trick.jpg

Nobody would actually bother to download it would they!

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

You could write native apps on top of your proposed directory layouts, and it would be better than whatever people do today.

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

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.

>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!

I recommend https://bazqux.com/ -- The death of Reader sprung the life of many pre-existing RSS reader replacements.

Don't jinx it! Luminary and Apple Podcasts are trying to add exclusive content now.

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.

Please share your favorite RSS client

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.

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

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.

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.

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

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.

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

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.

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.

Have they fixed the issue with excessive resource consumption when using Firefox on a Retina MacBook?

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

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

You could do all that, but what's the advantage over a very simple web server behind TLS?

https://github.com/drakkan/sftpgo#features does that I think. It was recently on HN: https://news.ycombinator.com/item?id=20531541

Why doesn't HN support http login then? It's part of the spec.

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)

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.

Except ftp is alive.

They can also just not upgrade their browser, then. If they don't have the time/energy they're probably still on IE anyway.

Can’t Chrome just hand the ftp:// link over to a dedicated client?

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.

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.

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!

> Don't care about FTP being insecure either.

Well, then its probably a good thing that you aren't a browser developer.

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)

Lots of SFTP clients are good at mput.

If we're limiting ourselves to HTTP, WebDAV is pretty nice and has builtin support across Windows, Mac, and most Linux distributions.

SFTP is different from FTP, though. As far as I know, it's a fine protocol.

Ok :) but WebDAV has the advantage that it's integrated with .htaccess permissions on Apache shared hosting.

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

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.

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.

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.

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 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 more like "now we don't have to teach everyone to read and write, we do the (filtered/censored/etc.) communication for them."

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.

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.

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.

No, actually the Explorer FTP support doesn't come from a browser at all. It's actually the other way around - IE handed off FTP handling to Explorer.

Yes. That protocol is effectively part of HTTP now.