Announcement

Collapse
No announcement yet.

Google Chrome 80 Released With WebVR 1.1, Dropping FTP Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by Paradigm Shifter View Post
    I think you took my response to another out of context, regarding why the maintainers of a scientific data archive only supported ftp, not sftp. They have nothing whatsoever to do with maintaining Chrome, which is what you appear to think I was talking about.
    If that is the case, yes I misunderstood you, good sir.

    but as I said multiple times in this thread already, acess to those servers will still work with any half-decent file manager and dedicated applications, while also migrating to http server for downloads is simple and does not increase server load or require to pay for certificates (There is Let's Encrypt that provides free certificates for https anyway)
    Last edited by starshipeleven; 14 February 2020, 05:37 AM.

    Leave a comment:


  • Paradigm Shifter
    replied
    Originally posted by starshipeleven View Post
    Development time. SFTP requires decent quality code as it is supposed to be "Secure". This is a web browser, they don't need more failure points.
    And there is literally 0 need for sftp in a browser. Anyone still using that has a client already.
    I think you took my response to another out of context, regarding why the maintainers of a scientific data archive only supported ftp, not sftp. They have nothing whatsoever to do with maintaining Chrome, which is what you appear to think I was talking about.
    Last edited by Paradigm Shifter; 13 February 2020, 10:43 PM. Reason: Clarity.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by chriswyatt View Post
    Most corporate machines would likely have another browser or dedicated FTP client installed, that would do the job just as well, or better, so (IMO) it's a change that's unlikely to affect many customers (but I could be wrong). If a corporation really needs that level of stability, then maybe they shouldn't be using a rolling release browser, anyway.
    This is correct, none uses Chrome to access internal FTP servers in a company environment. Windows Explorer (the default file manager) can natively browse FTP shares since ages ago and everyone uses that.

    Leave a comment:


  • chriswyatt
    replied
    Most corporate machines would likely have another browser or dedicated FTP client installed, that would do the job just as well, or better, so (IMO) it's a change that's unlikely to affect many customers (but I could be wrong). If a corporation really needs that level of stability, then maybe they shouldn't be using a rolling release browser, anyway.

    Leave a comment:


  • torsionbar28
    replied
    Originally posted by starshipeleven View Post
    ??? FTP does not provide any interface for that, the browser or filemanager does.
    Valid point, yes it is a client side thing, you're right.

    Originally posted by starshipeleven View Post
    This is changing the goalposts. You started "with FTP is better" and now it's about not paying the migration cost.
    No, those two points were a response to your "because they still can" argument. (1) Feature parity with HTTP, and (2) existing production system are two valid reasons for an organization to continue using FTP services. It's not a selfish or lazy "because we can" kind of thing at all.

    Originally posted by starshipeleven View Post
    Why support FTP in a browser when it offers no tangible improvement?
    Because people are using it. Because removing it, especially on such short notice, forces thousands of organizations worldwide to incur the cost of migrating services. Many organizations use Chrome as part of their standard desktop client image, so this change is killing off a feature that many folks are actively using. This isn't like deprecating support for Token ring, or 802.11b, it's like if Microsoft suddenly said they were ceasing support for the .ZIP file format. It breaks people's workflow and forces organizations to incur unplanned costs. And that's not a good thing.

    Maybe they announced this change long ago and I just missed it, but removing the feature in 2 versions, that's four months from now. Every IT shop I've worked at has project schedules that run more than four months out, making the timeline on this one pretty disruptive.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Jabberwocky View Post
    Due to NAT and encoding FTP should die, but some people don't know about anything else.
    People that can't learn new things will die with the old things.

    What would you recommend to use for low power devices like Pi Zero to share files.
    in a secure LAN anything goes, note that we were not talking of LAN usage. If you are using Chrome's basic FTP support in a LAN you are a weirdo, use your file manager instead.

    For a secure system over the internet, either a read-only http server if you just need a read-only share (mentioned above), or a very light https server with file upload support.
    There is one like that right here, https://github.com/Halcy0nic/SUBZero which is just a python script.
    Last edited by starshipeleven; 06 February 2020, 01:37 PM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by torsionbar28 View Post
    a more easily navigable folder structure.
    ??? FTP does not provide any interface for that, the browser or filemanager does.
    Chrome is just moving the load of maintaining the infrastructure from themselves to the website. And quite frankly there are 4 zillion frameworks that allow to make a dynamic download page already.

    Plus, correct me if I'm wrong, but I think FTP allows resuming an interrupted download while HTTP does not
    afaik it's wrong, http servers can let you resume interrupted downloads too (more specificially, start a new download from a specific offset). This can be disabled though and sometimes it is done to prevent the use of download managers (that use this feature to download more than one stream at the same time to increase the overall speed).

    You can easily try this with a download manager or with wget/curl.

    As for "they use ftp because they still can", another way to look at it, is that they use FTP today because it's an existing service/system that works just fine.
    This is changing the goalposts. You started "with FTP is better" and now it's about not paying the migration cost.

    Why switch to HTTP when it offers no tangible improvement?
    Why support FTP in a browser when it offers no tangible improvement?

    I would also posit that anon FTP is potentially more secure than HTTP
    which is mostly bs because http does not allow any input by default, and any input is sanitized (you can't do injections with plain http hyperlinks).

    I'm not talking of setting up Apache with Joomla and Wordpress garbage (php, database backing) to show a single download page.

    You can do the same job with very basic stuff like uhttpd https://github.com/nesv/uhttpd

    Leave a comment:


  • Jabberwocky
    replied
    Originally posted by starshipeleven View Post
    Technically correct, but only because you artificially limited the choice to sftp and rsync. If you are comparing FTP to "any of the better alternatives" as in his post, then the answer is "no there are no legitimate cases for FTP in 21st century".
    Due to NAT and encoding FTP should die, but some people don't know about anything else.

    What would you recommend to use for low power devices like Pi Zero to share files. Slow CPU without fixed function processors that handle hashing/encryption. Something that is as easy to use interactively and programmatically like ftp?

    I know devices like ZYMKEY 4i exist, but let's say physical space, shipping, or cost was an issue.

    Leave a comment:


  • torsionbar28
    replied
    Originally posted by starshipeleven View Post
    http servers can be (and should, and mostly are) used for the same job. It's not intrinsically different from what they already do (sending over a file to a client), and there are a bunch that are tiny and frugal.

    FTP is supposed to be a full file sharing protocol, anonymous read-only shares are using only like 20% of its functionality.

    Mobo vendors use ftp because they still can, not because FTP is somehow better.

    That's part of the point of Chrome developers and Google. The only legitimate FTP usecase on the web is limited to anonymous download repositories, and you can do exactly the same with a plain http server.
    I agree on most of your points. One advantage of FTP over HTTP though, for anon file distribution, is a more easily navigable folder structure. Plus, correct me if I'm wrong, but I think FTP allows resuming an interrupted download while HTTP does not, making FTP better for downloading large files. IMO these two features give FTP an advantage in this regard.

    As for "they use ftp because they still can", another way to look at it, is that they use FTP today because it's an existing service/system that works just fine. Why switch to HTTP when it offers no tangible improvement? Switching to something else has a cost associated with it, so from a business perspective, why incur the cost when HTTP offers no added value?

    I would also posit that anon FTP is potentially more secure than HTTP, only because an HTTP server is a larger more complex piece of code, where new vulnerabilities are more likely to be discovered and/or a sysadmin is more likely to misconfigure something.

    But FWIW, I don't really care that much either way, and don't use Chrome anyhow, so whatever.
    Last edited by torsionbar28; 06 February 2020, 12:32 PM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Jabberwocky View Post
    I don't understand your logic. How can you recommend X if you don't know Y's use? You should first determine Y before you can recommend X as a better alternative.
    it can be guessed within very reasonable margins. FTP capabilities are known.

    there are some legitimate cases where ftp is a better alternative over sftp or rsync.
    Technically correct, but only because you artificially limited the choice to sftp and rsync. If you are comparing FTP to "any of the better alternatives" as in his post, then the answer is "no there are no legitimate cases for FTP in 21st century".

    Leave a comment:

Working...
X