FTP/FTPS looks like it's gradually being deprecated. What are Windows + browser clients moving to and what...
up vote
0
down vote
favorite
In the past I've used FTP over TLS to let non-technical friends and family remotely access important files on my server.
I've just found that they can't do so using Firefox any more, and the firefox bug/feature states that FTP is heading for being "clearly deprecated" and FTP over TLS is being tagged as WONTFIX (Mozilla link1 link2 but see also link3). I also can't get IE11 in Win8.1 to connect either (most family are on 8.1 not 10).
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
I assume a not-especially-technical client user who wants it to "just work"within the default OS or their usual browser, and not download specific FTP/client software just to add that capability. The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Of course decent FTP clients will support this and will exist for many years, but the point was that an ftp(s):// URI has been usable in browsers for decades but now clearly won't be (or won't reliably be). So what should I do, to give them what they need/expect insead?
windows ftp network-protocols
add a comment |
up vote
0
down vote
favorite
In the past I've used FTP over TLS to let non-technical friends and family remotely access important files on my server.
I've just found that they can't do so using Firefox any more, and the firefox bug/feature states that FTP is heading for being "clearly deprecated" and FTP over TLS is being tagged as WONTFIX (Mozilla link1 link2 but see also link3). I also can't get IE11 in Win8.1 to connect either (most family are on 8.1 not 10).
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
I assume a not-especially-technical client user who wants it to "just work"within the default OS or their usual browser, and not download specific FTP/client software just to add that capability. The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Of course decent FTP clients will support this and will exist for many years, but the point was that an ftp(s):// URI has been usable in browsers for decades but now clearly won't be (or won't reliably be). So what should I do, to give them what they need/expect insead?
windows ftp network-protocols
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
In the past I've used FTP over TLS to let non-technical friends and family remotely access important files on my server.
I've just found that they can't do so using Firefox any more, and the firefox bug/feature states that FTP is heading for being "clearly deprecated" and FTP over TLS is being tagged as WONTFIX (Mozilla link1 link2 but see also link3). I also can't get IE11 in Win8.1 to connect either (most family are on 8.1 not 10).
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
I assume a not-especially-technical client user who wants it to "just work"within the default OS or their usual browser, and not download specific FTP/client software just to add that capability. The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Of course decent FTP clients will support this and will exist for many years, but the point was that an ftp(s):// URI has been usable in browsers for decades but now clearly won't be (or won't reliably be). So what should I do, to give them what they need/expect insead?
windows ftp network-protocols
In the past I've used FTP over TLS to let non-technical friends and family remotely access important files on my server.
I've just found that they can't do so using Firefox any more, and the firefox bug/feature states that FTP is heading for being "clearly deprecated" and FTP over TLS is being tagged as WONTFIX (Mozilla link1 link2 but see also link3). I also can't get IE11 in Win8.1 to connect either (most family are on 8.1 not 10).
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
I assume a not-especially-technical client user who wants it to "just work"within the default OS or their usual browser, and not download specific FTP/client software just to add that capability. The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Of course decent FTP clients will support this and will exist for many years, but the point was that an ftp(s):// URI has been usable in browsers for decades but now clearly won't be (or won't reliably be). So what should I do, to give them what they need/expect insead?
windows ftp network-protocols
windows ftp network-protocols
asked Nov 21 at 15:26
Stilez
6631719
6631719
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
So what should I do, to give them what they need/expect insead?
IMHO the expectations need to change. This is 2018, not 1992.
In the early 90's when Web browsers were a new thing, browsers had to plan to support things other than HTTP because:
- The Web was barely out of the hands of the academics. So everything online was static text and image documents, and that's what HTML was doing back then. HTTP itself was really a file transfer mechanism.
- Since HTTP was new, it wasn't a given at that time that HTTP would pretty much be the most common protocol on the web. There were others before HTTP - so you had browsers supporting Gopher, FTP, integrated with email clients, etc.
So back then integrating FTP support in the browser made sense.
Of course, it wasn't long before CGI made HTTP a primitive interactive protocol, then Javascript, XHR/AJAX, Webkit, websockets, Webkit, WebRTC, and all the other things browsers support besides display and formatting of static documents.
So now: HTTP(S) is not a simple file transfer mechanism like FTP any longer but really an application delivery mechanism - and static documents are just one possible application. The perspective of a browser not being in the same category as an FTP client and not supporting protocols other than HTTP(S) is very reasonable these days.
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
What non-technical people are doing these days is using cloud services like Dropbox/Google Drive/OneDrive to move files, at the cost of privacy of course.
The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Microsoft is moving to the cloud model for this, and is pushing OneDrive for this purpose.
There is WebDAV, but you will have to run a webserver, and WebDAV is often difficult to get working properly due to Windows quirks.
Want to do it yourself and not run a webserver? The answer is SCP. Your non-technical users will simply have to learn to use an SCP client. It isn't hard.
SCP has many benefits over FTP, some of which are:
- It's based on SSH, which has a long history, so it's secure and encrypted by default.
- Uses one port instead of two and does not need "passive mode" or firewall workarounds. Simply forward the single port on your router and you are good.
- You can administrate users in the same manner as FTP.
SCP can do file transfers. It does not provide directory listing or other file management features. So it's not really comparable to FTP. You maybe meant SFTP instead, didn't you?
– Martin Prikryl
Nov 21 at 20:05
I really don't want them to need a separate client, too much handholding/"what-is-this" risk - and as a bonus I get to have to maintain it. I could use my freenas server, which has NextCloud built in. Could that do the job of replacing FTPS, if so what are the pros and cons?
– Stilez
Nov 22 at 12:51
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
So what should I do, to give them what they need/expect insead?
IMHO the expectations need to change. This is 2018, not 1992.
In the early 90's when Web browsers were a new thing, browsers had to plan to support things other than HTTP because:
- The Web was barely out of the hands of the academics. So everything online was static text and image documents, and that's what HTML was doing back then. HTTP itself was really a file transfer mechanism.
- Since HTTP was new, it wasn't a given at that time that HTTP would pretty much be the most common protocol on the web. There were others before HTTP - so you had browsers supporting Gopher, FTP, integrated with email clients, etc.
So back then integrating FTP support in the browser made sense.
Of course, it wasn't long before CGI made HTTP a primitive interactive protocol, then Javascript, XHR/AJAX, Webkit, websockets, Webkit, WebRTC, and all the other things browsers support besides display and formatting of static documents.
So now: HTTP(S) is not a simple file transfer mechanism like FTP any longer but really an application delivery mechanism - and static documents are just one possible application. The perspective of a browser not being in the same category as an FTP client and not supporting protocols other than HTTP(S) is very reasonable these days.
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
What non-technical people are doing these days is using cloud services like Dropbox/Google Drive/OneDrive to move files, at the cost of privacy of course.
The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Microsoft is moving to the cloud model for this, and is pushing OneDrive for this purpose.
There is WebDAV, but you will have to run a webserver, and WebDAV is often difficult to get working properly due to Windows quirks.
Want to do it yourself and not run a webserver? The answer is SCP. Your non-technical users will simply have to learn to use an SCP client. It isn't hard.
SCP has many benefits over FTP, some of which are:
- It's based on SSH, which has a long history, so it's secure and encrypted by default.
- Uses one port instead of two and does not need "passive mode" or firewall workarounds. Simply forward the single port on your router and you are good.
- You can administrate users in the same manner as FTP.
SCP can do file transfers. It does not provide directory listing or other file management features. So it's not really comparable to FTP. You maybe meant SFTP instead, didn't you?
– Martin Prikryl
Nov 21 at 20:05
I really don't want them to need a separate client, too much handholding/"what-is-this" risk - and as a bonus I get to have to maintain it. I could use my freenas server, which has NextCloud built in. Could that do the job of replacing FTPS, if so what are the pros and cons?
– Stilez
Nov 22 at 12:51
add a comment |
up vote
1
down vote
So what should I do, to give them what they need/expect insead?
IMHO the expectations need to change. This is 2018, not 1992.
In the early 90's when Web browsers were a new thing, browsers had to plan to support things other than HTTP because:
- The Web was barely out of the hands of the academics. So everything online was static text and image documents, and that's what HTML was doing back then. HTTP itself was really a file transfer mechanism.
- Since HTTP was new, it wasn't a given at that time that HTTP would pretty much be the most common protocol on the web. There were others before HTTP - so you had browsers supporting Gopher, FTP, integrated with email clients, etc.
So back then integrating FTP support in the browser made sense.
Of course, it wasn't long before CGI made HTTP a primitive interactive protocol, then Javascript, XHR/AJAX, Webkit, websockets, Webkit, WebRTC, and all the other things browsers support besides display and formatting of static documents.
So now: HTTP(S) is not a simple file transfer mechanism like FTP any longer but really an application delivery mechanism - and static documents are just one possible application. The perspective of a browser not being in the same category as an FTP client and not supporting protocols other than HTTP(S) is very reasonable these days.
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
What non-technical people are doing these days is using cloud services like Dropbox/Google Drive/OneDrive to move files, at the cost of privacy of course.
The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Microsoft is moving to the cloud model for this, and is pushing OneDrive for this purpose.
There is WebDAV, but you will have to run a webserver, and WebDAV is often difficult to get working properly due to Windows quirks.
Want to do it yourself and not run a webserver? The answer is SCP. Your non-technical users will simply have to learn to use an SCP client. It isn't hard.
SCP has many benefits over FTP, some of which are:
- It's based on SSH, which has a long history, so it's secure and encrypted by default.
- Uses one port instead of two and does not need "passive mode" or firewall workarounds. Simply forward the single port on your router and you are good.
- You can administrate users in the same manner as FTP.
SCP can do file transfers. It does not provide directory listing or other file management features. So it's not really comparable to FTP. You maybe meant SFTP instead, didn't you?
– Martin Prikryl
Nov 21 at 20:05
I really don't want them to need a separate client, too much handholding/"what-is-this" risk - and as a bonus I get to have to maintain it. I could use my freenas server, which has NextCloud built in. Could that do the job of replacing FTPS, if so what are the pros and cons?
– Stilez
Nov 22 at 12:51
add a comment |
up vote
1
down vote
up vote
1
down vote
So what should I do, to give them what they need/expect insead?
IMHO the expectations need to change. This is 2018, not 1992.
In the early 90's when Web browsers were a new thing, browsers had to plan to support things other than HTTP because:
- The Web was barely out of the hands of the academics. So everything online was static text and image documents, and that's what HTML was doing back then. HTTP itself was really a file transfer mechanism.
- Since HTTP was new, it wasn't a given at that time that HTTP would pretty much be the most common protocol on the web. There were others before HTTP - so you had browsers supporting Gopher, FTP, integrated with email clients, etc.
So back then integrating FTP support in the browser made sense.
Of course, it wasn't long before CGI made HTTP a primitive interactive protocol, then Javascript, XHR/AJAX, Webkit, websockets, Webkit, WebRTC, and all the other things browsers support besides display and formatting of static documents.
So now: HTTP(S) is not a simple file transfer mechanism like FTP any longer but really an application delivery mechanism - and static documents are just one possible application. The perspective of a browser not being in the same category as an FTP client and not supporting protocols other than HTTP(S) is very reasonable these days.
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
What non-technical people are doing these days is using cloud services like Dropbox/Google Drive/OneDrive to move files, at the cost of privacy of course.
The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Microsoft is moving to the cloud model for this, and is pushing OneDrive for this purpose.
There is WebDAV, but you will have to run a webserver, and WebDAV is often difficult to get working properly due to Windows quirks.
Want to do it yourself and not run a webserver? The answer is SCP. Your non-technical users will simply have to learn to use an SCP client. It isn't hard.
SCP has many benefits over FTP, some of which are:
- It's based on SSH, which has a long history, so it's secure and encrypted by default.
- Uses one port instead of two and does not need "passive mode" or firewall workarounds. Simply forward the single port on your router and you are good.
- You can administrate users in the same manner as FTP.
So what should I do, to give them what they need/expect insead?
IMHO the expectations need to change. This is 2018, not 1992.
In the early 90's when Web browsers were a new thing, browsers had to plan to support things other than HTTP because:
- The Web was barely out of the hands of the academics. So everything online was static text and image documents, and that's what HTML was doing back then. HTTP itself was really a file transfer mechanism.
- Since HTTP was new, it wasn't a given at that time that HTTP would pretty much be the most common protocol on the web. There were others before HTTP - so you had browsers supporting Gopher, FTP, integrated with email clients, etc.
So back then integrating FTP support in the browser made sense.
Of course, it wasn't long before CGI made HTTP a primitive interactive protocol, then Javascript, XHR/AJAX, Webkit, websockets, Webkit, WebRTC, and all the other things browsers support besides display and formatting of static documents.
So now: HTTP(S) is not a simple file transfer mechanism like FTP any longer but really an application delivery mechanism - and static documents are just one possible application. The perspective of a browser not being in the same category as an FTP client and not supporting protocols other than HTTP(S) is very reasonable these days.
I do provide SMB on the LAN but not WAN, and I'd like to not start running a full web server locally if avoidable. (Because having far greater unnecessary functionality also means scope for a wider attack surface: best avoided if not needed).
Given that scenario, what is the substitute expectation for users who have been using FTPS (or who have been using FTP and want to add TLS transport) to be doing instead?
What non-technical people are doing these days is using cloud services like Dropbox/Google Drive/OneDrive to move files, at the cost of privacy of course.
The functionality they need is as simple as "enter URI -> authenticate -> get file system root listing -> browse & search directories and up/download files".
Microsoft is moving to the cloud model for this, and is pushing OneDrive for this purpose.
There is WebDAV, but you will have to run a webserver, and WebDAV is often difficult to get working properly due to Windows quirks.
Want to do it yourself and not run a webserver? The answer is SCP. Your non-technical users will simply have to learn to use an SCP client. It isn't hard.
SCP has many benefits over FTP, some of which are:
- It's based on SSH, which has a long history, so it's secure and encrypted by default.
- Uses one port instead of two and does not need "passive mode" or firewall workarounds. Simply forward the single port on your router and you are good.
- You can administrate users in the same manner as FTP.
answered Nov 21 at 16:10
LawrenceC
58.4k10100178
58.4k10100178
SCP can do file transfers. It does not provide directory listing or other file management features. So it's not really comparable to FTP. You maybe meant SFTP instead, didn't you?
– Martin Prikryl
Nov 21 at 20:05
I really don't want them to need a separate client, too much handholding/"what-is-this" risk - and as a bonus I get to have to maintain it. I could use my freenas server, which has NextCloud built in. Could that do the job of replacing FTPS, if so what are the pros and cons?
– Stilez
Nov 22 at 12:51
add a comment |
SCP can do file transfers. It does not provide directory listing or other file management features. So it's not really comparable to FTP. You maybe meant SFTP instead, didn't you?
– Martin Prikryl
Nov 21 at 20:05
I really don't want them to need a separate client, too much handholding/"what-is-this" risk - and as a bonus I get to have to maintain it. I could use my freenas server, which has NextCloud built in. Could that do the job of replacing FTPS, if so what are the pros and cons?
– Stilez
Nov 22 at 12:51
SCP can do file transfers. It does not provide directory listing or other file management features. So it's not really comparable to FTP. You maybe meant SFTP instead, didn't you?
– Martin Prikryl
Nov 21 at 20:05
SCP can do file transfers. It does not provide directory listing or other file management features. So it's not really comparable to FTP. You maybe meant SFTP instead, didn't you?
– Martin Prikryl
Nov 21 at 20:05
I really don't want them to need a separate client, too much handholding/"what-is-this" risk - and as a bonus I get to have to maintain it. I could use my freenas server, which has NextCloud built in. Could that do the job of replacing FTPS, if so what are the pros and cons?
– Stilez
Nov 22 at 12:51
I really don't want them to need a separate client, too much handholding/"what-is-this" risk - and as a bonus I get to have to maintain it. I could use my freenas server, which has NextCloud built in. Could that do the job of replacing FTPS, if so what are the pros and cons?
– Stilez
Nov 22 at 12:51
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377319%2fftp-ftps-looks-like-its-gradually-being-deprecated-what-are-windows-browser%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown