Live data from Hacker News

Stopping FTP support in Firefox 90

blog.mozilla.org

91–100 of 350 posts

Re: Stopping FTP support in Firefox 90

#91
Reminds me of Apple removing the headphone jack and being so proud of themselves for "being brave".

Just yesterday I found a link to FTP while researching something. Was pretty annoying to go get another FTP client up and running to get it.

Anyway, the movement away from unencrypted protocols to TLS-only is moving us closer to a fully censored internet. Sure, an unencrypted internet did not have any integrity guarantees, and thus was easy to censor (and worse) by totalitarian nation states.

However, a TLS-only internet is very easily censorable by our new global central planners (FAANG). This way, they'll have much more control than was available to the common MITMing nation state.

Re: Stopping FTP support in Firefox 90

#93
post #36

I don't understand all the negativity around this. People complained when Firefox added Pocket, in part because they took a browser extension and made it a feature that was ostensibly unrelated to web browsing. Now they're taking an old feature that's definitely not related to web browsing and removing it, and people are still complaining? Firefox can't be everything. It should focus on being a great browser and not…

Because pocket was a useless addition and dropping ftp:/ support breaks approximately 150 million valid links.

Browsers opening an ftp:// link can simply prompt to open it in a different program, much like they did PDFs in the past. (I also don't think a browser should have to be a great PDF renderer, but here we are.)

Re: Stopping FTP support in Firefox 90

#95

Earlier quoted context omitted.

No. WebSockets are a specific protocol tunneled over HTTP, not raw sockets, and WASM doesn't expose any functionality which wasn't already available to JS.

Webrtc?

You could make something similar to FTP with that, but it wouldn't be interoperable. Web browsers just don't expose a generic socket api where you can specify ports, bind(), listen(), accept(), connect(), and so on. So you can't make generic socket clients or servers. XHR, websockets, webrtc, and so on might be able to connect to a specific port, but they send things that would cause errors, and can't send/receive arbitrarily crafted sequences of data.

Re: Stopping FTP support in Firefox 90

#96
post #90

Earlier quoted context omitted.

Agreed. There are old drivers from established vendors that only send drivers over FTP links. It's an edge case these days though as more are moving to https:// links so I can understand the browser vendors wanting to make the code base smaller. They have enough to do. Especially for Mozilla given what they charge for us to use their product.

Maybe nice if they (Mozilla and/or Google) would make a site somewhat like https://webftp.dreamhost.com/ that would accept url parameters to sort of proxy ftp requests. Wouldn't help for internal network ftp servers, but would ease the publicly accessible part. (Note that the dreamhost site has a little link icon in the lower left that will generate a link/landing page with all the important bits filled out.)

Wouldn't make that security worse? Then any FTP connection would have to be proxied through a third-party, which has all opportunity to monitor or MITM the files. This in particular as FTP is often used to transfer non-public files.

Alternatively, Firefox could allow standalone clients to register for the ftp:// uri scheme (I think that's already possible) and, if no client is registered, redirect to some info page that explains the situation and offers links to standalone clients.

Re: Stopping FTP support in Firefox 90

#97
post #5

Earlier quoted context omitted.

While I agree with removing FTP support, I also agree that phrasing is pretty disgusting.

We'd be even more secure if they took away HTTP and HTTPS support

Way ahead of you: https://blog.mozilla.org/security/2015/04/30/deprecating-non...

Re: Stopping FTP support in Firefox 90

#98
post #96
post #90

Earlier quoted context omitted.

Maybe nice if they (Mozilla and/or Google) would make a site somewhat like https://webftp.dreamhost.com/ that would accept url parameters to sort of proxy ftp requests. Wouldn't help for internal network ftp servers, but would ease the publicly accessible part. (Note that the dreamhost site has a little link icon in the lower left that will generate a link/landing page with all the important bits filled out.)

Wouldn't make that security worse? Then any FTP connection would have to be proxied through a third-party, which has all opportunity to monitor or MITM the files. This in particular as FTP is often used to transfer non-public files. Alternatively, Firefox could allow standalone clients to register for the ftp:// uri scheme (I think that's already possible) and, if no client is registered, redirect to some info page t…

Perhaps if it only supported anonymous ftp. That's most of the links that will get broken. For that, there is no real security consideration. What exists is plain text all around with deliberately exposed passwords.

Re: Stopping FTP support in Firefox 90

#99
post #75

Earlier quoted context omitted.

So good luck configuring your firewall or NAS that don't have a valid certificate.

Seems like a great opportunity to secure your server rather than training humans to ignore security warnings, doesn't it?

Secure how?

Obtaining a public certificate from a well-known registrar requires Internet connectivity for the ACME protocol, and that's at odds with the other best-security-practice of isolating internal systems like NAS devices well away from general Internet connectivity.

The problem is even worse for home routers. They need Internet connectivity to have a chance of obtaining a certificate, but since they provide that connectivity to a network they can't obtain the certificate until they're set up. But setup generally happens via a web browser and captive portal, so we're right in the middle of a bootstrapping problem.

https/TLS everywhere on the public Internet is a great thing, but it's not a reasonable expectation for private networks with private devices.

Post reply on HN