ISPs and filesharing contents / 2002-12-04

2002-12-04 ISPs and filesharing contents 17 years ago
Reply to SANS NewsBites Vol. 4 Num. 49 article/editorial comment

Quoting The SANS Institute who wrote on Wed, Dec 04, 2002 at 08:25:37AM -0700:

> --26 November 2002 ISPs May Limit Bandwidth Consumption
> Some high speed ISPs are considering placing limits on the amount of
> bandwidth their customers may consume each month. If they decide
> to do it, it could significantly curtail file-swapping activity,
> which makes up a large portion of network traffic.
> http://news.com.com/2100-1023-975320.html

> [Editor's Note (Schultz): Peer-to-peer file sharing not only consumes
> a great amount of network bandwidth, but it also often involves
> illegal downloading of copyrighted materials. One would think that
> ISPs would realize this and take measures to preclude such activity.

In my opinion, an ISP should not police the *content* of what you do with
your Internet connection. Who is the ISP to decide that any connection
made by the user is bad.

File sharing as-is does not damage the Internet. Part (yes, a large part)
of what offers is not legal to share. According to normal laws for the
countries the ISP clients are in. Those laws should apply. If a district
attorney or a judge orders a user disconnected for law-breaking, the ISP
should disconnect that user. The ISP should not police the content of what
their user does by itself. The user can then apply to this decision
through the normal ways of justice.

Your comment seems to suggest thinking along the lines (like the RIAA)
'since filesharing can and is abused for transferring content which has
copyrights applied, all filesharing must be forbidden'. This is the same
line of thinking as the RIAA showed in sueing mp3.com for making the mp3
format popular which can be used for transferring contents of CD's while
mp3.com only offers mp3 format files for which no copyright violations
occur by downloading them.

You might bring up open smtp relays here. These damage the structures
the Internet is build on.

Technical reasons are a reason to not allow certain types of traffic (such
as traffic seeming to originate from a different IP then your own). But an
ISP should be open and clear about what they filter and why. A change in
filtering should be seen as a change in the offered amount of "Internet"
so it is a change in contract between ISP and user.

Bytes transferred through an ISP are a finite resource. With a price.
Paying for overusage of this resource is reasonable to me, if the ISP
is clear enough on what they consider 'enough' and 'too many' bytes
transferred. A counter can be applied both by the customer and ISP to
see when the user is over his limits. This puts the choice how important
each of those bytes is to the user at the user who is responsible.

The original article has the order of things right. If people find they
have to be careful with their bandwidth usage, they should use it wisely.
Yes, this might make sharing files a lot less interesting, unless you
have something you really want to spread.

> Where I work someone has developed "KO," the "KaZaA Obliterator,"
> which detects and kills sessions involving use of KaZaA and other
> peer-to-peer file sharing programs altogether.

Work is a different place. At work, management can set rules on what can > (Shpantzer): One company working on the P2P bandwidth issue
> claims that these applications hog as much as 60% of bandwidth
> on the internet. Also see the link for a University of Chicago
> study of the Gnutella P2P network effects on bandwidth patterns.]
> http://www.theregister.co.uk/content/22/27092.html]

Koos van den Hout
(speaking for himself)


Tags: ,

, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews
This page generated in 0.004979 seconds.