Google Plans to Deprecate FTP URL Support in Chrome(pulltech.net) |
Google Plans to Deprecate FTP URL Support in Chrome(pulltech.net) |
I just opened ftp://ftp.gnu.org/pub/gnu/ in firefox 68.
https://www.fxsitecompat.dev/en-CA/docs/2018/loading-ftp-res... But FTP still is.
I feel like Google is quickly moving in the footsteps of IE; embrace, extend, extinguish and all that. I don't like how Google now has so much market share in the browser space that they can essentially unilaterally make decisions that are user-unfriendly and have a real impact. I switched (back) to Firefox for this reason. I switched away from them when they essentially purged Brendan Eich for political reasons, but they're the lesser of two evils now.
I guess in summary, all browsers suck and we're all fucked.
Why should we keep FTP or other legacy non-HTTP protocols around? What are we buying? Slightly lower connection setup byte counts?
For remote file management and uploading there are other options besides WebDAV (itself a HTTP protocol extension), such as SSH/SFTP.
Basically the only case I can think of that needs FTP are people wanting to access a shared-webhost web-space. And FTP works fine for them already, and they aren’t using Chrome to update their site either - so no loss.
The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request.
If you do connection setup, service disambiguation, redirects, and so on with HTTP and switch to a non-HTTP interactive protocol, what you've effectively done is create an HTTP sub-protocol, and I don't care what the document you quoted says.
Also, I can't be the only one who's absolutely sick of hearing that bloody "security" argument again. Yes, everyone knows FTP is plaintext, and so is HTTP. But drivers, which I'd say are a significant part of FTP use, are almost always themselves signed anyway, and I don't think malware is widely distributed via FTP either (I'm curious why FTPS/SFTP doesn't see to be indexed, or why they didn't decide to add that to the browser instead --- or at least I've never come across a search result that links to one.)
Maybe it's time to bring ftp search engines back.
And yes I know there's some niche support still, just as FTP will live on.
You mean no one knows that FTP is plaintext except a minority of users which happens to be on HN.
Google is optimizing its browser for the majority, chrome is not a power-user browser. Maybe they'll add an option to enable ftp or something.
> drivers, which I'd say are a significant part of FTP use
I'm not sure how that's true. Every time I used FTP, it was not for drivers. All the drivers I downloaded were over http(s), from constructor websites.
That is a problem. We have browser engine duopoly, and really everyone is doing whatever Google wants anyway. So as they're optimizing against power users, they're making the whole web much worse.
Yet they are positioning it as the only browser
Well, I think there is enough people like us, where a proper 'power-user' browser is worth maintaining. Any takers?
I guess not. More likely there'll be plugin to add this functionality back.
The point of "organize the world's information and make it universally accessible and useful" is to do precisely that: to organize the world's information and make it universally accessible and useful -- long tails included. But I guess for them it's not...
(Also, I can't believe the Chrome team is so strapped it can't afford to support or harden the feature, as some in the bug tracker suggest [1]. This is Google we are talking about, not some tiny open source project!)
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=333943
How do you display ads while someone is accessing an FTP server?
ftp://example.com/directory/file.extension can be a link in a website, where the website displays ads.
I'm just imagining some people having a conversation that goes something like this:
"The funding for this feature has been removed because we can't serve ads on a page like this https://imgur.com/20ooI9f "
Edit: grammar
I believe those will happen, in the long run.
The next HTTP spec includes mandatory SSL, and Google had a hand in designing QUIC, and Google has been deprecating traditional SMTP authorisation.
But my gut reaction to reading this concern is actually: why do you think this is “bullying” and not “opening the door for a niche competitor”?
Bully them back. Don't use Google search and don't use Chrome.
It is obvious that the next FTP related headline we see from Google is when (not, if) they drop FTP links from all Google search results. There's no point them listing FTP urls in the results if their own browser can't connect to them.
(I don't understand why they can't just keep FTP support in, but with a security dialog that warns users the connection and data will be non-encrypted)
So much is going to be lost when this happens, it's really sad. All because Google want to recreate the internet as the Googlenet, with HTTPS URLs only, most of which link to their own walled garden servers (AMP etc.)
The internet started off as a wonderful limitless information sharing platform, now it's just a shopping mall controlled by corporates. The worse thing is... the general public just don't care.
When I click magnet:// links, my bittorrent client opens. When I click slack:// links, my slack client opens. With this change, when I click ftp:// my ftp client will open. Chrome has simply decided it only wants to spend resources focusing on http:// and make the unrelated protocols separate. I see 0 problem with this, it's not like they're killing the only or even the most popular ftp client out there. We should all be using sftp anyways...
That said, I find the viewpoint "users should not be impacted by this deprecation" the height of arrogance. Note that phrase is lifted from the article, and is not present in the dev team's post.
FTP isn't used much anymore, but IMO/IME, it's still nice to have for those rare times when you come across a file that you need to download and it's served over FTP.
No one should be running FTP in 2019. It sends passwords in plain text for christ's sake.
So...no reason for FTP in the browser, since it already supports HTTP?
The idea that young people know more about tech than their parents will become less and less true in the future.
That's fine... Except on a Chromebook or Android, where it will be a pain.
Aren't you forgetting that IE is a web browser, so are you suggesting it should just offload ftp:// links to another browser?
Also, IE is deprecated and replaced by Edge which is now essentially Chrome, so eventually won't work there as well.
Like, worst-case ChromeOS loses ftp?
If suddenly the links stop working and there isn't a way view the contents, it will be a frustrating transition
You'll still be able to download an ftp: link by your browser opening your local FTP client, same as a magnet: opening your local torrenting client -- as it should be.
And honestly, if you're one of the few people who actually need to regularly download files with FTP, don't you want a better standalone client anyways?
(I also invented a httpdirlist format (I have been told that httpdirlist is like WebDAV but not as bad; but I don't know WebDAV so I cannot say if it is or not). But, sometimes, the other protocols is better than HTTP(S) anyways.)
I think it is fine to have them implemented in separate programs, although sometimes you might want to display the result in the browser; one possibility is that the user can configure a program to execute and can configure it to treat the data that program writes to stdout as a HTTP response (possibly with different permissions than normal; it might allow some things that are normally disallowed, and some things that are normally allowed might not work). You might then also want to support other MIME types. You can do this also with external programs; so one configuration option could be to allow treating the program as a filter to convert it into a format the browser understands (e.g. plain text, HTML, PNG, etc; perhaps farbfeld should be supported too, even only for the purpose of these external filters).
Anyway, it's not like Chrome couldn't send the URL to a dedicated FTP client. Hell, it could even be another browser like Firefox. It's not going to be the end of the world -- just not as seamless of an experience and one would like.
The web is not just HTTP. FTP has been the binary companion to the text-based HTTP protocol, and I think that for the sake of the browser being a platform and not just a viewing tool, it should stay.
End of an era. I imagine it would take the better part of a decade to earn my loyalty back if they ever pulled a 180, but seeing their direction the writing has been on the wall for a while.
Mozilla stopped running ftp://ftp.mozilla.org quite a while ago. Maybe that is what you were remembering?
https://chrome.google.com/webstore/detail/sftp-client/jajcol...
Not sure if it uses a proprietary proxy though.
Bugzilla.mozilla.org is offline, here's a mirror: https://web.archive.org/web/20190520010425/http://bugzilla.m...
and relevant quotes posted there (a year ago!): "I think we should mark this bug as WONTFIX. We have a vague plans of deprecating FTP completely in Firefox, there is no point in adding more code in this area." "Since we (sooner or later) would like to deprecate FTP completely, we should not add more code in that area to our codebase."
Mozilla has lost the ability to be an independent protector of the Open Web
That's why you haven't. Ask regular non-tech people doing office jobs in non-tech companies. Some FTP use will show up. Random example I've seen recently: a sports clothing vendor giving seasonal copy bundles for marketing posters to its partners via a password-protected FTP server.
Thats a very small fraction of all the resources.
> It is obvious that the next FTP related headline we see from Google is when (not, if) they drop FTP links from all Google search results. There's no point them listing FTP urls in the results if their own browser can't connect to them.
This is a worthy concern, for sure. Although how do you know they haven't already done this? Do you have a search that shows ftp: urls?
> The internet started off as a wonderful limitless information sharing platform, now it's just a shopping mall controlled by corporates.
I'm trying to think of the period when the internet wasn't driven by corporate interests. Before the dot com boom, I suppose? When newsgroups thrived, and email servers roamed free without spam? That was fun but theres a fuckton more information on the internet now.
Sure, searching for "rfc 1337 inurl:ftp" returns FTP urls for the top four results for me.
Why would it? Seems like the relevant model is file types the browser can't open, and there are lots of search results for those?
https://support.google.com/webmasters/answer/35287?hl=en
Lots of worry in this thread from people who apparently don't use ftp enough to know that your OS will already open ftp links for you.
It's also a shame that the actual technical discussions are like half a page down.
I'm of the mindset that code written 20 years ago should run today. This is a breaking change on a critical piece of internet infrastructure. Google, by nature of operating the most popular web browser, has a moral obligation to the community to provide a stable environment.
There are something like 10^9 webpages out there. How many of these will become less accessible because of this change? Many well maintained webpages will have to expend resources to migrate off ftp. Less maintained webpages with FTP links will not be updated and put the burden of installing an FTP client on the user, reducing accessibility.
This is Google externalizing the cost of updating their software by forcing everyone else to update their webpages to following Google's specification.
I'm of the mindset that it should be possible to rub code written 20 years ago, but not always the same way you run code written more recently. Emulation, virtual machines etc all allow access to old work without hobbling future development with backwards compatibility concerns (see: Windows).
In this case, there are plenty of free and open source options for FTP clients. No one is going to have the world closed off to them as a result of this.
Given that chrome didn't exist 20 years ago, this seems like a fairly absurd position to apply to this situation. No code from 20 years ago relies on chrome having ftp support.
I believe otherwise. Let the old die, so we can alleviate ourselves to create something more suitable to our times.
We should stop telling others what they SHOULD do. (Crap I just did.) Anyways, why not contact Google and offer them to pay the costs of maintaining every piece of software they ever decide to deprecate? Or just go on and build a better browser if you can.
So you would have cp/m, MS-DOS, PDP-11 RSX-11M, Coherent, Vax VMS, old broken compilers for dead languages, IBM 360 TOS (yes, tape operating system), IBM 360 DOS, Sigma 5 Real-Time-Batch monitor, autocoder, 1401 software, Palm OS?
But for the love of all that is Balloons and Seashells, why?
More to the point--did Chrome have FTP 20 years ago? No, it did not.
In my opinion, they should have never put it there in the first place.
Really, though? Are there any examples of any web pages that are strictly available from FTP instead of HTTP? If so, why? Isn’t HTTP made specifically for the purpose of transporting hypertext? Why use another, more general protocol when you can use the one made specifically for your use case?
I’m sure there’s good stuff on FTP still. I really, really doubt people are throwing SPAs and PWAs on FTP servers though.
It's OK if some of the more antiquated parts of the web die off. I don't want to have to support old Flash loading screens, I don't need AOL instant messenger status badges, or iFramed in MySpace comments, and I don't need to open FTP in my browser. Most users these days wouldn't even know how to use this via browser... ftp://myname:mypassword@123.123.123.123... it's just a relic.
Anyone who wants to use FTP knows how to download a program for it. We don't need it in Chrome.
> It's not part of the modern web, so it's just another loose end to tie up.
While I see that it is shared by many here, I do not get this sentiment. It's still out there and rarely used, yes. But similarly would not require much maintenance for the time being, remove it when users decide it's dead, not just your shiny modern partners. The codebase cannot be that burdened by support for the protocol, why even take action?
I guess what I'm trying to figure out is the reason why this even came up, is that to soothe some weird code base / maintenance metric?
Rather, there are no ads on FTP pages, so Google is going to use it's power to stop countless people to stop using FTP.
That said, I agree that its outmoded today.
Before, computers compelled you to have a certain level of technical competence to be a user.
Now, the barrier to entry is a lot lower, but there aren't many of the very young learning their way around command lines, etc. The resources once you are on the track to doing technical stuff are far better, but you're less likely to end up on that track-- especially at an early age.
What’s the benefit in keeping protocols for the sake of it?
Do we need browser support for it? It still happens now and then that a link will have an ftp target. That could be handled in the browser or it could open a separate url-handling application, as e.g. email or magnet urls do.
(Of course there's no guarantee they'll keep support for it, based on similar arguments)
"relevant model"
> my OS won't open ftp links for me.
What OS? Because I bet you it does.
Whether Google's search engine will continue to do so for ftp:// resources once Google's web browser no longer handles them remains to be seen.
Since we’re talking about utilities built into the OS, I’ve never had a problem with this.
http://webcache.googleusercontent.com/search?q=cache:TaTfcCq...
FTP links will still work, they just won't be displayed in a browser anymore. People are blowing this way out of proportion, as if FTP is some critical underpinning of the web or web browsers are a critical part of FTP. Web browsers have always been terrible FTP clients, anybody who uses FTP on a regular basis uses a better client. The most tangible impact of this change is to give grumpy internet commenters something to complain about.
[0]: https://chrome.google.com/webstore/detail/iodihamcpbpeioajje...
https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...
Sadly a decent fraction of users might just accept something like this, even though it would be a major step backwards for internet freedom.
The linked Google Doc says that usage in a 28-day window was at 0.01-0.03% of users (not sure which figure to use there). Sure, that sounds horrid at first but think about how many users Chrome has, that's not nothing either. Instead of implementing encrypted connections to make their software better, they jump to deprecate yet another protocol. I just find this really hard to grok. How many people used the profiling features of the developer tools in that time frame for example? Not many? That's cool, do we get to keep those anyway?
Browsers are complex, yes, it just would be nice if we could expect a bit more of a graceful deprecation process with better communication. If you don't feel like supporting it, move it to an extension/plugin to separate it and put it somewhere the community can pick it up easily.
And to the people who disagree: Firefox has always been great, but it often came with a lot of bugs and inconveniences. It didn't use to be as accessible.
Please explain how. Since firefox 57 (quantum), there's precisely no way to do that properly...
I tried to switch to FF on multiple occasions, but it's a CPU hog on MacBook. Why is this issue ignored for so long?
It has been going on for years.
Having worked with ssh/scp/sftp, I think sftp could be better too, and therefore more useful.
It's intimately entwined with ssh, which means that instead of just transferring files, you have to give out ssh permissions where they're not required.
Really, there should be an sftp client and server, strictly dealing with files.
- You could have "accounts" that weren't real users on the machine
- You wouldn't have to deal with users and shells and groups and permissions
- You wouldn't have users running commands on your machine
- You could have read-only sftp (sort of a repository with access controls)
- You could have write-only sftp (sort of a dropbox)
- You could make these formal, with daemons like read-only-sftpd or write-only-sftpd that were securely purposed to prevent unexpected file operations.
Read only isn't a problem, as denying writes and allowing reads is a trivial part of unix filesystems.
For a time I was using Konqueror with fish:// URLs as a SFTP browser and it worked very well and made me happy ...
I am not sure if that workflow still works but most rsync.net customers that I interact with are using sshfs on top of FUSE and mounting ssh resources as a local filesystem - so no browser involved.
One wouldn't expect Google to say "We recommend you use our browser, Google Chrome, but there's also these others that work fine to."
It's probably the case that back when the number of internet users was smaller the place had a more community oriented vibe, whereas now there is huge sums of money and power at stake.
This is tangential to whether support for FTP is still worth keeping in a web browser, mind.
FTP in the browser typically looks something like this https://imgur.com/20ooI9f
Plenty of space for ads.
HTTP is basically FTP with ads.
Funny thought. Imagine if, to this day, the internet consisted of pretty much that.
You go to ftp://nytimes.com and it just has a directory structure that consists of yyyy/mm/dd and the file names where things like statement-from-chinese-ambassador-to-australia.txt
And maybe a directory named breaking-news
Imagine if Twitter was a list of text files named yyyy-mm-dd-hh-mm-ss-username.txt
Ha.
Imagine if you had to upload a text file like this
---
Please place an x between the brackets as desired
[ ] Whopper Meal
[ ] Super sized Whopper Meal
[ ] Coke
[ ] Sprite
[ ] Eat-in
[ ] Takeaway
etc
Name on card:
Card number:
Expiry:
Card Security Code:
Sponsored by Nike and the Ford Motor Company
----
That's pretty much Gopher. Another protocol that Chrome no longer supports.
On Usenet newsgroups and BBS conferences, sellers would post forms that looked exactly like that, except for the ads of course. Buyers would then send in their completed order form via either email/netmail or, preferably, via fax for added security.
I remember always choosing to fax in my orders; even way back then, sharing credit card details via email seemed like a very bad idea.
I would love this. This has better UX than the food ordering sites we have to deal with in the real world.
Nobody would actually bother to download it would they!
Sounds like a total improvement over websites I have suffered... not to mention allows all kinds of third parties to create their own fancier ordering systems on top!
Here we are talking about removing FTP from a browser.
It uses separate "command" and "data" channels. The data channel is usually in the other direction, i.e. the client listens to a connection from the server when downloading a file. Passive mode, and an extra command for that, had to be implemented, and if the stars don't align right, it still ends up being a pain.
FTP also used to default to 7bit. If you did not explicitly switch to 8bit mode, you got corrupted downloads. This maybe made sense in a world with fundamentally different encodings, line endings, and where connection speeds were slow enough that downloading text files was a big task, but now?
Then, if I remember correctly, the file listing you got was not actually standardized, it could just be the output of the "ls" command on the server! FTP clients used to be dumb and just passed that output through to you, so it did not matter much. For smarter clients later, it did start to matter.
Finally, what does FTP actually offer that, in most cases, HTTP, and, in niche cases, rsync, scp or sftp do not offer?
This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
This is a very silly response.
New versions are released with security fixes, not just new features.
Even aside from everything else, Chrome auto-updates and it’s very difficult to disable.
SFTP is actually not just FTP over SSH. The protocol is different precisely to get rid of a lot of the outdated nuisances.
As for rsync, sftp, scp those are heavily tied to ssh, rsync to the point that you actually ssh to host and call rsync command. rsync has a server mode as well, but almost no one uses it.
That aside, you can use FTP for auth and ACL in of which HTTP and rsync just aren't capable. I'm not sure this is a flaw in the core protocol so much as the tooling, but there you have it. FTP config syntax may often be byzantine. But it's widely supported (especially on old, low-spec, or embedded devices). For newer stuff, yeah sftp is probably better. But it's still got its uses.
That’s not the point we are discussing though; This is specifically regarding Chromium supporting FTP.
The users will just have to stop using Chrome. Supporting Google software is always just a pain in the ass (and I've gotta know as developer of Android apps)
Bad guys can now replay old drivers, which were cryptographically signed, as the latest drivers.
So then you need to build cryptographically signed metadata structures, so that you can tell that these were the latest drivers as of some recent moment. You need to have this idea of freshness, and a mechanism to ensure it's kept up to date.
There's a period of several years where Linux distros split into two camps: One camp used HTTPS and so it was fine, and the other camp would have a bug where bad guys could cause something unexpected with a MitM attack, and they'd patch it, and then some new bug would be found, and they'd patch that and repeat...
It isn't _impossible_ to get there, Fedora can safely update over insecure protocols today as far as we know. Or, you can skip all that noise and just do HTTPS as RHEL itself had been doing for many years by that point.
How many users do you think check which entity signed an executable?
But if you really think it would be right to switch away from Google, give yourself a month of pain and then decide if you can live this new life. ;-)
I personally hope they continue exhibiting monopolistic behaviour. Same with Cloudflare and other company's who choose business models that are hostile to an open and decentralized Internet.
It's real easy to do. It is not the case that you are dependent on Google search. You're imposing artificial limits on yourself. Break free of this limiting mindset.
These kind of comments are so strange... why do you want Google to own your FTP client instead of having an independent one?
I tend to agree with you, but would you mind fleshing this out a bit. Or, if you've written this before please point to it.
Chrome is a duopoly, and Firefox tends to get forced in the same direction as Chrome over time -- it's not powerful enough to push the web as a whole in a different direction.
If Chrome was not a duopoly, this would not be a problem. There's nothing fundamentally wrong with having a browser that's highly optimized for nontechnical users. However, because Chrome has such control, pushing technical users out of Chrome has the effect of pushing technical users out of the web entirely. By putting itself into a dominant market position, Chrome has put itself in the (unenviable) position of needing to be everything for everyone.
In other words, if Chrome doesn't support power users, and if Firefox doesn't have the guts to refuse to make the changes they advocate for, then power users have no where to go. This is why monopolies and duopolies are bad even if the companies behind them are good. Its completely unrealistic for a single product to be everything for everyone, so single products by their very nature exclude certain users.
----
So who cares if power users abandon the web?
This is a problem because historically, power users have been incredibly important for the web's development. They've been important not just in the sense that they've pushed the web forward technically, but also because the web was designed to be a democratizing medium. The web is designed to be a publishing platform where people can build weird things without asking anyone's permission.
Even non-technical users benefit from this -- it's in their best interest to have lots of providers providing lots of solutions for publishing because (repeating what I said above) no one platform can be everything for everyone. A non-technical web that is optimized for ordinary people to the exclusion of power users is going to be less creative, less interesting, and less useful even for ordinary people.
Whether or not FTP in particular is critical to that -- I don't know. I don't know enough about FTP to make a strong argument on that. I will say I have used FTP a lot as a consumer, especially when downloading packages, and I have used FTP on internal networks. I'm not an expert, but the arguments package maintainers make about why SSL is unimportant to FTP ring true to me. My understanding is that package signing prevents modification attacks, and that looking at request sizes is enough to identify resources even with SSL.
As a policy, deprecating URL types that don't support encryption seems at first glance to be a really dumb move, and I'm not sure the security arguments justify it. But I'm not an expert.
----
I'm on Firefox, and I'm hopeful that Firefox is going to see a resurgence of usage pretty soon, particularly among power users. If Firefox refuses to deprecate FTP, I'm not so worried, since honestly I think it's probably in everyone's best interest for Chrome to do a few dumb things that make more power-users jump ship to Firefox. A lot of power users aren't willing to make the switch on ideological grounds; Chrome as a browser needs to get much, much worse to encourage them to use competitors.
Thankfully, it appears that (especially recently) the Chrome dev team has been thinking the same thing.
EDIT: 'danShumway and 'ajnin together essentially summarized my thinking here.
Web is built and maintained by technically proficient people so it needs them to be comfortable. There is no unified group of "power users"; everyone doing something regularly becomes a "power user" in that context to the extent they are able to. If you remove their ability to grow, you're condemning them to wasting their time and reducing utility of the web for them.
A real strange thing...
Not to worry though, I'm sure Google is just doing it for everyone's best interests, like the charitable organization for humanity that they are.
FTP is an awful protocol and there are other perfectly fungible open standard replacements for it, like HTTP/HTTPS. FTP dates from the era before NAT and firewalls and makes a bunch of problematic design choices, like having the server establish a separate port connection to the client (or vice versa, for passive mode) to transfer the file. It's super chatty, requiring multiple waits for response, and therefore slow. There's no length check, so if your socket gets closed you silently save a half-finished file.
FTP should just die off.
IMO, browsers need to concern themselves with HTTP. Anything else gets handed off to an application that's designed for it.
Now that's so much better and more secure!
I'm a fairly young person. What I've seen over the past few years is technology is finally useful and accessible to everyone. Forcing people to use the command line isn't a useful skill for 99.5% of people anymore, it's just senseless gatekeeping to make it a computer requirement. I got into computers by ripping into Windows XP internals and learning how it worked when I was a kid, no command line needed.
There will always be people who are more curious about how things work. Have faith that kids are smart enough to use the internet to learn for themselves.
Just because technology is easier does not mean it's harder to learn how to be "technically competent". Remember that the definition of technically competent moves with the times, too.
Before, a huge portion of the population was using computers and had to peek under the hood. This means you got a lot more people who got curious about how the machine worked very early on.
I am teaching STEM stuff to kids these days-- programming in Scratch and python, etc. My friends and I, back in the day, were all poking around memory, rekeying Basic programs from magazines and moving on to writing Turbo Pascal programs, etc, at a pretty early age. I don't see this with the kids I teach. There's not as good of a path/funnel there, and I'm not sure whether the stuff we do to e.g. teach programming in elementary school, etc, are analogous exercises in computational thinking.
I think there's something fundamentally wrong with the way cs is taught, but its hard to teach computers in a class setting. You really need to inspire that deep interest that so many of us have in computers, and it's very tough to get at that in the modern day. Because of the overload of information and media that kids are getting thrown at them these days. It's very easy to sit down 20 kids and make a game in scratch, and call it computer science.
We should have kids use technologies that professionals use in their work. Setup a flask web server, write a scraper, use apis, etc. Stop dumbing down things, expect more from the younger generation. Those coding bootcamps sure as heck don't teach scratch right?
I've also taught primary school kids (elementary) similar things, though fairly limited. Overwhelming what I've seen is most of them are fine with the tool they're shown and not much more, but those who do want to learn more aren't hampered by lack of exposure to the command line. Maybe a bit further behind, but they can figure it out quickly.
I think the trade off between this and computers being far more accessible is worth it.
macOS kind of does this, whether intentionally or not. On the surface, it's a basic consumer machine, with a web browser, media player, and office suite. But dig a little deeper, and you'll discover Automator, a great little tool for automating menial tasks which puts you in a programmer mindset. Probe deeper still, and you may discover the Terminal icon, full of secrets to be discovered.
It could be taken further. Imagine if TextEdit had built-in syntax highlighting whenever it detected code. "Regular" users would never see the highlighting, and professional programmers would stick to real IDE's or more advanced editors. But as a hidden built-in, it could be a wonderful stepping stone.
Now compare all of this to iOS. Yes, it's true, no one really wants to program on an iPhone anyway—but what happens if you give a child an iPad instead of a laptop? There's now much less opportunity for them to grow and discover more. This isn't to say that every child with a Mac will discover the terminal and become a power user, but some will, and be thankful for the opportunity.
Stuff like renaming 200 files, or converting 200 images to a different size, or normalizing 200 audio files you recorded yesterday, or finding the right few words in 200 files all can be done with minutes of effort once you unlock those powers. I use 200 because that's about how many times people are willing to sit there and bang out something manually. Tasks larger than that people tend to give up on, or buy a tool to help. The neat thing is, the same solution for 200 items could be applied to 200 million items without changes.
I would love for the full power of the CLI to be available to everybody without training. Until that gift comes from on high, we use the tools we have, GUI or text or SMS or whatever. Today you can pick your path.
The internet does unlock all of those doors to those who want to learn. There are incredible resources for learning new things and fixing problems that others have ran into. Reading man pages and printed manuals may be fun for some, but I'd rather search for answers, and chip in some when I can.
I'm not saying the command line isn't useful, it's insanely useful to me, but I and presumably you are the 0.5% of people that do things like batch organising thousands of files. Most people will just have a basic folder structure on a cloud service somewhere and they're fine with that.
My point is that the general population doesn't need to be exposed to the command line to be able to go deeper into learning computers. Those who need it will hopefully find it.
It's good that computers are more accessible. But by making it easy, we're providing less opportunity for people who are curious about innards at an early age.
Of course, now we're teaching computational thinking in schools, but IMO it's a really big open question whether our attempts to teach that work, especially in elementary school.
Understanding the inner workings of computers is not a fundamental good. Solving problems and achieving one's goals are the important thing. If people can use computers to solve problems better today but they don't understand how bootloaders work then I think that is a good trade off.
From what I understand, it's a low level rendering issue.
Source: I wrote the initial version of those patches, though I think Markus has basically rewritten them all at this point.
People like to cargo cult TLS as if it's the only option but it's really not, even debian doesn't use https (and gets quite a bit of backlash despite understanding very well their security model): https://whydoesaptnotusehttps.com/
I've seen a lot of naive designs where signed data is downloaded via an unsigned control channel. At the very least, they are vulnerable to replay attacks. Beyond that, it enables more selective blocking/filtering to prevent clients from accessing specific data.
Let's not forget the lost "confidentiality" aspect of TLS either. Your request for HP_Drivers_2019_Update.exe is now broadcasting to the Internet: "Hey I'm running a vulnerable, unpatched device! Last chance to hack me!"
I don't get why there is so much resistance. It's an old, outdated technology that has to be replaced eventually. Yes, change is always painful. But this isn't like with RSS were the tech provided clear benefits we would loose.
????
Using FTP doesn't put your computer at increased risk of being hacked.
Not updating your browser _DOES_ put your computer at increased risk of being hacked.
In any case, integrating FTP in your browser absolutely increases your chances of an exploit, though. When was the last time the FTP code was tested? Or worked on at all? I suspect it will have been a very long time.
This is a specious argument because HTTP/HTTPS is regularly (and legally) MITM'ed[0, 1].
If we shouldn't use anything that can be MITM'ed, shouldn't we just shut down the internet? Wouldn't that stop MITM attacks permanently-like? What about phones? Or letters? Or even talking? Where does this scare-tactic of the MITM "boogey-man" end (for you)?
[0] - https://www.symantec.com/products/proxy-sg-and-advanced-secu...
[1] - https://www.occrp.org/en/daily/10431-kazakh-officials-delay-...
Also, this enables linear scale out, since not all ftp data nodes (not sure what the correct term was) need to store all of the data that’s being served, and you can store multiple copies of each file.
Come to think of it, I’m not sure why HDFS exists, given that you can just use a ftp server cluster for the same effect.
https://en.wikipedia.org/wiki/Heartbleed
(I mean, I'm not overjoyed at the deprecation of FTP support because I used it just yesterday, but let's at least be honest here. The protocol might be decades old but the implementations aren't necessarily, and if they're being actively maintained there's always the possibility of introducing new bugs.)
That's not the "stable protocol that's been around for decades" situation that FTP is in.
Many protocols evolve not by being replaced by incrementally better point releases, but rather by being supplanted entirely by a better designed alternative.
FTP effectively evolved into HTTP for this use case, and scp/sftp for the authenticated file transfer use case.
and there are other bugs in the implementation which further demotivates the FTP support.
To me that reads as there are bugs in Chrome's implementation of FTP.
Did you take that to mean the author intended to convey the message that the FTP protocol has bugs?
My direct and blunt rebuttal is "I don't care". The future is worthless without the present, and more importantly, the past. The continued effective destruction of history that these big tech companies are doing with their actions is a disturbing trend.
I think it's pretty much a given since most clients change to PASV mode as a first step. And it's rare that people have a port open to them (behind all firewalls, etc)
I don't think Chrome ever supported Gopher, but if some other browser removed something that worked fine before I wouldn't like it either.
I am more worried about the very realistic that that Google would be dropping FTP from search results, seeing as how their users won't be able to open them in the Google browser.
Is that really the case though? Wordpress ( Love it or Hate it ), both .com and self hosted is still thriving.
And if people are writing less blog, I think it has more to do with Social Media ( Facebook ) than RSS or Google Search / Reader.
The big problem at the time was there was no good options, even a year or so after and I gave up trying. Everything was 90% of the way or too fancy for such a simple service.
However I have been wanting to selfhost more so evaluating moving to either FreshRSS or TinyRSS,
I wish there were guard rails for learners (I guess a proper permissions scheme would do) or a safe place to explore (probably lots online at this point). Agreed that for most people, storing files in Dropbox lets them get real work done without a second thought, and that in itself is A Good Thing.
That is literally the point I was making when I said, "if they're being actively maintained there's always the possibility of introducing new bugs."
Moreover, just because a library had its last fix a decade (or whatever) ago is no guarantee that unfixed bugs do not lie undiscovered in it.
Why using email? I switch between phones, OSs etc and it was a bitch to find decent clients for the self hosted options on each OS. I can generally get my email everywhere, via ActiveSync on my phone, WebUI, thunderbird etc. And since I host my mail, the data never leaves my network :) It works really well, though I do sometimes feel like RMS having web pages emailed to me lol