
Google Plans to Deprecate FTP URL Support in Chrome - github-cat
https://www.pulltech.net/article/1566007822-Google-plans-to-deprecate-FTP-URL-support-in-Chrome
======
userbinator
Considering that Google (search) still lists plenty of FTP results, many of
which have been _extremely_ useful to me, this seems like another move to
bully the Internet into what Google wants it to be. Will it start removing
those results, effectively censoring another huge chunk of the Internet? It's
already hard enough to find older/more obscure information, and FTP sites are
more likely to be in that category.

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

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

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

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

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

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

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

~~~
Touche
Do dedicated ftp clients include crawling and indexing?

~~~
T-hawk
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.

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

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

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

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

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

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

~~~
tim58
A platform should support the entire spec. An app should correctly implement
the parts of the spec it chooses.

------
nyxxie
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://](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...

~~~
OrgNet
Do they index magnet and slack links?

~~~
nyxxie
No, but they currently index ftp links.

~~~
OrgNet
that's too bad... they should index all of it

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

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

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

~~~
brokensegue
What average user has a ftp app installed?

~~~
detaro
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)

------
TylerE
Not bothered by this.

No one should be running FTP in 2019. It sends passwords in plain text for
christ's sake.

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

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

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

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

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

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

------
kerng
Using Chrome these days is like Internet Explorer in 1999. You are at the
mercy of a giant corporation.

~~~
userbinator
The difference is that IE in 1999 was made by a giant corporation that
profited from selling software, and not from monetising/tracking/advertising.

------
subsubsub
Google don't want users, they want pliant consumers.

The idea that young people know more about tech than their parents will become
less and less true in the future.

~~~
georgebarnett
Why do we need a separate legacy protocol for file transfers?

What’s the benefit in keeping protocols for the sake of it?

~~~
im3w1l
We need a protocol for file transfers because having a protocol makes it more
standardized and interoperable than if everyone rolls their own solution.

Do we need browser support for it? It still happens now and then that a link
will have an ftp target. That could be handled in the browser or it could open
a separate url-handling application, as e.g. email or magnet urls do.

~~~
anyfoo
Yes, but as someone who's been around when FTP was a big thing, and HTTP only
just came into fruition... what, really, is the benefit of FTP? In fact, FTP
is actually a horrible protocol, that caused me much pain even back then:

It uses separate "command" and "data" channels. The data channel is usually in
the other direction, i.e. the _client_ listens to a connection from the
_server_ when downloading a file. Passive mode, and an extra command for that,
had to be implemented, and if the stars don't align right, it still ends up
being a pain.

FTP also used to default to 7bit. If you did not explicitly switch to 8bit
mode, you got corrupted downloads. This maybe made sense in a world with
fundamentally different encodings, line endings, and where connection speeds
were slow enough that downloading text files was a big task, but now?

Then, if I remember correctly, the file listing you got was not actually
standardized, it could just be the output of the "ls" command on the server!
FTP clients used to be dumb and just passed that output through to you, so it
did not matter much. For smarter clients later, it did start to matter.

Finally, what does FTP actually offer that, in most cases, HTTP, and, in niche
cases, rsync, scp or sftp do not offer?

~~~
viraptor
> It uses separate "command" and "data" channels

This is not a bad thing in itself. It could enable you to download each file
from a different, potentially better endpoint, while talking to the same
server for coordination. It's just not the way we do it these days anymore -
3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that
idea being usable years ago. It's still fine in protocols like sip.

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

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

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

~~~
pedrocx486
Windows Explorer can navigate (and transfer files) on FTPs. Type
"ftp://ip.addr.of.ftp" in explorer and you're in. :-)

~~~
takeda
That's because it shares code base with IE, a web browser.

Here we are talking about removing FTP from a browser.

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

------
bvttf
Wouldn't this just make a ftp:// url fallthrough to the ftp client in
Dolphin/Finder/Explorer/xdg?

Like, worst-case ChromeOS loses ftp?

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

------
crazygringo
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?

~~~
kayamon
Early browsers did in fact support gopher. (some still do)

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

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

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

------
edaemon
Referenced post:
[https://chromestatus.com/feature/6246151319715840](https://chromestatus.com/feature/6246151319715840)

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

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

------
IloveHN84
Why don't they remove the bloat in source code, reducing its compile time from
2/3 hours to roughly minutes?

------
Endy
Second best reason to move away from Chrome.

~~~
The_rationalist
Ridiculous, Firefox removed support for FTP far before chrome.

~~~
kbrosnan
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?

~~~
The_rationalist
What I said was erroneous! This is what I remembered badly,
[https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-
res...](https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-resources-
within-web-page-is-no-longer-allowed/)

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

------
Causality1
After this change, will Chrome still be able to support FTP through
extensions?

~~~
takeda
Given that extensions are just JavaScript code and they constantly restrict
what they can do, I doubt it.

~~~
tln
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...](https://chrome.google.com/webstore/detail/sftp-
client/jajcoljhdglkjpfefjkgiohbhnkkmipm?hl=en-GB)

Not sure if it uses a proprietary proxy though.

------
fastbmk
Unicorn startup idea: Build a FTP search engine!

------
pts_
Takes me back to the shitty ISP I had which decided to block port 21 to reduce
traffic and increase security.

------
iovrthoughtthis
Good. An easy feature for competitor browsers to implement.

~~~
The_rationalist
Firefox used to support FTP too and removed support for it far before chrome.

~~~
tln
Source?

I just opened ftp://ftp.gnu.org/pub/gnu/ in firefox 68.

~~~
The_rationalist
I was mostly wrong. [https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-
res...](https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-resources-
within-web-page-is-no-longer-allowed/)

------
The_rationalist
Just as a reminder, Firefox did this (a year ago?).

~~~
Narishma
Is that true? I just opened an FTP URL in Firefox 68 just fine.

~~~
The_rationalist
No what I said was in fact erroneous!

[https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-
res...](https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-resources-
within-web-page-is-no-longer-allowed/) But FTP still is.

------
viburnum
First they came for Gopher ...

------
sschueller
What alternatives to Chrome are people here using other than Firefox or
safari?

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

------
quotemstr
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?

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

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

~~~
aloknnikhil
Websockets use HTTP only for the initial handshake. The rest of the channel
uses the Websocket protocol.

~~~
quotemstr
Yes. That protocol is effectively _part_ of HTTP now.

~~~
ivanfon

      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.
    

[https://tools.ietf.org/html/rfc6455#section-1.7](https://tools.ietf.org/html/rfc6455#section-1.7)

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

