Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1234 > unrolled thread

Ideas on solving the file transfer problem

Back to article view | Back to comp.programming

Contents

  Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-15 17:17 +0000
    Re: Ideas on solving the file transfer problem "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-01-15 18:35 +0100
      Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-15 18:07 +0000
        Re: Ideas on solving the file transfer problem "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-01-15 20:19 +0100
          Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-15 19:42 +0000
    Re: Ideas on solving the file transfer problem Willem <willem@toad.stack.nl> - 2012-01-15 19:15 +0000
      Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-15 20:10 +0000
    Re: Ideas on solving the file transfer problem Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-18 09:16 -0600
      Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-19 16:26 +0000
        Re: Ideas on solving the file transfer problem Robert Wessel <robertwessel2@yahoo.com> - 2012-01-19 14:59 -0600
          Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-19 21:22 +0000
            Re: Ideas on solving the file transfer problem Robert Wessel <robertwessel2@yahoo.com> - 2012-01-19 15:54 -0600
              Re: Ideas on solving the file transfer problem root <NoEMail@home.org> - 2012-01-19 22:20 +0000
                Re: Ideas on solving the file transfer problem Robert Wessel <robertwessel2@yahoo.com> - 2012-01-19 17:43 -0600
                  Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-20 04:22 +0000
                    Re: Ideas on solving the file transfer problem Robert Wessel <robertwessel2@yahoo.com> - 2012-01-19 23:43 -0600
                      Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-20 12:59 +0000
                    Re: Ideas on solving the file transfer problem Geoff <geoff@invalid.invalid> - 2012-01-20 02:41 -0800
                      Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-20 12:45 +0000
                        Re: Ideas on solving the file transfer problem Geoff <geoff@invalid.invalid> - 2012-01-20 15:41 -0800
                          Re: Ideas on solving the file transfer problem root <NoEMail@home.org> - 2012-01-21 00:18 +0000
                            Re: Ideas on solving the file transfer problem Geoff <geoff@invalid.invalid> - 2012-01-20 16:41 -0800
                              Re: Ideas on solving the file transfer problem Robert Wessel <robertwessel2@yahoo.com> - 2012-01-20 18:44 -0600
                        Re: Ideas on solving the file transfer problem Geoff <geoff@invalid.invalid> - 2012-01-20 15:43 -0800
                      Re: Ideas on solving the file transfer problem Robert Wessel <robertwessel2@yahoo.com> - 2012-01-20 18:34 -0600
                      Re: Ideas on solving the file transfer problem "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-01-21 10:21 +0000
                Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-20 03:59 +0000
              Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-20 03:44 +0000
                Re: Ideas on solving the file transfer problem Robert Wessel <robertwessel2@yahoo.com> - 2012-01-19 23:41 -0600
      Re: Ideas on solving the file transfer problem Ian Collins <ian-news@hotmail.com> - 2012-01-20 14:07 +1300
        Re: Ideas on solving the file transfer problem blp@cs.stanford.edu (Ben Pfaff) - 2012-01-19 18:20 -0800
        Re: Ideas on solving the file transfer problem Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-19 20:33 -0600
          Re: Ideas on solving the file transfer problem Rui Maciel <rui.maciel@gmail.com> - 2012-01-20 04:08 +0000

Page 1 of 2  [1] 2  Next page →

#1234 — Ideas on solving the file transfer problem

The following xkcd comic caught my attention:

http://xkcd.com/949/

Indeed, it appears that transfering files over the internet is still an open 
question.  Email is only a viable option if the file size is relatively 
small, and it really depends on the whims of the email service providers 
involved in a file transfer.  

Adding to this problem, a third party is deedlessly involved in this, which 
is a security problem and it threatens the privacy of each part involved in 
transfering files.  This problem also affects any form of alternative which 
relies on a third party web hosting service.

IM services may represent the best option which is currently available, but 
they rely on a user registering an account, which may not be convenient.  In 
some cases the file transfer also involves a third party, which brings all 
the problems which were already mentioned.

Other options, such as setting up a FTP server, are too convoluted and 
technically demanding for a couple of techincally illiterate users (i.e., 
the vast majority of internet users) to rely on this method to transfer 
files.

Is there any relevant method to transfer files on the interent?


Rui Maciel

[toc] | [next] | [standalone]

#1235

On Sun, 15 Jan 2012 17:17:50 +0000, Rui Maciel wrote:

> The following xkcd comic caught my attention:
> 
> http://xkcd.com/949/
> 
> Indeed, it appears that transfering files over the internet is still an open 
> question.

Well, it is rather a closed question. You should not transfer files, do
data instead. File is a container object for certain types of data
persistent in a file system. As such it has limitations and usage areas.
UNIX was in some sense responsible for overuse of files. It was the UNIX's
false idea that everything were a file.

> Is there any relevant method to transfer files on the interent?

Specifically to transfer files, depending on the topology of the publishers
and subscribers, their coupling, mutual trust, connectivity QoS etc:

http://en.wikipedia.org/wiki/Rsync
http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29
http://en.wikipedia.org/wiki/Network_File_System_%28protocol%29

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#1236

Dmitry A. Kazakov wrote:

> On Sun, 15 Jan 2012 17:17:50 +0000, Rui Maciel wrote:
> 
>> The following xkcd comic caught my attention:
>> 
>> http://xkcd.com/949/
>> 
>> Indeed, it appears that transfering files over the internet is still an
>> open question.
> 
> Well, it is rather a closed question. You should not transfer files, do
> data instead. File is a container object for certain types of data
> persistent in a file system. As such it has limitations and usage areas.

If a user wants to send/receive a file, why is this any relevant?


> UNIX was in some sense responsible for overuse of files. It was the UNIX's
> false idea that everything were a file.

This is silly.


>> Is there any relevant method to transfer files on the interent?
> 
> Specifically to transfer files, depending on the topology of the
> publishers and subscribers, their coupling, mutual trust, connectivity QoS
> etc:
> 
> http://en.wikipedia.org/wiki/Rsync
> http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29
> http://en.wikipedia.org/wiki/Network_File_System_%28protocol%29

Unfortunately, neither of those technologies solves the problem of providing 
a convenient way for user A to transfer a file to user B.  Rsync is employed 
to synchronize files from multiple locations, bittorrent is designed to 
transfer files from multiple servers to multiple clients and NFS is employed 
to provide remote access to a file system.  None of these scenarios are 
applicable to a simple use case of transfering a file between two users, 
such as the one described in the xkcd comic.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1238

On Sun, 15 Jan 2012 18:07:41 +0000, Rui Maciel wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Sun, 15 Jan 2012 17:17:50 +0000, Rui Maciel wrote:
>> 
>>> The following xkcd comic caught my attention:
>>> 
>>> http://xkcd.com/949/
>>> 
>>> Indeed, it appears that transfering files over the internet is still an
>>> open question.
>> 
>> Well, it is rather a closed question. You should not transfer files, do
>> data instead. File is a container object for certain types of data
>> persistent in a file system. As such it has limitations and usage areas.
> 
> If a user wants to send/receive a file, why is this any relevant?

He does not want it, he is put in a position when all choices are bad. The
user wants to publish a photo, to modify meeting minutes, to confirm money
transaction etc. It the OS which forces him to send files rather than
perform actions he really wants and needs.

>>> Is there any relevant method to transfer files on the interent?
>> 
>> Specifically to transfer files, depending on the topology of the
>> publishers and subscribers, their coupling, mutual trust, connectivity QoS
>> etc:
>> 
>> http://en.wikipedia.org/wiki/Rsync
>> http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29
>> http://en.wikipedia.org/wiki/Network_File_System_%28protocol%29
> 
> Unfortunately, neither of those technologies solves the problem of providing 
> a convenient way for user A to transfer a file to user B.

You didn't describe the setup. If the condition is that none of more or
less advanced file transfer protocols is available, then, well, none of
them is.

> Rsync is employed 
> to synchronize files from multiple locations, bittorrent is designed to 
> transfer files from multiple servers to multiple clients and NFS is employed 
> to provide remote access to a file system.

All of them were designed to transfer files.

> None of these scenarios are 
> applicable to a simple use case of transfering a file between two users, 
> such as the one described in the xkcd comic.

I don't know what a "simple use case" is. Are you presuming that E-mail is
available, but the NFS mount is not? Why? What if the user has no computer
at all? No OS installed? etc. You must define the setup. Once you did it,
e.g. Windows 7, no system administrator on either side etc, then the answer
will become obvious.

Returning to the beginning, transferring files always will be complex,
because it is a wrong abstraction. The Internet industry circumvents files,
at least in the user interfaces, you don't see them. Note that this
requires a very complex environment of browsers, plug-ins, applets,
servlets etc. Rendering a simple web page involves a huge amount of work
equivalent to transfer of many files. The user does not see this and does
not care. He gets what he wants.

This is the ultimative answer to the cartoon. If you need to transfer a
file, get a better environment where you would not need to worry about
files anymore.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#1239

Dmitry A. Kazakov wrote:

>> If a user wants to send/receive a file, why is this any relevant?
> 
> He does not want it, he is put in a position when all choices are bad. The
> user wants to publish a photo, to modify meeting minutes, to confirm money
> transaction etc. It the OS which forces him to send files rather than
> perform actions he really wants and needs.

I 

>>>> Is there any relevant method to transfer files on the interent?
>>> 
>>> Specifically to transfer files, depending on the topology of the
>>> publishers and subscribers, their coupling, mutual trust, connectivity
>>> QoS etc:
>>> 
>>> http://en.wikipedia.org/wiki/Rsync
>>> http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29
>>> http://en.wikipedia.org/wiki/Network_File_System_%28protocol%29
>> 
>> Unfortunately, neither of those technologies solves the problem of
>> providing a convenient way for user A to transfer a file to user B.
> 
> You didn't describe the setup. If the condition is that none of more or
> less advanced file transfer protocols is available, then, well, none of
> them is.

Read the original post.


>> Rsync is employed
>> to synchronize files from multiple locations, bittorrent is designed to
>> transfer files from multiple servers to multiple clients and NFS is
>> employed to provide remote access to a file system.
> 
> All of them were designed to transfer files.

Read the original post.


>> None of these scenarios are
>> applicable to a simple use case of transfering a file between two users,
>> such as the one described in the xkcd comic.
> 
> I don't know what a "simple use case" is. Are you presuming that E-mail is
> available, but the NFS mount is not? Why? 

I've explained in the original post why email wasn't an option.

Regarding the use of NFS to transfer a file, sending a file to someone 
though a pre-existing NFS service requires that either one is already 
available or that one is made available for the single purpose of 
sending/receiving a single file.  

If a NFS service is already available then it is provided by a third-party 
or it implies that an entire file system is exposed to someone just to be 
able to send them a file.  Suffice to say, this method won't do.


> What if the user has no computer
> at all? No OS installed? etc. You must define the setup. Once you did it,
> e.g. Windows 7, no system administrator on either side etc, then the
> answer will become obvious.

Read the original post.


> Returning to the beginning, transferring files always will be complex,
> because it is a wrong abstraction. The Internet industry circumvents
> files, at least in the user interfaces, you don't see them. Note that this
> requires a very complex environment of browsers, plug-ins, applets,
> servlets etc. Rendering a simple web page involves a huge amount of work
> equivalent to transfer of many files. The user does not see this and does
> not care. He gets what he wants.
> 
> This is the ultimative answer to the cartoon. If you need to transfer a
> file, get a better environment where you would not need to worry about
> files anymore.

It became quite clear that you don't know what you are talking about.  A 
file is a data dump.  Claiming that dumping data through a network "requires 
a very complex environment of browsers, plug-ins, applets, servlets etc." is 
a clear sign that you are oblivious to the issues regarding this.

As a side note, it is possible to send a file between two users by using 
tools such as netcat and telnet, both requiring zero file transfer 
protocols.  One client dumps the data, the other client pipes it to a file.  
Done.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1237

Rui Maciel wrote:
) The following xkcd comic caught my attention:
)
) http://xkcd.com/949/
)
) Indeed, it appears that transfering files over the internet is still an open 
) question.  Email is only a viable option if the file size is relatively 
) small, and it really depends on the whims of the email service providers 
) involved in a file transfer.  
)
) Adding to this problem, a third party is deedlessly involved in this, which 
) is a security problem and it threatens the privacy of each part involved in 
) transfering files.  This problem also affects any form of alternative which 
) relies on a third party web hosting service.
)
) IM services may represent the best option which is currently available, but 
) they rely on a user registering an account, which may not be convenient.  In 
) some cases the file transfer also involves a third party, which brings all 
) the problems which were already mentioned.
)
) Other options, such as setting up a FTP server, are too convoluted and 
) technically demanding for a couple of techincally illiterate users (i.e., 
) the vast majority of internet users) to rely on this method to transfer 
) files.
)
) Is there any relevant method to transfer files on the interent?

Another comic writer was way ahead of you: http://www.dilbertfiles.com/


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#1241

Willem wrote:

> Another comic writer was way ahead of you: http://www.dilbertfiles.com/

Indeed.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1242

Rui Maciel <rui.maciel@gmail.com> wrote:
 
> Is there any relevant method to transfer files on the interent?

Sure, but none that ticks all the boxes "easy", "convenient", "secure"
and "no third party involved".

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#1243

Leif Roar Moldskred wrote:

> Rui Maciel <rui.maciel@gmail.com> wrote:
>  
>> Is there any relevant method to transfer files on the interent?
> 
> Sure, but none that ticks all the boxes "easy", "convenient", "secure"
> and "no third party involved".

Maybe the world needs a FTP server designed with this in mind.  For example, 
if there was a FTP server which could be run on unpriviledged accounts and 
provided a convenient way to set up accounts with the single purpose of 
uploading a specific set of files to a specific client then maybe this 
problem could be solved.  Is there any program out there that is able to do 
this sort of thing?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1244

On Thu, 19 Jan 2012 16:26:41 +0000, Rui Maciel <rui.maciel@gmail.com>
wrote:

>Leif Roar Moldskred wrote:
>
>> Rui Maciel <rui.maciel@gmail.com> wrote:
>>  
>>> Is there any relevant method to transfer files on the interent?
>> 
>> Sure, but none that ticks all the boxes "easy", "convenient", "secure"
>> and "no third party involved".
>
>Maybe the world needs a FTP server designed with this in mind.  For example, 
>if there was a FTP server which could be run on unpriviledged accounts and 
>provided a convenient way to set up accounts with the single purpose of 
>uploading a specific set of files to a specific client then maybe this 
>problem could be solved.  Is there any program out there that is able to do 
>this sort of thing?


Binding to ports 20 and 21 is the least of the problems for an
unprivileged FTP server.  The big problem is that most firewalls will
never let that traffic in, so something like that won't happen without
the cooperation of the network security crew.  And given the
prevalence of NAT, you have address and DNS issues as well (which are
really more network issues).

[toc] | [prev] | [next] | [standalone]

#1245

Robert Wessel wrote:

> Binding to ports 20 and 21 is the least of the problems for an
> unprivileged FTP server.  The big problem is that most firewalls will
> never let that traffic in, so something like that won't happen without
> the cooperation of the network security crew.  

Domestic users tend to control their own firewalls.  Would they be affected 
by this?


> And given the
> prevalence of NAT, you have address and DNS issues as well (which are
> really more network issues).

DNS wouldn't be a problem, as domain names aren't exactly necessary.  NAT 
wouldn't be a bigger problem than it already is.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1246

On Thu, 19 Jan 2012 21:22:13 +0000, Rui Maciel <rui.maciel@gmail.com>
wrote:

>Robert Wessel wrote:
>
>> Binding to ports 20 and 21 is the least of the problems for an
>> unprivileged FTP server.  The big problem is that most firewalls will
>> never let that traffic in, so something like that won't happen without
>> the cooperation of the network security crew.  
>
>Domestic users tend to control their own firewalls.  Would they be affected 
>by this?


Well, sometimes they do.  But doesn't making such a change move this
out of the range of easy solution for the vast majority of users?

But FTP ports are commonly blocked by (residential) ISPs, along with
SMTP and a few others.  You can often ask to get them unblocked.


>> And given the
>> prevalence of NAT, you have address and DNS issues as well (which are
>> really more network issues).
>
>DNS wouldn't be a problem, as domain names aren't exactly necessary.  NAT 
>wouldn't be a bigger problem than it already is.


Given the two channel nature of FTP, NAT is a bigger problem than
usual.  Most firewalls that support FTP have specific code to deal
with the data connection.  PASV mode helps, but isn't usually the
default, and is often disabled on FTP servers.

But even the usual problems caused by NAT are bad enough, as it blocks
all incoming connections by default.  And NAT then imposes an extra
step to determine what the externally visible IP address is.

And without some DNS support, the fairly frequent reassignment of IP
addresses, particularly for residential users, makes using IP
addresses a challenge.  Remember, this needs to be easy.

Perhaps Skype would be a good solution (you can send files during a
conversation).

[toc] | [prev] | [next] | [standalone]

#1247

Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Thu, 19 Jan 2012 21:22:13 +0000, Rui Maciel <rui.maciel@gmail.com>
> wrote:
> 
>>Robert Wessel wrote:
>>
>>> Binding to ports 20 and 21 is the least of the problems for an
>>> unprivileged FTP server.  The big problem is that most firewalls will
>>> never let that traffic in, so something like that won't happen without
>>> the cooperation of the network security crew.  
>>
>>Domestic users tend to control their own firewalls.  Would they be affected 
>>by this?
> 
> 
> Well, sometimes they do.  But doesn't making such a change move this
> out of the range of easy solution for the vast majority of users?
> 
> But FTP ports are commonly blocked by (residential) ISPs, along with
> SMTP and a few others.  You can often ask to get them unblocked.
> 
> 
>>> And given the
>>> prevalence of NAT, you have address and DNS issues as well (which are
>>> really more network issues).
>>
>>DNS wouldn't be a problem, as domain names aren't exactly necessary.  NAT 
>>wouldn't be a bigger problem than it already is.
> 
> 
> Given the two channel nature of FTP, NAT is a bigger problem than
> usual.  Most firewalls that support FTP have specific code to deal
> with the data connection.  PASV mode helps, but isn't usually the
> default, and is often disabled on FTP servers.
> 
> But even the usual problems caused by NAT are bad enough, as it blocks
> all incoming connections by default.  And NAT then imposes an extra
> step to determine what the externally visible IP address is.
> 
> And without some DNS support, the fairly frequent reassignment of IP
> addresses, particularly for residential users, makes using IP
> addresses a challenge.  Remember, this needs to be easy.
> 
> Perhaps Skype would be a good solution (you can send files during a
> conversation).

I know the OP requested that no third party be involved, but
if that requirement is relaxed OneSwarm is a free solution.

[toc] | [prev] | [next] | [standalone]

#1248

On Thu, 19 Jan 2012 22:20:34 +0000 (UTC), root <NoEMail@home.org>
wrote:

>Robert Wessel <robertwessel2@yahoo.com> wrote:
>> On Thu, 19 Jan 2012 21:22:13 +0000, Rui Maciel <rui.maciel@gmail.com>
>> wrote:
>> 
>>>Robert Wessel wrote:
>>>
>>>> Binding to ports 20 and 21 is the least of the problems for an
>>>> unprivileged FTP server.  The big problem is that most firewalls will
>>>> never let that traffic in, so something like that won't happen without
>>>> the cooperation of the network security crew.  
>>>
>>>Domestic users tend to control their own firewalls.  Would they be affected 
>>>by this?
>> 
>> 
>> Well, sometimes they do.  But doesn't making such a change move this
>> out of the range of easy solution for the vast majority of users?
>> 
>> But FTP ports are commonly blocked by (residential) ISPs, along with
>> SMTP and a few others.  You can often ask to get them unblocked.
>> 
>> 
>>>> And given the
>>>> prevalence of NAT, you have address and DNS issues as well (which are
>>>> really more network issues).
>>>
>>>DNS wouldn't be a problem, as domain names aren't exactly necessary.  NAT 
>>>wouldn't be a bigger problem than it already is.
>> 
>> 
>> Given the two channel nature of FTP, NAT is a bigger problem than
>> usual.  Most firewalls that support FTP have specific code to deal
>> with the data connection.  PASV mode helps, but isn't usually the
>> default, and is often disabled on FTP servers.
>> 
>> But even the usual problems caused by NAT are bad enough, as it blocks
>> all incoming connections by default.  And NAT then imposes an extra
>> step to determine what the externally visible IP address is.
>> 
>> And without some DNS support, the fairly frequent reassignment of IP
>> addresses, particularly for residential users, makes using IP
>> addresses a challenge.  Remember, this needs to be easy.
>> 
>> Perhaps Skype would be a good solution (you can send files during a
>> conversation).
>
>I know the OP requested that no third party be involved, but
>if that requirement is relaxed OneSwarm is a free solution.


True, but there are already hundreds of millions of copies of Skype
installed, and most people have at least heard of it, and would likely
have fewer qualms installing it than something like OneSwarm, with
something like a thousandth the user base.

[toc] | [prev] | [next] | [standalone]

#1255

Robert Wessel wrote:

> True, but there are already hundreds of millions of copies of Skype
> installed, and most people have at least heard of it, and would likely
> have fewer qualms installing it than something like OneSwarm, with
> something like a thousandth the user base.

Skype does represent a middleman, and therefore a security and privacy 
threat.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1257

On Fri, 20 Jan 2012 04:22:05 +0000, Rui Maciel <rui.maciel@gmail.com>
wrote:

>Robert Wessel wrote:
>
>> True, but there are already hundreds of millions of copies of Skype
>> installed, and most people have at least heard of it, and would likely
>> have fewer qualms installing it than something like OneSwarm, with
>> something like a thousandth the user base.
>
>Skype does represent a middleman, and therefore a security and privacy 
>threat.


But the *entire* Internet is a middleman and a security threat.  If
you care, encrypt the file before you send it, no mater what the
method.

[toc] | [prev] | [next] | [standalone]

#1260

Robert Wessel wrote:

> But the entire Internet is a middleman and a security threat.  

This is true.  Yet, there is a considerable difference between having our 
traffic sniffed and simply handling our data to any mysterious third-party, 
inadvertently or not.  After all, just because we rely on a postal service 
to exchange letters with someone it doesn't mean it is a good idea to send 
them to some random person in the country that promissed to resend them to 
our intended destination.  

This becomes even less of a good idea if one of the demands put in place by 
that middleman is that we grant them the right to snoop our mail as he sees 
fit and even copy it just for kicks.  If it is quite possible to simply post 
our mailing directly to our intended destination then why should we even 
bother with this abuse?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#1258

On Fri, 20 Jan 2012 04:22:05 +0000, Rui Maciel <rui.maciel@gmail.com>
wrote:

>Robert Wessel wrote:
>
>> True, but there are already hundreds of millions of copies of Skype
>> installed, and most people have at least heard of it, and would likely
>> have fewer qualms installing it than something like OneSwarm, with
>> something like a thousandth the user base.
>
>Skype does represent a middleman, and therefore a security and privacy 
>threat.
>
>

It's only a middleman for establishing the connection between two
clients. Once the clients have negotiated a session they operate
peer-to-peer and the server never sees the streams. This is also true
for Windows Live Messenger, ICQ, AIM, and other messaging clients.

[toc] | [prev] | [next] | [standalone]

#1259

Geoff wrote:

> It's only a middleman for establishing the connection between two
> clients. Once the clients have negotiated a session they operate
> peer-to-peer and the server never sees the streams. 

It doesn't appear to be that way.  Although Skype's P2P nature has been 
widely publicized and supported, Skype still relies on a centralized client-
server model to handle communication.[1]  It is said that Skype only uses 
the company's servers as middlemen if it isn't possible to handle that 
communication directly between peers. Yet, unless someone actively monitors 
his network connection very closely, there is no way to know that.  

Adding to this, to be able to register an account with Skype, Skype requires 
that the user authorizes them to collect and use information regarding the 
user.[2]  This includes "traffic data", which includes "data processed for 
the purpose of the conveyance of communications".  It also includes "content 
of instant messaging communications".


> This is also true
> for Windows Live Messenger, ICQ, AIM, and other messaging clients.

Not quite.  I haven't checked ICQ, AIM or any other service, but MSN 
messenger's original protocol[3] also employes on what it defines as 
"switchboard servers" to "establish lightweight communication sessions 
without requiring a direct network connection between clients".  

Granted, this protocol may be old and possibly deprecated, and a number of 
revisions and major rewrites may already be released, but as no definition 
of those protocols has been made public, it isn't possible to simply assume 
that Windows Live Messenger does and does not.


Rui Maciel

[1] http://blog.makezine.com/2007/06/01/udp-hole-punching-how-skype-ge/
[2] http://www.skype.com/intl/en/legal/privacy/general/
[3] http://tools.ietf.org/html/draft-movva-msn-messenger-protocol-00

[toc] | [prev] | [next] | [standalone]

#1262

On Fri, 20 Jan 2012 12:45 +0000, Rui Maciel <rui.maciel@gmail.com>
wrote:

>Granted, this protocol may be old and possibly deprecated, and a number of 
>revisions and major rewrites may already be released, but as no definition 
>of those protocols has been made public, it isn't possible to simply assume 
>that Windows Live Messenger does and does not.

Then I suggest you get a protocol sniffer and test it yourself. I
believe the text traffic travels from client to server to client but
the file sharing (and I know this is true for IRC), is negotiated from
peer-to-peer once they have set up the session via the
client-server-client channel. At least that was the case as of several
years ago when I tested those protocols.

But these are not programming issues, they are protocol issues and at
least in the case of IRC, they are clearly documented in the
literature.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web