back to article Not just deprecated, but deleted: Google finally strips File Transfer Protocol code from Chrome browser

The Chromium team has finally done it – File Transfer Protocol (FTP) support is not just deprecated, but stripped from the codebase in the latest stable build of the Chrome browser, version 95. It has been a while coming. A lack of support for encrypted connections in Chrome's FTP implementation, coupled with a general …

  1. Anonymous Coward
    Anonymous Coward

    Overkill for many sites

    I always recommend using appropriate security and most of the time, you do not need sftp.

    1. A random security guy

      Re: Overkill for many sites

      You would generally use a file transfer system as part of a tool chain that is used in a process. Starting with a fundamentally unsecured system that can be readily exploited is fairly difficult to fix when security just happens to be required.

      Make everything zero-trust. That way you avoid one system failure to become the Maginot line failure.

      Simple examples: power distribution systems used FTP and FTP like protocols and then they suddenly became distributed. You can't even change the password because it was appropriate security 50 years ago. Router boxes are another example.

      I wonder where FTP would be appropriate vs. SFTP. Just opening up the port is grounds for dismissal. I see small devices use it for firmware upgrade. Unsigned firmware upgrade on the top of it.

      1. Anonymous Coward
        Anonymous Coward

        Re: Overkill for many sites

        Actually the Maginot line didn't fail. Hitler just went around it with his fancy new tanks.

        1. doublelayer Silver badge

          Re: Overkill for many sites

          And thus it failed. The line was intended to be impassable, or at least very difficult to pass, and it probably would have been pretty good had someone tried to assault it directly. However, because it was possible to bypass it, it ended up not doing what it was designed for, and being effort wasted. Its only benefit was delaying troops by a few days, and it used resources which could have been used in making a more vigorous defense against them.

          1. A random security guy

            Re: Overkill for many sites

            The German paratroopers also penetrated fort Eben-Emael (sp?). Which was disconcerting for the French and the Belgians because the Germans turned around and used it to control everything the fort was supposed to. For the wrong side.

            Without zero trust and the current shift from perimeter based architecture to a mesh system, I can’t even imagine any justification for ftp.

            FTP depends on everyone else doing the right thing.

          2. jmch Silver badge
            Boffin

            Re: Overkill for many sites

            "The line was intended to be impassable"

            It was meant to be impassable on the German-French border. Belgium and the Netherlands were neutral, and France was still under the mistaken impression that other countries were playing by the informal rules of war that were basically centuries-old gentlemen's agreements. Hitler (there goes Godwin's law!) just ignored the neutrality and invaded Belgium and the Netherlands to get around the Maginot.

            I guess that's enough off topic!

            1. Anonymous Coward
              Coat

              Re: Overkill for many sites

              Merely mentioning Hitler in conversation isn't sufficient to invoke Godwin. Godwin requires a comparison of, for example, your mum to Hitler.

              I propose mentions of Hitler in future be referred to as Mini-Godwins.

              1. Disgusted Of Tunbridge Wells Silver badge
                Gimp

                Re: Overkill for many sites

                Don't you repress him.

                That's exactly what Hitler would do.

            2. jake Silver badge

              Re: Overkill for many sites

              Godwins "Law" isn't actually a law, it's an adage. It reads "As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1.

              And that is all. Mike was just trying to get people to think before making daft comparisons to Hitler and the Nazis, he was not suggesting any mention should somehow automagicaly close down the conversation.

              1. John Lilburne

                Re: Overkill for many sites

                Mike has never obeyed his own adage. He's pretty quick to shout TROLL at anyone who doesn't agree 100% with him.

                1. jake Silver badge

                  Re: Overkill for many sites

                  The adage doesn't contain anything that needs obeying. It's an observation, nothing more.

            3. imanidiot Silver badge

              Re: Overkill for many sites

              No, no, in the case of the Netherlands he didn't ignore neutrality, he simply made up some stuff about the Netherlands having violated it's own neutrality by cooperating with British intelligence officers and German officers conspiring against his government, thus making his invasion of the Netherlands "totally legitimate" (see the Venlo incident: https://en.m.wikipedia.org/wiki/Venlo_incident. This incident also contributed to the forming of the SOE by Churchill, then later das Englandspiel and the general mistrust of Dutch resistance by SOE, culminating in the failure of operation Market-Garden)

          3. Disgusted Of Tunbridge Wells Silver badge

            Re: Overkill for many sites

            The reason it "failed" is that for political reasons it didn't extend across Belgium - the French government wanting to keep their allies on side.

            It might have worked if it had.

      2. martyn.hare
        Go

        FTP is totally appropriate where

        The instance has a dedicated purpose, your payload is itself encrypted and where you’re using both IP restrictions and a form of digest-based authentication. Its also worth keeping in mind that SFTP is not great for security either if we are talking OpenSSH vs. vsftpd where the latter has remained very static in feature set, has been widely audited and thus has always had very few bugs.

        Should you need TLS for your old FTP implementation, you always have the option of forcing FTPS in modern ftpds or if you’re forced to use outdated crap, then you can either IPSec your way around it or use stunnel.

        1. martinusher Silver badge

          Re: FTP is totally appropriate where

          Its also useful for local file transfer. Not everyone is going out on the anonymous Internet to send or receive huge files of heaven only knows what. (...and even if you are then surely you're checking incoming data before using it?)

        2. rcxb1

          Re: FTP is totally appropriate where

          <blockquote>you can either IPSec your way around it or use stunnel.</blockquote>

          No, you can't.

          "Stunnel cannot be used for the FTP daemon because of the nature of the FTP protocol"

          https://www.stunnel.org/faq.html

        3. This post has been deleted by its author

      3. Anonymous Coward
        Anonymous Coward

        Re: Overkill for many sites

        "I wonder where FTP would be appropriate vs. SFTP"

        Literally any anonymous download from the Internet. There is zero reason to encrypt publically available information, and encryption does not help with file verification. People who understand the purpose of encryption can come up with many scenarios which fit your question, while a significant number of "security professionals" are clueless and talk about zero trust to distract from their lack of understanding.

        1. Gerhard Mack

          Re: Overkill for many sites

          You seem to be forgetting that one of the reasons behind the current push for encryption everywhere was that several ISPs were caught hijacking connections and adding stuff the user never asked for to the stream.

          1. jake Silver badge

            Re: Overkill for many sites

            If you can't trust your ISP (social media provider, OS provider ...) to not snoop-and-augment user traffic, you have far more interesting problems than "which file transfer protocol should I use?".

        2. doublelayer Silver badge

          Re: Overkill for many sites

          "Literally any anonymous download from the Internet. There is zero reason to encrypt publically available information,"

          There are several. Here are a few of them:

          1. "encryption does not help with file verification.": It does prevent a listener from modifying the content and it still being valid. Most edits will break the encryption and alert the user rather than corrupting the file, and even if they can corrupt the file, they are unlikely to be able to inject new data into it.

          2. Privacy: If I'm downloading a file which anyone can download, but it's encrypted, then an attacker doesn't know exactly which file I'm viewing. This may be of interest to me. The degree of privacy still depends on other factors, as they can usually get the domain I'm downloading from, but there are some plans to encrypt that as well.

          3. It prevents meaningful injection of other data, which means that, for files which can't be verified (never an SHA1 hash for a standard page), you're not getting an attacker's replacement instead.

          4. If you do have a verifiable file, but the hashes are also retrieved unencrypted, the attacker could replace the file you're downloading and the hashes when you retrieve them so they do match.

          If you need something which can talk to something old or something that really can't do encryption because it's so weak, FTP is tested as a protocol. Otherwise, there are reasons to want something that protects the user.

          1. jake Silver badge

            Re: Overkill for many sites

            I agree that there are reasons to protect some users from some things ... but I totally reject the argument that all users need protecting from everything.

          2. Lusty

            Re: Overkill for many sites

            You're confusing your use-cases with every use case. None of your points make any sense with 99% of FTP traffic on the Internet, and your ultra paranoia that somehow there's a man in the middle attack injecting dogs into your cat pictures is ridiculous security industry bullshit.

            If someone has the skill, and most importantly motivation to hijack one of the routers between an Internet server and an end user then it's pretty trivial to also insert their own TLS without that user noticing, making the extra layer pointless.

            1. doublelayer Silver badge

              Re: Overkill for many sites

              You are sort of correct that almost all FTP traffic in use doesn't come under the use case I suggest. However, that's most of the traffic using FTP for transfers between known machines for known purposes. Most traffic from browsers is users downloading stuff, where the risk of an attacker is larger. Since this article was about the inclusion of FTP in a browser, not an FTP client, I was talking about that use case most of all.

              "If someone has the skill, and most importantly motivation to hijack one of the routers between an Internet server and an end user then it's pretty trivial to also insert their own TLS without that user noticing, making the extra layer pointless."

              People do have the skill and motivation, observed in ISPs and dodgy public networks alike. And no, it's not always easy to inject TLS. TLS certs are verified against CAs and associated with specific names. Unless the attacker succeeds in redirecting the user to a different endpoint without their noticing, they will find impersonation a bit harder.

              1. Lusty

                Re: Overkill for many sites

                "Most traffic from browsers is users downloading stuff, where the risk of an attacker is larger."

                No, it's not. It's just not. If you don't work for MI5 it's extremely unlikely that someone would do anything to your anonymous download from Tucows that hadn't already been done server side or client side. There is a vanishingly small possibility that someone would be able to intercept your traffic and modify it unless there were state level reasons to do so, and even then they'd probably have the help of the infrastructure providers.

                I strongly suggest you stay away from security vendor marketing for a while, it's having a detrimental effect on your world view.

          3. heyrick Silver badge

            Re: Overkill for many sites

            "the attacker could replace the file you're downloading and the hashes when you retrieve them so they do match"

            What a palaver. Alternatively call up claiming to be XYZ Technical Support and, for far too many people, get a lot more useful information for a lot less effort.

            1. doublelayer Silver badge

              Re: Overkill for many sites

              Entirely true. Few attackers would go to that effort when they have other mechanisms. The only reason I brought it up is that it is a case where the data itself isn't sensitive but can still produce a dangerous result, and you'll note that it only is needed if two conditions which don't always hold are met, and if either is not met, it's a lot easier to inject malicious data.

          4. Zakhar

            Re: Overkill for many sites

            There is a case though where FTP makes sense: retrieving my own encrypted files stored in "the cloud".

            I use encfs and the files are encrypted locally before storing. So, files at rest "on the cloud" are encrypted with my own key that is kept locally.

            1. encfs is setup with a verification code so that if the file was changed the read would fail.

            2. Indeed an attacker can see that I access my cloud provider and how much data. Encryption won't change that. To be precise, the FTP control flow is kept encrypted of course, only the FTP data flow in unencrypted. (--ftp-ssl-control option for curl)

            3. see 1.

            4. no, the hashes are in the encfs blocks themselves, and apart out of sheer luck you can't tamper with that.

            Adding encryption on already encrypted data adds no protection, indeed granted that the protocol used also does "checksums".

            1. doublelayer Silver badge

              Re: Overkill for many sites

              Yes, that use case works well. My comment was about the uses from a browser as that's what changed and what some here dislike, and you can't do any of those checks from a browser. You could of course download the file with a browser and see whether encfs likes it, but I'm guessing you're using an automatic system which does it more efficiently and therefore don't rely on the browser for any FTP tasks.

    2. Smartypantz

      Re: Overkill for many sites

      The stupid is strong in this one Luke!

  2. Mike 137 Silver badge

    "frankly, Google and pals would rather users opted for a dedicated transfer app"

    Of course they would - it's proprietary and capable of silent snooping.

    SFTP is the fastest and simpest way to maintain a web site - far more convenient than the clunky file managers in abortions such as cPanel.

    1. Version 1.0 Silver badge

      Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

      It's going to be sold as "an upgrade" ... they are upgrading their access to our data.

    2. beekir

      Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

      SFTP is almost nothing like FTP and was never supported by Chrome or Firefox.

      1. Mike 137 Silver badge

        Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

        "SFTP is almost nothing like FTP and was never supported by Chrome or Firefox."

        Yes. As the article stated "A lack of support for encrypted connections in Chrome's FTP implementation ..."

        So rather than implement the secure protocol they abandon the facility entirely in favour of a certainly proprietary and almost certainly opaque tool.

        1. Jon 37

          Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

          They have HTTPS, a secure protocol that can be used for file download. They don't need FTP as well. And browsers supported FTP for file downloads, not uploads.

          1. Zakhar

            Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

            FTP (and secure variants) are far superior to HTTP when it comes to uploads. But true, browsers are anyway not very good at uploads apart from basic stuff.

        2. doublelayer Silver badge

          Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

          "So rather than implement the secure protocol they abandon the facility entirely in favour of a certainly proprietary and almost certainly opaque tool."

          You're telling me that you can't find a single open source SFTP client? I can. Lots of them. CLI or GUI. Linux, Windows, Mac OS, all included. They're not new either. Most seem to support unencrypted FTP if you need that still. They're not proprietary. They're not opaque as the standards are well defined. And, unlike browsers, they support uploads as well. Use them.

          1. katrinab Silver badge
            Meh

            Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

            ftp still works in Windows Explorer if you don't like downloading things, or you are unable to.

      2. Arthur the cat Silver badge

        Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

        SFTP is almost nothing like FTP

        Agreed. However FTPS (port 990 with non-PASV data on 989) theoretically existed.

        The big question is, has anyone actually seen FTPS in the wild?

        1. Throatwarbler Mangrove Silver badge
          WTF?

          Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

          "has anyone actually seen FTPS in the wild?"

          Yes, usually exclusive of using sftp, and my first question is "Why the hell don't you support sftp?" I guess one argument in favor of ftp/s instead of sftp is that sftp by default uses port 22 (ssh), which might not be desirable.

        2. beekir

          Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

          I have and it was a pain to deploy and a pain to configure the clients, too. For whatever reason, FTP sessions can start in plaintext and then switch over to TLS mid-connection. It seems to break the whole purpose of TLS and I despised maintaining and supporting that mess.

          SFTP is so much easier to deploy.

        3. Coen Dijkgraaf

          Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

          "The big question is, has anyone actually seen FTPS in the wild?"

          Yes, if you work in the B2B integration space, it gets used quite often.

        4. Smartypantz

          Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

          That question is an embarrasingly small one, smartass, and the answer is yes. Us who actually do this IT-shit for a living still rely on the ability to transfer files between boxes in a secure manner. So we do it with both implicit and explicit FTPS in an opportunistic manner.

          1. Arthur the cat Silver badge
            Happy

            Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

            That question is an embarrasingly small one, smartass, and the answer is yes.

            Tetchy. Having a bad day are we?

        5. Anonymous Coward
          Anonymous Coward

          Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

          Yes, when you don't want to give SSH credentials to people needing to access a machine just to transfer files to/from some directories only. It could be simpler than having to neuter they SSH accounts to allow only some file transfers.

        6. Roland6 Silver badge

          Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

          >"The big question is, has anyone actually seen FTPS in the wild?"

          This question really needs to be caveated with:

          In a use case that required the usage of a web browser rather than a functionally specific piece of software that can be more easily sandboxed by the OS

          About the only time I worry about file transfer protocols is when I have to reset a bricked appliance and so am using the factory reset TELNET/TFTP interface to load a clean firmware image.

    3. bombastic bob Silver badge
      Devil

      Re: "frankly, Google and pals would rather users opted for a dedicated transfer app"

      I agree with you about sftp (and also scp and ssh when available). cPanel (and any equivalent) is one of those necessary evils for things like DNS or aliases or e-mail or otherwise managing services. But actual file management? No. Just No.

      I smell a new 0lugin for things like ftp in firefox. There WAS one for gopher but last I checked it is no more. Maybe a "legacy protocol" plugin for educational purposes at the very least...

  3. Doctor Syntax Silver badge

    I hope KDE don't follow suit with kio-slaves". I have an ancient but still functional Buffallo NAS device on my home LAN. My Brother all in one device saves scans to it. Older versions of KDE would let me open that via SMB but the device was SMB2 and support for that was dropped. However FTP access is still an option. I could add the functionality elsewhere but it would be another make-work to replace something that is good enough in its context. If someone can eavesdrop on my home LAN I have bigger problems than sending plain text passwords to see my scans.

    * Are they still allowed to call them that?

    1. Disgusted Of Tunbridge Wells Silver badge

      I don't see why they would, but you could use FUSE to mount the FTP server.

      1. Zakhar

        curlftpfs has a very naive implementation of things, but is should still work relatively well if you read one file at a time!

  4. Anonymous Coward
    Anonymous Coward

    You can't sell Advertising

    over FTP.

    1. Phil O'Sophical Silver badge

      Re: You can't sell Advertising

      You probably can. Put it in the README file in the FTP directory, and it will be displayed to a client on connection...

      1. DevOpsTimothyC

        Re: You can't sell Advertising

        The problem is that it's not google doing the selling

        1. doublelayer Silver badge

          Re: You can't sell Advertising

          The connection is not authenticated. You can inject anything you like into the readme when the user downloads it. Anyone willing to go that far can advertise or attack as they like.

          1. Anonymous Coward
            Anonymous Coward

            Re: You can't sell Advertising

            There's nothing to stop an FTP server implementing authentication against the user-password.

          2. Anonymous Coward
            Anonymous Coward

            Re: You can't sell Advertising

            Authentication has nothing to do with injecting using a man in the middle attack.

            1. doublelayer Silver badge

              Re: You can't sell Advertising

              Yes, you are right. I used authentication to mean that there was nothing ensuring the identity of the server to the user, as there is with a certificate. That's not the obvious meaning, and a better word would have been clearer.

              1. Lusty

                Re: You can't sell Advertising

                A certificate doesn't authenticate the source, it just means that someone bought a certificate that covers their server from a supplier on your trusted list who wanted money. 99% of FTP use cases don't involve a server the end user knows the name of, and increasingly people download blindly from amazon arbitrary named endpoints which have certificates but which you couldn't determine the owner of.

                SSL certificates are blind trust for authentication, their only purpose in reality is to encrypt traffic for privacy. If you don't need privacy they achieve nothing at all.

      2. jake Silver badge

        Re: You can't sell Advertising

        As a software developer who had multiple titles available via anonymous FTP in the early years of FOSS, I can assure you that almost nobody reads the README file ... or any other text file distributed with the code. Gawd/ess knows why the kiddies were so excited to get access to the source. I remember one friend included the comment "If you read this, you've won $100! Contact the author directly to be sent a check." in a header file ... he got no takers for the ten years that he owned that email address.

        1. Peter2 Silver badge

          Re: You can't sell Advertising

          Most people would assume either a joke or a phishing scam, and certainly wouldn't be sending their (physical) address.

          1. jake Silver badge

            Re: You can't sell Advertising

            Way to miss the point.

            As a side note, there weren't enough phishing scams for them to have a name back in the '80s. That didn't occur until AOL inflicted the online world with TheGreatUnwashed in the mid '90s.

  5. Dwarf

    Plenty of other choices for when you need to use it and on the plus side, less clutter in the browser.

    Perhaps it might even reduce the amount of RAM that Chrome seems to want to suck ... well, one can hope.

    Alternative FTP options include

    Another browser

    Linux command line ftp, and wget can do ftp too (but curl can't)

    Windows command line but no PASV iirc ??

    WinSCP

    BitKinex

    and a million other possibilities

    1. Bartholomew

      If I'm not using the command line.

      I like Filezilla, it provides sftp/ftp and works on Windows, OSX and Linux.

      1. Dwarf

        Don't fear the command line

        1. Bartholomew

          I've been using UNIX since 89, so no fear of the command line, it is my preferred home.

          1. Dwarf

            Somehow I missed the word "if" at the start of your previous posting.

  6. Anonymous Coward
    Anonymous Coward

    So....

    One more reason to avoid Chrome. Not that the list wasn't long enough already.

    1. Hubert Cumberdale

      Re: So....

      The list is indeed very long, but IMO this doesn't seem to add to it.

    2. IGotOut Silver badge

      Re: So....

      You do realise many other browsers dropped it some time ago, and my guess it's going to be Chromium that has dropped it, so see it dropped from plenty more soon.

  7. Elledan
    Meh

    Soon HTTP as well?

    When it comes to the thousands of public FTP servers out there that serve up everything from archived documents to publicly available software, it's always been convenient to just download these straight from the browser rather having to whip out the ol' FTP client.

    FTP has a massive benefit over HTTP here in that it is actually stateful, with a persistent connection and resuming downloads simply bloody works, instead of HTTP(S)'s adorable feature of having you start over a 1 GB download from scratch at 97% because your connection had a bit of a wobble.

    With the move to eliminate HTTP as well, I imagine that before long anything that isn't HTTPS (or HTTPA?) will be cordoned off except for those of us who still know our way around archaic tools that speak these obscure protocols.

    1. bombastic bob Silver badge
      Unhappy

      Re: Soon HTTP as well?

      if http disappears then a LOT of embedded devices may have trouble with web interfaces.

      It is often VERY hard to implement SSL within the confines of a tiny CPU's NVRAM code space, even for ARM devices. Eliminating http support would add unnecessary cost factors for embedded devices, or require you to use "the cloud" or some proprietary protocol/app.

      I have toyed with even an Arduino (with a network or wifi shield) serving up config pages. I even added graphics to it. Limited to ~30k of code space there's only so much you can do, but for a simple device it can "just work", maybe just to config the network interface, even.

      using https for that - just NOT possible.

      (and it becomes a road block for independent inventors and software developers)

      [and do you REALLY want to be FORCED to get an SSL cert JUST to have a private web server?]

      1. Clausewitz 4.0
        Devil

        Re: Soon HTTP as well?

        For embedded devices, please do not forget TFTP.

        I successfully implemented parts of UDP protocol code in C inside a PIC16Fxxxx from Microchip without much trouble, even with limited stack and flash space.

        Also, tftp is still available in both Windows / Linux / BSD by default.

        1. Smartypantz

          Re: Soon HTTP as well?

          TFTP is the most UNsecure protocol ever invented,. It was only ever used to load boot images on trusted networks in the old days.

          1. Clausewitz 4.0
            Devil

            Re: Soon HTTP as well?

            Yes, it is dirty; but still used and supported by Cisco and others embedded devices.

            1. Rockets

              Re: Soon HTTP as well?

              I mostly use FTP with Cisco devices for a number of years now, it's significantly faster than TFTP loading large images to network devices.

          2. Anonymous Coward
            Anonymous Coward

            Re: Soon HTTP as well?

            @Smartypantz not every connection needs to be secure or authenticated. For FTP transfer of things in the public domain there is no justification for either since you're not trying to hide the data from anyone (it's already available) and you don't care who downloads it (it's freely available).

            The level of security understanding on these comments is surprisingly poor for 2021.

            1. sten2012

              Re: Soon HTTP as well?

              100% - I see no difference between it and anonymous FTP in terms of security, except it has less attack surface (such as port bounce).

              It also has far worse user experience in general, but as that isn't the point of the post you were responding too...

      2. Richard 12 Silver badge

        Re: Soon HTTP as well?

        Exactly. Chrome's HTTPS implementation is completely unusable in a lot of circumstances.

        How do I access my private NAS over a private, airgapped LAN?

        Self-signed certificates are the most secure method available, yet none of the major browsers support these in a useful way.

        Firefox moans but lets me bypass - but not to say "this is the right cert, store it and never warn me about it ever again, but DO warn me if it changes"

        Last time I tried, Chrome just refused entirely.

        Yes, I could manually add the cert to the OS store, but as so many tools seem to ignore that...

        1. IGotOut Silver badge

          Re: Soon HTTP as well?

          "How do I access my private NAS over a private, airgapped LAN?"

          Well if it's "airgapped" you are completely unaffected by any and all updates, so keep using the old browser.

          Not hard was it.

        2. theOtherJT Silver badge

          Re: Soon HTTP as well?

          That whole blindly type "thisisunsafe" into the browser thing for self signed certs is the most fucking infuriating thing ever. No. No it's not. It is not unsafe. I am debugging a webserver! It is MY webserver! This is about the safest connection I ever will make; seeing as it's going to fucking localhost!

          1. Anonymous Coward
            Anonymous Coward

            Re: Soon HTTP as well?

            Oh fuck. That "thisisunsafe" thing lets you bypass Chrome's asinine refusal to accept invalid SSL certs? I had no idea, never heard of it. Holy shit, I got stuff I need to try out now...

            Thanks.

        3. Clausewitz 4.0
          Devil

          Re: Soon HTTP as well?

          I understand your frustration with self-signed certificates in the majority of internet browsers being so difficult to accept their use. But there is a clear explanation for that - if it was easy to users to accept self-signed certificates, malware authors targeting banks could take advantage of that also. It is still easy to modify the process of an internet browser to get bank credentials purely in RING3/usermode, but more debug/decompiling and patching in memory are necessary.

      3. Warm Braw

        Re: Soon HTTP as well?

        or require you to use "the cloud"

        It would equally add cost to securely communicate with "the cloud", but of course it's cost you can recover through monetization, whether that be subscription fees or managing the lifetime of connected hardware to ensure continued upgrades.

        When it comes to security, security of revenue will trump all other considerations.

        1. jake Silver badge

          Re: Soon HTTP as well?

          And of course using the cloud increases the size of the attack surface immeasurably.

          OK, maybe it's technically measurable ... but do you really think your cloud provider is going to let you audit their internal processes?

    2. Anonymous Coward
      Anonymous Coward

      Re: Soon HTTP as well?

      I doubt it as many computer engineers at Google use HTTP during development. "Headless Chrome" is a mode of Chrome specifically made for development and testing. It would be a meaningless complication to enforce HTTPS during development.

    3. Adrian 4

      Re: Soon HTTP as well?

      It's also quite convenient to use wget from the command line to download a file instead of firing up megabytes of browser. Not everything HAS to be in the browser.

      And it doesn't try to secondguess your URL and convert a reference to a local machine's filestore into some global link (which, of course, fails).

  8. bigtreeman

    git, wget

    I mainly use git these days.

    ftp ?

    wget, and don't care if it's on an ftp server but it is generally http or https

    but the dedicated downloaders are generally redirecting me to other shit I don't want to see.

    when was the last time you used command line ftp ?

    1. Smartypantz

      Re: git, wget

      Yesterday, because i do this for a living and live in the real world.

      Let me guess: You identify as a "developer"?

      We cant all just sit around scratch our asses/navels and "use git" to load the tons off bullshit you need to "develop" the next , agile version of "hello world".

      Some of has to get shit to work IRL.

    2. Rockets

      Re: git, wget

      I'd use command line FTP almost daily doing my job, but that's almost always on the corporate WAN and not over the Internet. I never use git, just because you don't use something doesn't mean that others don't nor there still isn't a place for it. It doesn't really bother me that Chrome killed FTP support either though, I did use it from time to time but most public mirror FTP servers that I'd use it for also support http/https.

    3. jake Silver badge

      Re: git, wget

      I use command line FTP daily.

  9. JBowler

    50 years ago, when I was 11

    >the protocol is over 50 years old and comes from more innocent times, when authentication was not what it is today

    Those days I didn't trust anyone on the street. I didn't trust stuff written in the Guarniad either, though the Times (pre-tits-days) was, of course, a source. Just that.

    That was the time of Thatcher, a person without redemption, whose publicist BoJo perhaps changed the world for the worst [sic].

    These days I'm almost like you guys; I almost trust no-one. Except FTP requires I trust myself to evaluate the stuff I receive without, in any way, trusting it.

    This is, of course, Irony if you don't understand what I am saying, otherwise it is Sarcasm and this post should be immediately deleted lest innocents learn.

    1. Anonymous Coward
      Anonymous Coward

      Re: 50 years ago, when I was 11

      Do you trust your own judgement?

      1. jake Silver badge

        Re: 50 years ago, when I was 11

        If I didn't, I'd probably pack it in.

    2. IGotOut Silver badge

      Re: 50 years ago, when I was 11

      "This is, of course, Irony if you don't understand what I am saying, otherwise it is Sarcasm and this post should be immediately deleted lest innocents learn"

      What?

    3. Anonymous Coward
      Anonymous Coward

      Re: 50 years ago, when I was 11

      Being authenticated by SOMEONE ELSES SERVER should not make you trust that person. If they don't give a shit who you are, why would they authenticate you? What if there are a million downloads, will you be creating the accounts for authentication?

      Think McFly, think!

      1. jake Silver badge

        Re: 50 years ago, when I was 11

        Evaluating stuff downloaded via FTP, and thus residing on my system, doesn't require the help of anybody else's server.

        I AM thinking, B1FF.

  10. Allan George Dyer
    Facepalm

    It might still creep back...

    I got rid of ftp years ago. Then I got a multi-function printer that used it to upload scans, so I found myself reinstalling an ftp server, strictly internal only of course.

    The last time I used it on the internet was for uploading documents to a printing company. Anonymous ftp, just drop it in the right directory. I could also browse projects from their other clients. They didn't seem concerned by the security implications.

    1. jake Silver badge

      Re: It might still creep back...

      I still pull files off read-only FTP sites occasionally. Mostly drivers/shims for ancient hardware, zipped or tarred files containing technical documentation, photos of old boards and wring, and that kind of thing.

      My FTP server has family photos and the like uploaded by various family members to their own space. Other family members can browse the individual collections if they are logged onto the server. Security implications are minimal. We did have one teenager park some Pr0n on his space ... he's lucky I found it before his grandmother did.

      FTP moves files around internally in my private USENET system, when I'm not using UUCP.

      ::shrugs::

  11. a_yank_lurker

    Use?

    FTP strikes me as a rarely used protocol. It has been a few years since I have used FTP. In fact I had forgotten about it being available in any browser.

    1. Anonymous Coward
      Anonymous Coward

      Re: Use?

      FTP in the browser? Never really used it.

      FTP with specific clients and applications? Useful.

      For example I have cameras that can upload photos while shooting via FTP (via Ethernet or WiFi). The advantage is the setup is simpler and faster than setting up a web server to perform the same task. Not something you may wish to use across the Internet (without a site-to-site VPN ), but very useful locally, even if it means uploading to a laptop.

      Latest models can also transfer via HTTP(S) - but they do using a gateway managed by the camera maker - that means the camera uploads there, then you download from there. That avoids them to have to deliver the software to be installed on customers' web servers to manage the transfer - and having to test if for different web servers and operating systems. You get the download utility, which is simpler to write. But sometimes you can't or don't want to go through an outside system.

      Maybe they could have used WebDAV - but for some reasons it's a protocol that never became really commonplace.

  12. YetAnotherJoeBlow

    I just used ftp today to update octave (in a vpn.)

  13. chivo243 Silver badge
    Headmaster

    Use a dedicated app!

    Why not a dedicated App for Meet for crying out loud! Really, Meet totally kills performance across the board. Zoom is superior iMHO.

  14. chileboy

    I don't know why, but it makes me sad.

  15. Chuunen Baka

    FTP in the browser feels like a hang-over from the early days of the web. I was using the internet before HTTP was a thing. Having FTP URLs was fairly common before real web servers evolved. Can't see a need for them now.

    1. jake Silver badge

      FTP existed long before the Web existed. In fact, FTP existed before TCP/IP existed.

  16. Naich
    Pirate

    Aaar anonymous FTP

    I remember the good old days of anonymous FTP and poorly configured servers that anyone could write to. Finding a directory called "..." and following it to the warez treasures contained within. Kids these days with their dark webs and torrents don't know they are born.

    1. jake Silver badge

      Re: Aaar anonymous FTP

      It wasn't FTP that was at fault, it was those administering the site that had problems.

  17. Jan 0 Silver badge

    Other protocols?

    What protocols other than https can be addressed in modern browsers?

    I cseem to remember using telnet://xxxxx.xx addresses in a browser, long ago.

    1. jake Silver badge

      Re: Other protocols?

      Some are listed here:

      https://en.wikipedia.org/wiki/Comparison_of_web_browsers#Protocol_support

      Presumably somebody with an interest in such things has a more complete list posted somewhere online, but a casual DDG on the subject doesn't turn up anything useful.

  18. /dev/null
    Headmaster

    50 years ago?

    Internet FTP, ie. FTP over TCP, was first defined in RFC765, published June 1980. The first RFC describing a file transfer protocol was RFC114, which was indeed about 50 years ago. However that was an ARPANET protocol and really quite different to the protocol described in RFC765.

    1. jake Silver badge

      Re: 50 years ago?

      Yes, TCP/IP and NCP are different. However, to all intents and purposes, FTP worked the same from a user's perspective. It worked over Netware and SNA, too. And a bunch of other networking systems. Portability in this manor was designed in, right from the git-go.

  19. Binraider Silver badge

    I still begrudge Gopher protocol support being ditched. But then I would, because I was a BBS nerd.

    1. jake Silver badge

      Me 107 year old Great Aunt, who has been using Gopher to publish her life's story for decades, thinks that it is evil to remove perfectly good tools from the hands of people who don't want to learn a new system TO DO THE EXACT SAME THING. Especially when those tools are, to all intents and purposes, finished, and thus require minimal upkeep.

      Fortunately, she has me to run the server and keep her old tools running.

  20. martinusher Silver badge

    But...surely HTTPx uses FTP as its primary file transfer mechanism?

    I may be a bit out of date but I'm pretty sure that the same basic protocols are used by both FTP and HTTP (and by extension its variants). They both use TCP as the underlying transport, framing the transactions using a three decimal digit code to manage the request/authentication/transfer protocols. The only difference is that originally HTTP used a simple encoding scheme to transfer binary data into 'readable' data.

    What I think we're seeing here is what we could call 'technology creep'. As sucessive generations of programmers work on the software they layer new protocols o top of the originals, ultimately forgetting what the underlying mechanisms are and how they worked. This is the reason why generations of programmers have built message oriented transactions on top of TCP -- they haven't a clue what it is or how it works but know its 'reliable', all it is to them is a parameter they use when they open a socket. (If they thought about it a bit they should be basing the stuff on UDP but, "whatever", they're not to know about the decrease in reliability and the extra traffic and complexity caused by using TCP. Then there's the constant reinvention of the wheel -- never use FTP (or even SFTP) when you can write some code to practically the same thing (I don't know what any knew mechanism would be like but its probably built around numbered blocks and CRCs -- there really aren't a whole lot of ways to move data from 'A' to 'B').

    Its unimportant to me. I don't use FTP inside a browser. I want to see what I'm doing.

  21. BART BARFSALOT
    Gimp

    Removing TP Rolls

    "In between 76 and 86, Google tinkered with defecation deprecation, backing away in the first half of 2020, in response to the fart-fandemic and the pantsloads faeced hardpressed by IT crews. However, the writing was on the bathroom wall for the venerable TP protocol."

  22. rmstock

    whats wrong with FTP ?

    In 1991 someone in the Math Dept. grabbed my elbow and pulled me to a DECstation and wanted me to show the Internet. He said type this in : ftp ftp.funet.fi I said what does this do ? It connects to a server in Finland so can you download all their files. At that moment i decided to reduce my PhD efforts and concentrate on all aspects Internet. Did ftp.funet.fi have problems with ftp ? No of course not. Why does Google have problems with ftp today ? Oh wait its Google who has problems with the entire world now. Obviously today Google is China controlled, so who is Google to snuff out ftp ?

    Recently the Big Browsers like google chrome and now also opera have switched ftp off by default, labeling it a "dangerous" experiment. If you know the dangers you can still use ftp:// from your browers . Here's how to enable old-style ftp inside opera https://crashrecovery.org/opera-ftp/ As of opera-stable_78.0.4093.147 the Big Browsers came to the conclusion that the ftp:// experiment had become to dangerous. If you know the dangers you can still obtain the older versions and are available here https://crashrecovery.org/opera/DEBS/

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like