Slashdot Mirror


Firefox Follows Chrome and Blocks the Loading of Most FTP Resources (bleepingcomputer.com)

Mozilla says it will follow in the steps of Google Chrome and start blocking the loading of FTP subresources inside HTTP and HTTPS pages. From a report: By FTP subresources, we refer to files loaded via the FTP protocol inside img, script, or iframe tags that have a src="ftp://". FTP links placed inside normal angle bracket links or typed directly in the browser's address bar will continue to work. The reasoning is that FTP is an insecure protocol that doesn't support modern encryption techniques and will inherently break many other built-in browser security and privacy features, such as HSTS, CSP, XSA, or others. Furthermore, many malware distribution campaigns often rely on compromising FTP servers and redirecting or downloading malware on users' computers via FTP subresources. Mozilla engineers say FTP subresource blocking will ship with Firefox 61, currently scheduled for release on June 26.

89 comments

  1. Re:DONALD DRUMPF by Anonymous Coward · · Score: 1

    You know what would help getting your message across? Writing correctly.

  2. Why FTP? Why not an HTTPS CMS site? by xxxJonBoyxxx · · Score: 1

    How is it any easier or better to compromise an FTP server to serve "subresources" as opposed to a crappy WordPress or Drupal site running HTTPS?

    1. Re:Why FTP? Why not an HTTPS CMS site? by Anonymous Coward · · Score: 1

      Shh! Google said this is a good idea. Google can not be wrong. /s

    2. Re:Why FTP? Why not an HTTPS CMS site? by CreamyG31337 · · Score: 4, Interesting

      It's doesn't need to be easier or better -- it's just another attack surface that CAN be compromised, meaning that there are plenty of FTP servers out there which are misconfigured and can be used to serve malware. Due to the latency logging in and requesting a file via FTP, no webmaster should purposely configure a site to pull a page's resources from an FTP, so it makes sense to cut it off.
      As for why it's easier or better, a badly configured FTP server is probably more likely to stay that way because the hackers hide the files and are only using disk space and bandwidth. Something like a CMS will tell you "please update me" every time you log in as admin to patch holes. Your FTP isn't going to tell you that you're a shitty admin.

    3. Re:Why FTP? Why not an HTTPS CMS site? by Anonymous Coward · · Score: 0

      False dichotomy. A better question would be: if you're visiting a website that, unknown to you, is actually a crappy WordPress site that has already been compromised, would you like your browser to bypass privacy and security features in order to load FTP resources or would you rather just skip those resources?

    4. Re:Why FTP? Why not an HTTPS CMS site? by Anonymous Coward · · Score: 0

      Many FTP servers have a MOTD option. They could tell you that information there.

    5. Re:Why FTP? Why not an HTTPS CMS site? by scdeimos · · Score: 1

      One could argue that the FTP protocol is actually more secure because it doesn't serve up Cookies for scumbag companies like Apple, Facebook, Google and Microsoft to track your traffic.

      If Mozilla and Google were serious about security they'd block Wordpress sites by default.

  3. TIL by bobstreo · · Score: 2

    There are still ftp servers. /s

    Seriously, why not move to block HTTP traffic? It's not secure, it can serve malicious pages, and spoof real sites...

    1. Re:TIL by KiloByte · · Score: 1

      Or block https not secured by DANE. Oh wait, implementing DANE in the browser was WONTFIXed by Mozilla. Yay for every single state-sponsored attacker controlling at least one CA.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    2. Re:TIL by Anonymous Coward · · Score: 1

      That's coming. The same browsers that are removing support for FTP want to remove unencrypted HTTP too. HTTP/2 is not in wide use yet, but the browsers already refuse to accept HTTP/2 content if it's unencrypted.

    3. Re:TIL by Anonymous Coward · · Score: 0

      This isn't removing FTP - it's abstaining from automatically loading FTP subresources on HTTPS pages.

    4. Re:TIL by Anonymous Coward · · Score: 0

      they start with the smaller targets...

    5. Re:TIL by thegarbz · · Score: 1

      Seriously, why not move to block HTTP traffic? It's not secure, it can serve malicious pages, and spoof real sites...

      Security is only a very small part of it. The point is also that there's a fundamentally different protocol, a woefully chatty and inefficient one at that serving content within pages. Note FTP isn't being blocked, just FTP content within HTTP.

      Honestly whoever thought this was a good idea in the first place should have been taken out behind the shed and shown some 2nd amendment rights in action.

    6. Re: TIL by Anonymous Coward · · Score: 0

      Funny you bring up the 2nd Amendment where that same argument structure is used.

      We're not banning X, we're banning X in Y. Totally different. /s

      It isn't, and it is just one more move by the tail of browser developers to wag the dog of the Net.

    7. Re:TIL by scdeimos · · Score: 1

      HTTP/2 is not in wide use yet, but the browsers already refuse to accept HTTP/2 content if it's unencrypted.

      Source? The Kestrel web server used for ASP.NET Core uses HTTP/2 by default and I've never seen a browser refuse to load output from it.

    8. Re:TIL by AmiMoJo · · Score: 1

      Seriously, why not move to block HTTP traffic?

      It's happening. Chrome already flags HTTP sites as insecure, and won't load HTTP content on mixed HTTP/HTTPS pages.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  4. Making money, tracking cookies. by OrangeTide · · Score: 5, Interesting

    Google, Facebook, Amazon, Apple, Microsoft, and many others wish to end the hobbyist Internet.

    FTP lacks cookies to track views. And FTP is hard for search engines to index with useful metadata for advertisers.

    --
    “Common sense is not so common.” — Voltaire
    1. Re:Making money, tracking cookies. by xxxJonBoyxxx · · Score: 3, Insightful

      >> FTP is hard for search engines to index

      (Remembers Gopher. Feels old.)

    2. Re:Making money, tracking cookies. by Rockoon · · Score: 1

      Gopher didnt have much to do with FTP, however Archie was the first search engine.

      --
      "His name was James Damore."
    3. Re:Making money, tracking cookies. by Anonymous Coward · · Score: 1

      You're thinking of Veronica, that was the search engine for Gopher.

    4. Re:Making money, tracking cookies. by OrangeTide · · Score: 1

      Floodgap Gopher proxy is still alive and kicking. And even Veronica-2 is quite usable. There are a few folks who publish their blogs on Gopher (as well as HTTP). And in a weird way the structure of Gopher makes a lot of sense for blog/journal content. (I don't blog, but I'd like to if I could be motivated to write about something)

      --
      “Common sense is not so common.” — Voltaire
    5. Re:Making money, tracking cookies. by eneville · · Score: 1

      And FTP is hard for search engines to index with useful metadata for advertisers.

      I think it is somewhat easier for a search engine to 'list -al' the directory to see which timestamps have changed compared to performing a HEAD on each request, parsing the content and spidering. If a robots.txt exists, great, is is accurate? Dunno, will have to index anyway and see.

    6. Re:Making money, tracking cookies. by thegarbz · · Score: 2

      Horseshit, more importantly there was no reason at all to serve live content in a HTTP page via FTP in the first place. All you effectively do is break the efforts to optimise HTTP by introducing a random and woefully slow and inefficient protocol into part of the page rendering.

      Really this should have been blocked from the onset.

    7. Re:Making money, tracking cookies. by Anonymous Coward · · Score: 1

      If you are loading FTP resources on an HTTPS site, you are doing it wrong.

    8. Re:Making money, tracking cookies. by OrangeTide · · Score: 2

      There are reasons, even if none of them apply to your own situations.

      --
      “Common sense is not so common.” — Voltaire
  5. Not that big a fan of ftp in html, but... by Junta · · Score: 1

    I'm not sure I grasp the logic of treating ftp distinct from http (no s) from a security perspective?

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Not that big a fan of ftp in html, but... by whoever57 · · Score: 2

      I'm not sure I grasp the logic of treating ftp distinct from http (no s) from a security perspective?

      I don't think they are. This is just the same as blocking http: resources that are loaded from an https: page (mixed content blocking).

      --
      The real "Libtards" are the Libertarians!
    2. Re:Not that big a fan of ftp in html, but... by thegarbz · · Score: 1

      You can start with the three acronyms in the summary. None of them work with FTP.

    3. Re:Not that big a fan of ftp in html, but... by Junta · · Score: 1

      Ok, but it also says mixed content for http, and I would think in principle, http and ftp would be considered equivalent security....

      The whole point of urls after all was to include protocols and have flexibility to have fit-for-purpose protocols. Nowadays the only protocol is http, and when it isn't, we must shoehorn it into http. This has been disappointing and pretty senseless (at this point, arbitrary TCP style protocols are possible to implement on top of http and this is somehow considered more sane than just having tcp based protocols.... somehow?)

      My disappointment is a bit more academic I suppose, in practice ftp servers are a cesspool of sloppy and lazy admins, even if the protocol itself is theoretically the same, sometimes the practical answer is to consider the wider reality of how that protocol has been implemented and deployed.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    4. Re:Not that big a fan of ftp in html, but... by Junta · · Score: 1

      HSTS means nothing to http (no s)
      I *suppose* the other headers requesting browser behavior aren't part of ftp and that could matter. If embedded in an http(s) hosted html page,I would have thought that page should have had all those relevant security headers, and those security headers should already be blocking ftp content from loading as part of such pages if configured...

      --
      XML is like violence. If it doesn't solve the problem, use more.
    5. Re:Not that big a fan of ftp in html, but... by thegarbz · · Score: 2

      HSTS means nothing to http (no s)

      HSTS means everything *specifically* to HTTP when there's no S. That's the fundamental point of HSTS to prevent protocol downgrade away from secure, and something that by nature does not work with FTP because there's no equivalent.

      And before you dismiss this just remember that half of the attacks on encrypted connections via the internet in the past several years have been due to downgrade attacks, and every single protocol change and advancement has specifically attempted to mitigate this.

      FTP wasn't mitigated.

      FTP in this scenario also serves zero purpose what so ever.

      No one is sad about this change. Your FTP server will continue to work just fine when you're using FTP, something that fundamentally should never serve content within a HTTP page anyway.

  6. Assholes.. clueless assholes by Anonymous Coward · · Score: 0, Troll

    Been using ftp URI's for years, why? It just works and due to transparent proxies, tends to work better then HTTP(s).

    Can we please make age a requirement at these companies? Swear to god they're all fresh out of Highschool with no fucking clue how the Internet works, worked, nor should work. What they care about are resume line items and that is pure bullshit.

  7. Wow, by Anonymous Coward · · Score: 0

    Firefox following Chrome,...again. Color me impressed.

  8. Yet more breakage from Mozilla. by Anonymous Coward · · Score: 0

    Enterprise sites and developer sites rely on FTP. In related problems you can no longer download Firefox on default Windows XP. bug here

  9. down with ftp by Anonymous Coward · · Score: 0

    bring back gopher.. and veronica.. and archie... ya know, from back when they knew now to name shit on the internet.

  10. How do you turn it off? by drinkypoo · · Score: 0

    That's the only information I need. I'll decide whether I want to visit an FTP link or not, thanks.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    1. Re:How do you turn it off? by Anonymous Coward · · Score: 0

      The reverse is probably better.. Turn it off by default to help the sheeple. Let me enable it easily.

    2. Re:How do you turn it off? by thegreatbob · · Score: 3, Informative

      Doesn't appear to be blocking <a href= tags, but rather things such as iframes that automatically load content.

      --
      There is no XUL, only WebExtensions...
    3. Re:How do you turn it off? by Anonymous Coward · · Score: 1

      The are not blocking you from links. Read again.

    4. Re:How do you turn it off? by drinkypoo · · Score: 1

      Doesn't appear to be blocking <a href= tags, but rather things such as iframes that automatically load content.

      Regardless, Firefox isn't qualified to decide which of those things to load. I have several extensions loaded which handle that, because they are.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    5. Re:How do you turn it off? by thegarbz · · Score: 1

      You don't need to turn anything off. Links to FTP not only will continue to work but they are actively improving FTP functionality within Firefox.

      What is being blocked is just somet stupid idea that the occasional web designer who can't spell their own name thought may be a good idea when creating a page. Although really I prefer functionality that instead of blocking this, uses Facebook's data trove to identify them, and then call the men in white coats to put that developer in a room with pillows for walls because quite frankly if serving HTTP content via FTP isn't a sign of a serious mental conditions I don't know what is.

  11. Yes, but.... by Anonymous Coward · · Score: 0

    I hope they spend as little time as possible on this new FIrefox and put more effort into maintaining old versions.

  12. Good. Kids should stay in their cribs. by Seven+Spirals · · Score: 2

    The Chinese, Russians, and Indians are constantly beating on my FTP server. Well, they would be if I hadn't GeoIP blocked them (proftpd module feature). Hopefully, not being able to use FTP sites as a pivot, their interest will wane (but I'm not counting on it). I dislike FTP's mult-port design, but it's got far more full-featured servers versus something like a web server will give you (compare ProFTPd with Apache - no contest for file service, not even at all close). I hope the newschool Internet folks will just stay on their smart phones and fuck off and forget FTP exists. The problem is that when masses of idiots decide something is "the new way" they will try crap on "the old way" despite it still being useful or even required. So, I expect ISPs will think they need to block it or whatever. If it won't load up with lynx/elinks then I'm not interested anyway, HTML stopped serving normal people and started serving corporations and graphic designers after HTML 1.1.

    1. Re:Good. Kids should stay in their cribs. by freeze128 · · Score: 1

      FTP implementation in web browsers has always been terrible. It's difficult to select multiple files, and forget selecting multiple files in multiple directories. Uploads are often no supported. If anyone really wants ftp, they should use a proper client.

    2. Re:Good. Kids should stay in their cribs. by rahvin112 · · Score: 3, Informative

      Every time you log in to your FTP server remotely you pass your login credentials in the clear. FTP is ancient and unsecure and should be abandoned.

    3. Re: Good. Kids should stay in their cribs. by Z00L00K · · Score: 1

      Ever tried to do a tenex setting from a web browser for a ftp session?

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    4. Re:Good. Kids should stay in their cribs. by Anonymous Coward · · Score: 0

      Maybe every time you log in you let credentials go in the clear. However, TLS doesn't care about the layers above it, and there are RFCs that standardize encrypting both the control and the data connections.

    5. Re:Good. Kids should stay in their cribs. by Anonymous Coward · · Score: 0

      So how about FTPS?

    6. Re:Good. Kids should stay in their cribs. by Anonymous Coward · · Score: 0

      So how about FTPS?

      Serious question: why not just use SFTP? Specifically, an SSH server that chroots using "internal-sftp" in the config file? You can hardly ask for a simpler or cleaner setup. That's likely because it was designed to be secure from the ground up, rather than bolting TLS/etc onto a fundamentally insecure protocol.

    7. Re:Good. Kids should stay in their cribs. by Seven+Spirals · · Score: 1

      Serious answer: Because before you had something like ProFTPd supporting SFTP, the features in the sftpd-server that comes with OpenSSH were a joke compared with the competition (again, ProFTP is the best example). I mean SFTP was missing many many features that some folks can't go without. So, up until that point, which was somewhat recent, FTP was your best option for supporting the dozens of features missing from SFTP that were present in FTP servers. Nowadays thanks to ProFTPD, the answer is "you can now switch to SFTP without having a completely different experience." Of course, that doesn't mean all the nice FTP clients out there have workalikes on the SFTP side, but since folks already have some fairly decent SFTP clients, that shouldn't be a huge issue. There are only two other issues to fight about. The first is the reproducible fact that SFTP is like 5x slower than FTP in most cases over a fast LAN due to the encryption overhead. For Internet users that's no big deal, they aren't going to be moving files at 100MB/s anyway. The last is the fact that older systems which integrate FTP client or server protocols will be shut out, and not all of those use-cases require the high security; so it's just a kick in the shins for no reason for those folks if ISPs or others get aggressive about blocking FTP (hasn't happened yet, I know).

    8. Re:Good. Kids should stay in their cribs. by Seven+Spirals · · Score: 1

      It does pass traffic in the clear if you are dumb enough not to use TLS, yes. However, there is also the fact that many many applications don't have big security concerns and they operate in an environment where not every client may have an effective SFTP workalike to solve the problems a switch would create. It's fine to hand-wave away someone else's concern when it's not your rig to re-create the "secure" way. There is also the fact that until ProFTPd got an SFTP module there were shittons of missing features from sftpd-server compared to many FTP servers and especially ProFTPd. You can get on /. and be all imperious about it, but if you were one of those folks using one of those features I doubt you'd be so flippant with your "ancient and should be abandoned" comment. Unix is old too, so is TCP/IP should we throw those babies out with the other "old" stuff bathwater just because for some people in some use cases might be better off with SFTP? Stop proffering logical fallacies. Being old doesn't make it bad, neither does the fact that it doesn't use encryption. What makes it bad is when you *use* it in a situation where you are putting the credentials at risk. I know lots of folks using FTP on their local LAN. Should they take a 5x performance hit for the encryption? That'd be dumb in my opinion. Use the right tool for the job, not "the most secure" tool when security isn't even a concern in some cases.

  13. FF has 1 foot in the grave by Anonymous Coward · · Score: 0

    Why would anyone still use Firefox? Palemoon is what Firefox should still be. I switched to Palemoon months ago and have had no issues. FF is dying. Just look at statcounter. FF's market share continues to go down. In a year or 2 it won't even show up on their graph.

    1. Re:FF has 1 foot in the grave by Anonymous Coward · · Score: 0

      Why would anyone still use Firefox? Palemoon is what Firefox should still be. I switched to Palemoon months ago and have had no issues. FF is dying. Just look at statcounter. FF's market share continues to go down. In a year or 2 it won't even show up on their graph.

      I followed that link and don't see Palemoon on there at all.

    2. Re:FF has 1 foot in the grave by Anonymous Coward · · Score: 0

      Palemoon shows up if you download the stats. My point was more that FF is dying than that Palemoon is rising. But I hope that as FF dies that forks (Waterfox, Palemoon, etc.) will rise up.

  14. If it's not broken, don't 'fix' it. by CptLoRes · · Score: 1

    FTP is an old and established protocol. And when is the last time you hard it causing major security problems? Seriously, this is breaking just for the sake of breaking stuff..

    1. Re:If it's not broken, don't 'fix' it. by Anonymous Coward · · Score: 1

      FTP *is* broken.
      I've already had the "pleasure" to open a firewall to allow FTP traffic, it's a nightmare.
      Between the passive mode, the active mode and the guy on the other end that doesn't know how it really works, it's always a hassle to get it working right.

      I sincerly hope that FTP dies... fast.

    2. Re:If it's not broken, don't 'fix' it. by thegarbz · · Score: 1

      FTP isn't being fixed.

      The use of FTP to serve content inside HTML pages however is a horribly frigging broken concept that should have been aborted at birth. It deserves to be "fixed" in that regard.

      Nothing isn't being broken that wasn't a broken idea in the first place.

    3. Re:If it's not broken, don't 'fix' it. by Anonymous Coward · · Score: 0

      Nothing isn't being broken that wasn't a broken idea in the first place.

      That's never before stopped people from whinging about it. It won't now due to the popularity of investing in broken ideas (because understanding the basics about how things work is just so hard). This is all rather standard. Then everyone moves on. Knowledge of this pattern from having seen it in the past indicates this is a right decision.

  15. I've been blocking port 21 for over 10 years by neo-mkrey · · Score: 1

    What took Google and Mozilla so long?

  16. Oy by RightwingNutjob · · Score: 0

    I'm waiting for Firefox to automatically put black bars over profanity and refuse to show images that aren't cryptographically signed by a consortium of SLPC, Snopes, and Politifact.

    Seriously...why do these people think it's their business to control the form of content displayed in their browsers? If it's valid HTML, served over a valid protocol, it should display. Otherwise the browser is broken.

    1. Re:Oy by thegarbz · · Score: 1

      Seriously...why do these people think it's their business to control the form of content displayed in their browsers?

      Because the use of the protocol is inefficient, a stupid idea from the onset, and breaks compatibility with many security processes introduced in browsers over the past few years.

      Even if it wasn't a security issue it shouldn't be allowed because it would be a stupid fucking idea like embedding the remainder of this post within a magnet link or some crap like that.

    2. Re:Oy by RightwingNutjob · · Score: 2

      The browser's job is to display a page as written in conformance with standards. If the standards allow protocols besides http or https for fetching resources, then too fucking bad if the protocols are not to your liking, it's still valid.

    3. Re:Oy by thegarbz · · Score: 2

      And that is precisely the point. The HTTP standard says nothing about using FTP to fetch content mid page. That entire functionality is the curious quirk that started with a browser becoming an FTP client so that it could download files that were presented as links rather than having to open a separate app. It is not and was never meant to be in any way shape or form a way of delivery content within a page.

      The standards don't allow for it.
      The standards don't forbid it.
      That doesn't mean we should just blindly do it because it makes no fucking sense, breaks attempts at preventing cross-site scripting, data injection and protocol downgrades, and above all it's the most laggy and inefficient way to fetch and display content. It doesn't break a standard, but it prevents standards from being implemented properly.

  17. Only FTP? by eneville · · Score: 3, Insightful

    This makes no sense to me whatsoever. I fear there is a greater quantity of exploited HTTP(S) servers out there than FTP. Is this not akin to removing telnet from Windows? The loss of functionality does not match the gain in security (is there any?). Surely the first step should be to prevent malicious content, not prevent a protocol.

    Are Mozilla thinking to block FTPS too? What about sftp (if it were ever to be introduced), would that count too?

    If the argument is that the protocol is plaintext, then HTTP should be dropped.

    1. Re:Only FTP? by Anonymous Coward · · Score: 0

      The sftp! No! We are the FTPS, and the only thing we hate more that HTTPs is the sftp!

    2. Re:Only FTP? by Anonymous Coward · · Score: 1

      Is this not akin to removing telnet from Windows?

      No. Why? Because it is not removing ftp - this is stopping the ability to load resources from an ftp resource when loading a http/https page.
      Do you think that there are many decent web designers that are loading their images/pages from an ftp site?

    3. Re:Only FTP? by Anonymous Coward · · Score: 0

      I propose we make an SFTPS protocol. This way we don't have to choose which side the "S" letter is on.

    4. Re:Only FTP? by eneville · · Score: 1

      I don't think there are many descent web designers.

    5. Re:Only FTP? by thegarbz · · Score: 1

      The loss of functionality

      What loss in functionality? You do realise Firefox will continue to support FTP right, and if you post a link to an FTP site it will work just fine right? The only "fuctionali", and I use that term very losely, that is lost is the ability to embed an FTP based resource in a webpage, which is a horrible frigging idea. What do you think is faster:

      GET this image.
      200 OK here is this image.

      Or

      Hello
      Hi, I'm your FTP server.
      Hi I'm anonymous.
      Hi anonymous do you have a password for me?
      No I'm anonymous.
      Ok my bad, what can I do for you? By the way you will need to switch to binary mode.
      Well we're talking using this outdated piece of shit that didn't take into account that most people are behind NAT, so let's talk passively.
      227 Passive mode is okay by me. Please connect to me again on port 2990 when you transfer data to me.
      GET this image.
      200 OK
      Wait one sec: Connecting to port 2990.
      here is the image.
      quit
      221 Goodbye

      Anybody web designer who considers this "functionality" for serving mid page content should have all their fingers broken so they feel some proper pain when they type.

    6. Re:Only FTP? by eneville · · Score: 1

      Anybody web designer who considers this "functionality" for serving mid page content should have all their fingers broken so they feel some proper pain when they type.

      Really? There was a time when it was not as simple to have HTTP servers everywhere. There could still be situations where FTP could be faster. Many HTTP servers require more memory than FTP, and, all things being equal there could be real situations where an FTP may be faster than an HTTP, badly written mod_perl/mod_php that sits at the header processing stage could make HTTP perform worse than FTP. Maybe just to take load away from the HTTP you might decide to put that traffic through FTP if its static. This could be quite rare, and you wouldn't be going through all the faff that a normal FTP client goes through on login since you know ahead of time where the content is so you'd likely PASV, BINARY then GET. Yes, would likely be much slower since these would be synchronous but I can see an edge case where a "developer" may be in a bind.

      This shouldn't, and if the developers are competent, wouldn't affect many people at all.

    7. Re:Only FTP? by thegarbz · · Score: 1

      Sorry but I don't see a single use case for any of your points. Let's go through them:

      - It was not simple to have HTTP everywhere. It was not. It is now. We are talking about a change that is happening in 2018.
      - HTTP needs more memory. - We'll ignore the fact you can run a HTTP server on an ESP8622 with it's whole 80KB of RAM for the moment. Instead let's focus on the fact that this is talking about FTP delivered within HTTP so there is no saving to be had, if you want to save RAM dump the superfluous FTP server and just server up HTTP content like a normal website.
      - Poorly written mod_php? Why are you doing anything with mod_php? I thought you were out of RAM?
      - Sub point: If you need php for anything than an FTP server simply isn't going to cut it.
      - The load on FTP will be worse than for HTTP. There's nothing complicated in HTTP unless you want to make it complicated. There's no benefit to offloading onto FTP instead of another HTTP server, and if you have another HTTP server your best bet would likely be load balancing or shadow proxying. It sure as hell isn't shoehorning a horribly inefficient protocol into your website to serve up subcontent.
      - We are most definitely going through the normal fuff because it is the browser making the request and the browser is a normal standards compliant FTP client.

      You're trying to make this something it isn't. Load issues that are solved in a better way, a (as far as I can tell) brainfade that you didn't realise that whatever you do in this scenario you cannot eliminate the HTTP server, and edge scenarios that are not physically possible.

    8. Re:Only FTP? by Anonymous Coward · · Score: 0

      Splitters!

    9. Re:Only FTP? by eneville · · Score: 1

      You seem to have spent a lot of energy confusing best solution with possible solution.

    10. Re:Only FTP? by thegarbz · · Score: 1

      Not at all. FTP to serve up HTTP content should never be considered a solution at all under any circumstances. There is quite literally no use case for it other than embedding content in a site from a foreign source that was never meant to be embedded in the first place, and that is horrible link breaking practice regardless of what protocol is used.

      I'm not spending energy, just using a few braincells and typing really quickly, and if I can convince even one person to not consider going down this incredibly stupid path then it would be energy well spent (and saved, considering all those poor resource constrained servers we were talking about).

    11. Re:Only FTP? by eneville · · Score: 1

      Again, you have totally missed the point. There are use cases but you refuse to look at other needs. Go back and read my original post, HTTP isn't the only way to transfer content.

    12. Re:Only FTP? by thegarbz · · Score: 1

      There are use cases but you refuse to look at other needs. Go back and read my original post, HTTP isn't the only way to transfer content.

      I think you may not have read my reply if you think for a moment that your post contained a "use case". No your post contained a clunky way of doing something that was never intended to do without any benefit and a load of downsides. That does not a use case make, and you have yet to come up with an actual use case for serving inline HTTP content via FTP.

      Not only is there no need for it, EVER, it also is a stupid idea if you sadistically have a *want* for it.

    13. Re:Only FTP? by eneville · · Score: 1

      I think you may not have read my reply if you think for a moment that your post contained a "use case". No your post contained a clunky way of doing something that was never intended to do without any benefit and a load of downsides. That does not a use case make, and you have yet to come up with an actual use case for serving inline HTTP content via FTP.

      Not only is there no need for it, EVER, it also is a stupid idea if you sadistically have a *want* for it.

      The use case is that someone has a need to deliver content over FTP. That's the long and short of it. Just because you don't want to do that doesn't remove the fact that someone may wish to deliver that way. You may choose to not do that if you wish, once the browsers include a way to do that they should continue to include that otherwise they have removed functionality that may leave some users surprised. Regardless of you choice delivery protocol preferences.

    14. Re:Only FTP? by thegarbz · · Score: 1

      The use case is that someone has a need to deliver content over FTP.

      Your logical fallacy is: Circular Argument! Now try to come up with a use case for delivering content over FTP within a HTTP site without that use case being "But someone may need to!!!"

      doesn't remove the fact that someone may wish to deliver that way

      I thought you were talking about a use case. If someone "may wish to" without a use case, all the while delivering a poor solution, then I will continue to call them out for the morons they are.

      once the browsers include a way to do that they should continue to

      Cars can be used for gassing yourself. Therefore cars should keep having an internal combustion case because someone may wish to gas themselves.
      What you are saying was a quirk and never a function, and where it was used it has no use case and is detrimental to users. No browsers should not continue to appease people who misuse their features stupidly.

      otherwise they have removed functionality that may leave some users surprised

      And the internet is a better place for it. Hopefully some web developer loses their job as a result. You seem very defensive about this topic. Are you one of these people who did something stupid without understanding what you were doing and without a use case?

      Regardless of you choice delivery protocol preferences.

      The sad thing is that this makes the most sense out of everything you have said so far, and it is completely gibberish, and not actually a proper sentence.

    15. Re:Only FTP? by eneville · · Score: 1

      The use case is that someone has a need to deliver content over FTP.

      Your logical fallacy is: Circular Argument! Now try to come up with a use case for delivering content over FTP within a HTTP site without that use case being "But someone may need to!!!"

      You're misusing the logical fallacy argument, we're talking established protocols here, not adding something that wasn't there already. The use case is, as said already, FTP server is likely to have less overheads. Take a look at RHEL Apache installs as an example, they're the kitchen sink, unlike that vsftp. Take this to an extreme with a dynamic site that handles all associated mod_* hooks and you will very likely have much slower delivery than a skinny vsftp.

      doesn't remove the fact that someone may wish to deliver that way

      I thought you were talking about a use case. If someone "may wish to" without a use case, all the while delivering a poor solution, then I will continue to call them out for the morons they are.

      No browsers should not continue to appease people who misuse their features stupidly.

      The only misuse you came up with was marginal performance. It is nonsensical to reduce protocol coverage based on that alone. There is still plenty of room in the world for mixed protocol delivery.

    16. Re:Only FTP? by thegarbz · · Score: 1

      You're misusing the logical fallacy argument, we're talking established protocols here, not adding something that wasn't there already.

      No we're talking about using established protocols in way that were unintended. You said there was a use case. I'm still waiting to hear that use case without you coming up with a circular argument for that use case.

      The use case is, as said already, FTP server is likely to have less overheads.

      No it doesn't because we're talking about serving FTP within HTTP which means you either have a HTTP server or a HTTP server AND and FTP server. So the FTP server adds needless overheads when you already require a HTTP server to serve a page. No one anywhere in this thread, in any Slashdot reply, in TFA, or at Mozilla is talking about using FTP for it's purpose of transferring files, something that Firefox will continue to do just fine.

      The only misuse you came up with was marginal performance. It is nonsensical to reduce protocol coverage based on that alone.

      That's the only one I mentioned here, TFS mentions breaking multiple security additions to the HTTP protocol, I already said not only is FTP+HTTP not a resource improvement, but actually a resource drain on your server. Then there's the technical downsides of FTP active not working behind NAT on one side, FTP passive not working on virtualised hosts, so aside from all the downsides it doesn't even actually fucking work on much of the internet.

      There is still plenty of room in the world for mixed protocol delivery.

      Indeed. When there's a use case that makes sense and it doesn't screw things up and add pointless overhead we should definitely implement mixed protocol delivery. We have created a lot of mixed protocols to fulfil a variety of use cases.

      Use cases...

      You come up with one yet? Or do I need to link to you the definition of a circular argument?

    17. Re:Only FTP? by Anonymous Coward · · Score: 0

      No we're talking about using established protocols in way that were unintended. You said there was a use case. I'm still waiting to hear that use case without you coming up with a circular argument for that use case.

      How is it unintended? I'm genuinely interested to hear.

      You come up with one yet? Or do I need to link to you the definition of a circular argument?

      You may link, but you're turning this into something that it's not. The point I've made clear, you may accept or not, is if a protocol has become supported within the browser it should stay there. Next next version will not be backwardly compatible with the protocol set of the previous. Dropping support is not not ideal, and may well lead to surprises for those who are implementing. If you wish to ignore that then do so as you may.

  18. Re: DONALD DRUMPF by Anonymous Coward · · Score: 0

    Please refrain from constraining this fine young man's honest opinion.

  19. Switched My Browser A While Ago by Anonymous Coward · · Score: 0

    Glad to see I made the right choice. It will be interesting to see if in the future people or businesses stick to older versions or diable updates due to the piling loss of functionality in firefox. Its a little worrying to see the internet shifting more and more into a single protocall of http or https only, what's next, firefox dropping support for loading the mailto protocall in webpages?

  20. Racist! by Anonymous Coward · · Score: 0

    You are spewing hate against orange POCs!!! I hope you are prosecuted.

  21. FTP used by FOSS Linux/BSD mirror sites by Anonymous Coward · · Score: 0

    Looks like a move to stop Linux distro being distributed easily. Most of my linux distro are being downloaded via FTP. Maybe torrent is another option for me now.

  22. What is XSA? by manu0601 · · Score: 1

    browser security and privacy features, such as HSTS, CSP, XSA

    I know HSTS and CSP, but what is XSA? Wikipedia says "Cross-Server Attack", but that is not a security feature.

  23. Let's be honest by Anonymous Coward · · Score: 0

    Mozilla and Google are blocking ftp:// links because they can't generate any advertising revenue from them.

  24. Javascript by Anonymous Coward · · Score: 0

    Now if it stopped loading Javascript "resources" too...

    Oh, wait. It's not the user they care about, it's the ad industry. Got it.