4 ms·
> ftp is a relatively simple protocol, not particularly complicated to implement Parts of it are, sure, but parts of it are an absolutely horror show (The clie
by billyhoffman 5y ago
> ftp is a relatively simple protocol, not particularly complicated to implement
Parts of it are, sure, but parts of it are an absolutely horror show (The client opens a port, and then the server connects back to it!?), text conversion and binary modes that's based on ASCII, different list formats, etc. It's not great. Worse, it doesn't support the good stuff like implicit TLS extensions
> Supporting FTP isn't some big technical challenge. The code has been there in the firefox codebase for nearly 20 years now, running just fine. All you need to do to continue to support ftp is nothing at all.
Not at all. Continuing to support FTP means continuing to defend attack surface that's implemented as 20 year-old code, to deliver a feature that in 2021 the majority of people do not use.
It's a cost-benefit analysis. I want Mozilla to do more. If they believe removing FTP support enables them to do more, I'll all for it.
- antisol 5y ago>It's not great It's simpler than a pdf viewer. >It's a cost-benefit analysis If it were, they'd have never added a pdf viewer in the first place. Everyone already had one. Near-zero benefit, huge cost. >I want Mozilla to do more. At this point I'm afraid we're just going to have to agree to disagree. For the last 5+ years, Every time Mozilla "do more", I throw up in my mouth a little.
- oblio 5y ago> If it were, they'd have never added a pdf viewer in the first place. Everyone already had one. Near-zero benefit, huge cost. Every time I clicked a PDF online, I dreaded the external viewer opening (especially Adobe Reader). I very much liked when they integrated a PDF viewer. Chrome also has one. I'm willing to bet the internal PDF viewer has at least 100x (more likely 1000x) the users the FTP client had.
- antisol 5y agoSounds like you had a shitty pdf viewer installed. Which is not my problem. Why was I forced to install a substandard, feature-poor, ridiculously slow pdf viewer that I never wanted and which took over as the default pdf viewer against my wishes and without asking me, just because you couldn't be bothered to install a decent one? >I'm willing to bet the internal PDF viewer has at least 100x (more likely 1000x) the users the FTP client had. Yeah, that tends to happen when you change the defaults without asking.
- oblio 5y agoVent, rant, get it out of your system :-)
- antisol 5y agoWay ahead of ya ;) but you didn't address my question
- oblio 5y agoAll PDF viewers are crap in my experience. If you don't agree, you haven't used PDF enough. PDF has Javascript as a programming language, it has extensions for 3D models and a ton of other stuff (I think even sound). As a format it's almost as complex as the entire web stack. Multiple web browsers have embedded PDF viewers because the PDF viewing experience for most people sucked so much. That's not a product decision taken lightly. Your personal experience does not reflect that of many other browser users, it seems. Even on mobile I dread clicking a PDF link.
- antisol 5y agoYou still haven't addressed my question. I'd respond to the rest of your vague and incorrect opinions, but why would I do that if you're not even going to bother to address my points despite me asking you to repeatedly?
- oblio 5y ago> You still haven't addressed my question. If I must spell it out, there you go: > Why was I forced to install a substandard, feature-poor, ridiculously slow pdf viewer that I never wanted and which took over as the default pdf viewer against my wishes and without asking me, just because you couldn't be bothered to install a decent one? Because you are part of a minority of Chrome and Firefox users and I'm probably part of the majority of users, in this regard. I don't know this for sure, but if a Google program manager decided to back building and embedding an entire PDF reader into a browser, I'm 99% convinced this is true. We're dumb and you have to live with us. Life's tuff.
- kragen 5y agoIt's not a well-designed protocol, but it's still a relatively simple protocol. Your reasoning, that "Continuing to support $x means continuing to defend attack surface that's implemented as $y year-old code, to deliver a feature that in $z the majority of people do not use," would ultimately consign every feature on the web to the book-burners' flames, except for the worthless minority of features that the majority of people do use. Chinese HTML text support, I suppose, and biometric authentication, and whatever the latest video codec is. After all, it's 02045. Who watches videos encoded in VP9 now anyway? It's been obsolete since 02028! Or reads English text? Much less Hebrew? The majority of people do not use those features. Why should we continue to defend that attack surface?
- billyhoffman 5y agoStraw men are not helpful. I never suggested removing a language used by millions of people. Let me be more specific: Pruning support for old formats and protocols is a feature, not a bug. Let's pick something else from this golden age of "browsing HTML pages via the FTP protocol" that people on this thread keep professing: XBM images, the very first image format ever supported by browsers, and used when Marc Andreessen literally invented the IMG tag [0]. XBM is a crazy simple image format [1]. Yet, because it is essentially C code that defines a buffer size and then gives you a char array, caused security bugs over and over [2] in all major browsers. Since virtually no one was using XBM images, the browsers all removed support for it [3]. The browsers removed code that was already written, and abandoned functionality that had already existed, because it reduced attack surface supporting something that virtually no website was using. Exactly like FTP support. 0 - https://eager.io/blog/to-what-extent-did-marc-andreessen-invent-the-internet/ https://eager.io/blog/to-what-extent-did-marc-andreessen-inv... 1- https://en.wikipedia.org/wiki/X_BitMap https://en.wikipedia.org/wiki/X_BitMap 2- https://www.cvedetails.com/google-search-results.php?q=xbm+image&sa=Search https://www.cvedetails.com/google-search-results.php?q=xbm+i... 3- https://en.wikipedia.org/wiki/X_BitMap#Support https://en.wikipedia.org/wiki/X_BitMap#Support
- kragen 5y ago> I never suggested removing a language used by millions of people. Let me be more specific: Pruning support for old formats and protocols is a feature, not a bug. You're contradicting yourself here; Hebrew is a language used by millions of people (about ten million, so 99.9% of the world's population does not use it) and also an old format (about 3000 years old). "Pruning" support for old formats makes history inaccessible; "pruning" support for old protocols requires constant effort to keep your servers compatible with whatever is fashionable with today's cascade of attention-deficit teenagers [CADT]. And if we follow your originally stated reasoning, "Continuing to support $x means continuing to defend attack surface that's implemented as $y year-old code, to deliver a feature that in $z the majority of people do not use," we ineluctably arrive at the conclusion that we should remove support for languages used by millions of people. Taken literally, we should remove support for all languages, since no language is used by more than 50% of the world population, but in keeping with the principle of charity, I interpreted your "majority" as "vast majority". I'm not sure where exactly the vast-majority cutoff lies: a feature that 90% of people do not use? That would include all natural languages except English and Chinese. 95%? All languages except those, Hindi, and Spanish. (In particular, it leaves out all those RTL languages that cause so much complication in text rendering, like Arabic.) 99%? That leaves 20 languages, but not, for example, Persian, Swahili, Italian, or Thai. Even a cutoff of 99.9% might leave out Hebrew, Uighur, and Greek. What percentage of users do you think use View Source? The web inspector? Printing? That's not a strawman argument; it's a slippery-slope argument. And, I think, it's a valid slippery-slope argument. If we are going to avoid removing support for these things, we need a better basis on which to make the decision than, "Continuing to support $x means continuing to defend attack surface that's implemented as $y year-old code, to deliver a feature that in $z the [vast] majority of people do not use." I do agree that there needs to be some kind of cutoff. Gopher is probably below it; WAIS and XBM certainly are. But FTP? XBM was never very widely used in web pages because it didn't support color, grayscale, or compression, although for a little while it was the only image format supported by browsers that supported transparency. I did put it on a few of my web pages, but as soon as Netscape added support for transparent pixels in GIFs, I switched over and never looked back. This would have been about 01994. By contrast, there are about 1.1 million anonymous FTP servers today, one out of every 4000 public IP addresses, and about one for every 30 HTTP(S) servers: https://zakird.com/papers/dsn-ftp.pdf https://zakird.com/papers/dsn-ftp.pdf That's more than the number of HTTP servers that existed for the first seven years of the Web, up to 01997: https://news.netcraft.com/archives/2021/05/31/may-2021-web-server-survey.html https://news.netcraft.com/archives/2021/05/31/may-2021-web-s... You can be sure that there's millions of people using them. Probably more people than speak Hebrew, in fact.
- apostacy 5y ago> It's a cost-benefit analysis. I want Mozilla to do more. If they believe removing FTP support enables them to do more, I'll all for it. This was the justification for removing RSS support. And look at what Mozilla has chosen to develop instead.