Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Web browsers are not file browsers, not 3D renderers, not fucking text editors. Stop moaning about removed browser features. The two plausible use cases of a web browser are
1. A document viewer for the publishing format known as the World Wide Web
OR
2. A trusted, secure sandbox for running untrusted applications written in JavaScript and WASM.
It's bad enough that these two wildly different use cases are tightly coupled, and it's the main reason why there are 3 good browsers left. Stop moaning when they cut off underutilized maintenance burden. They desperately need it. -
Also, FTP isn't usable "for non-private data". It's completely unencrypted and unsigned. Each device in the linkage kindly asks the next to please forward the same file. The contents of an FTP server are decided by each network operator based on what the next network operator says. Every single one of them has the individual choice to lie based on your request and the true data, and the rest and you are none the wiser. This is totally unnecessary and unjustifiable risk when in practice you always either know the server (direct key exchange, SFTP) or trust a common authority (certificate, FTPS), otherwise you wouldn't be talking to it.
-
i'd say they removed it because it's utterly obsolete.
first of all, browsers were limited to downloading - and ftp doesn't really provide any benefits over http. not in this day and age.
and if you want to manage files, then you are gonna want a dedicated tool, anyway. for example... whatever file explorer is built into your OS.
by the way: it's been at least a decade since i last saw anything FTP in "the wild". the closest i've seen (and actually used) is SFTP (which only shares a similar name and is a file-transfer protocol basically built into SSH) - which has the great advantage over ftp: _you do not need to set up anything_ - as soon as you have ssh-access to a system, you can meddle with the files.
FTP is dead. let it rest in peace. -
@exerceo If browser developers feel that it is underutilized and a burden then yes. Linux ships with a HTTP server, as does nearly every programming language. All that would change is that shells would gain support for starting an ad-hoc http server before opening stuff in a browser. Stopping the server after 30 minutes of inactivity is also trivial no matter which one of the many HTTP servers already installed on your system you're using.
-
@exerceo Without file:// and ftp:// there are two protocol families browsers support. Virtual pages (what Firefox calls about:) and http. If the only providers of an interface are one virtual and one shim, refactoring is probably in order.
-
FTP is totally unnecessary in browsers, good riddance. Downloads, which is all that FTP was ever used for in browsers, are via HTTP these days, and that benefits directly from "https everywhere" and Let's Encrypt being for free.
On top of that, FTP is quite a shitty protocol to begin with, much less robust that HTTP. That's because FTP needs actually two connections, data and control, and even then only works reliably if the server supports passive FTP. Without that and the common CGNAT in the mobile world, it's screwed. HTTP doesn't have such issues.
file:// is different because there are use cases for that, namely when you save a website locally and want to view it. It also isn't over the network anyway, so the FTP issues don't apply. -
@Fast-Nop External content usually breaks in file:// because it's not a secure context and absolute paths break. It only really makes sense in the document viewer role of a web browser and even then it's kind of clunky. I think it could be better if browsers supported a "snapshot" export mode where all JS is stripped, the currently applicable styles (as opposed to the downloaded styles) inlined and image paths translated.
-
@lorentz Saving a website will also save the resources locally, and adjust the pathnames. Mostly at least.
I don't see browsers removing file:// because that would also mean the first browser to do so would be unable to be the default file handler for local .htm(l) files. -
@Fast-Nop I expect the road to removing file:// starts with some OS shell replacing it as the default file opening behaviour for browsers with an ad-hoc http server to forego the jank of an untrusted context. Browsers will only remove it once this catches on.
-
The shell to do this could be Windows or MacOS because they have their own browsers so they can easily detect when the tab is closed and cleanly shut down the server, or it could be KDE because it's willing to address niche power user problems and it already comes with MariaDB to make PIM work so they clearly don't give a fuck about daemon bloat.
-
@lorentz But that would require installing an http server just for viewing files. Doesn't sound likely, and also not performing well. Plus that it wouldn't really solve the issues with saving a web page locally. You'd still need to save everything locally, even external stuff, or else it isn't a local copy.
-
@Fast-Nop It would remove some differences between the website and the saved copy. For example, a React page that pulls data from an API on the same domain would fail in file://. (I think, I can't test right now but trying to fetch() a non-CORS endpoint sounds like the archetypical trusted operation). As a cherry on top, React blanks the page if a component crashes so this will happen even if the page just checks if you're logged in to draw the little icon in the header bar.
-
@Fast-Nop Many users already have several HTTP servers installed, and they're not that heavy or complicated anyway. This server wouldn't even have to support complicated things like concurrency, just a decent MIME database is enough.
-
@c3r38r170 Ban HTTP? Why? Does the content of some public information page need to be encrypted?
-
@lorentz touched on it, but the problem with using it for "simple", accessible data is not that it's unauthenticated, but that it's unsigned.
If I want to use it to access a public file, I want to be damn sure that file hasn't been MITMd or tampered with. FTP can't do that. -
@fjmurau Everything needs to be signed, no exceptions. Encryption comes with authenticity guarantees for free. I'm not aware of an unencrypted protocol that signs all server communication, it sounds unnecessary to devise a custom protocol just so your communication can be less secure than the regular clear text method wrapped in TLS.
-
@lorentz If it was unencrypted and signed then a MITM could trivially alter the signature to match tampered content - so the signing would be worthless.
-
@AlmondSauce How? Isn't the definition of a signature that you can't forge one without knowing the private key no matter how many real text-signature pairs you know?
-
@AlmondSauce request tampering is still a risk but easily solvable by including the hash of the request in the signed response. I guess such a protocol would have the advantage of being cache transparent.
-
@lorentz Oh sorry, early morning brain. You are correct.
-
@fjmurau Everything needs https, also static public information: https://doesmysiteneedhttps.com/
-
@exerceo "Do you also believe getting rid of FAT32 support on operating systems is a good idea?"
maybe not right now. but at some point? yes. just like we got rid of a lot of obsolete things. like FAT16 or FAT12. or 16-bit executables. or IPX. -
@fjmurau "Does the content of some public information page need to be encrypted?"
yes. because privacy. because i don't want my internet provider, government, or other potentially malicious individuals to know _what_ public information i have accessed.
also: yes. because security. i don't want malicious individuals to change the data packets during transport (which is much easier with unencrypted content) and inject invalid information or malicious code.
today, encryption does not incur any _significant_ performance overhead anymore, and there's no reason not to use it. -
@tosensei Isn't FAT the best supported FS for UEFI boot partitions? I mean, I wouldn't do anything complicated or high demand with it, but using a file system the read-only implementation of which is a couple hundred lines for UEFI makes sense.
-
@lorentz that's why i said "at some point" and not "totally, yes, right now, what are we waiting for?".
-
@fjmurau That's a very niche use case. I can't think of a website that has no need for security. And if there's one... it may need in the near future. Even a public newsletter has an admin panel that needs security, most of the time, right?
-
@exerceo "But your family photos stored on FAT16 or ISO9660 media can not be replaced."
1) i doubt the _physical media_ would survive that long. especially optical disks written at home have a very limited shelf life.
2) if you don't have a backup on it on a storage you know is reliable - then it's not important and doesn't need to be replaced. no backup, no mercy. period.
as for 16 bit support: "anything that FAT32 can do has been adapted by [NTFS/EXT3/ExFAT/YouNameItFs]" - bad argument. and yes: you can always add an emulator to retrofit your modern system for ancient technology _if you need it_. but nobody does.
also: please don't mix up "technologies" and "services". the size limitations you nare talking about have absolutely no technical reasons. only business reasons.
also: HTML doesn't require a custom interface anyway, since EVERY webserver software supports directory listing. and for uploading: just enable webDAV. -
@exerceo so by the same logic, you just volunteered to write drivers for any new operating system to support my old 5.25" floppy disks on which i keep my important documents?
-
@exerceo I don't think the browsers even supported FTP upload, only download. So for you transfer, you had to use some other program for the upload anyway.
Big news: you can use that same program for download as well! All with completely insecure FTP, blasting your password over the internet, getting hacked as result. -
@exerceo Already my desktop back in 2010 didn't even have a floppy controller on the mobo. You can maybe find a PCIe card with controller, or a USB floppy drive, but normal computers havn't supported floppy drives in a long time.
-
@exerceo Being able to read is one thing. Demanding to do that with a specific program that isn't even meant for that, that's something else.
Browsers were never meant as FTP programs and only supported the download because people were downloading from FTP sites, which is now so obsolete that browsers have no reason to offer that anymore.
Quite the opposite, they have good reason to remove it so that people download via https. No third party SW required, either. Give them, big brain move, an https link!
Related Rants
Privacy is a legend
Web browsers removed FTP support in 2021 arguing that it is "insecure".
The purpose of FTP is not privacy to begin with but simplicity and compatibility, given that it is widely established. Any FTP user should be aware that sharing files over FTP is not private. For non-private data, that is perfectly acceptable. FTP may be used on the local network to bypass MTP (problems with MTP: https://devrant.com/rants/6198095/... ) for file transfers between a smartphone and a Windows/Linux computer.
A more reasonable approach than eliminating FTP altogether would have been showing a notice to the user that data accessed through FTP is not private. It is not intended for private file sharing in the first place.
A comparable argument was used by YouTube in mid-2021 to memory-hole all unlisted videos of 2016 and earlier except where channel owners intervened. They implied that URLs generated before January 1st, 2017, were generated using an "unsafe" algorithm ( https://blog.youtube/news-and-event... ).
Besides the fact that Google informed its users four years late about a security issue if this reason were true (hint: it almost certainly isn't), unlisted videos were never intended for "protecting privacy" anyway, given that anyone can access them without providing credentials. Any channel owner who does not want their videos to be seen sets them to "private" or deletes them. "Unlisted" was never intended for privacy.
> "In 2017, we rolled out a security update to the system that generates new YouTube Unlisted links"
It is unlikely that they rolled out a security update exactly on new years' day (2017-01-01). This means some early 2017 unlisted videos would still have the "insecure URLs". Or, likelier than not, this story was made up to sound just-so plausible enough so people believe it.
rant
security theatre
privacy