To clarify my intent, I was merely pointing out that
such an argument was a) inevitable and b) a sure winner.
For me the argument against allowing any large amount
of anonymous transmitting over the web is SPAM.
But protecting innocent consumers against money
grubbing businessman does not seem to be a high
priority with the Congress.
To me there is a very clear line. My car might
be carrying all sorts of illegal contraband. But the police
cannot just stop me and demand proof of ownership
for everything within it.
That does not mean I have a right
to carry illegal items in my auto, or that the police
cannot stop me when they have reasonable grounds
to believe that my car has illegal goods in it.
Similarly, the police/RIAA/whomever must never be
given the right to "inspect" p2p traffic to see what is
in it. My traffic is entitled to both a presumption of
innocence and privacy. I should not have to
prove on demand that I own the MP3 that
I am transferring.
On the other hand, If I put up a web site announcing
free Metallica downloads and giving my URL, I
believe that constitutes "reasonable grounds"
to search the material I offer for download.
At that point, even if I am not charging, I am
operating in the commercial space. It has long
been recognized that there is no right to provide
goods and services anonymously.
Anonymous speech needs protection, not anonymous
theft.
We need to focus on the preservation of the privacy
of legitimate communications, not that
we're losing access to a "free" cookie jar.
Exactly. The ISP needs to be able to prove that it is not
the source of DoS attacks and/or spam. So ultimately
for reasons totally unrelated to the RIAA they will have
logs to show who was the authorized user of an IP
address at any given instant.
Don't think of ISPs protecting file-sharers, shift it to
protecting distributers of child pornography. There is
no way that ISPs will not be forced by explicit law and/or
by the need to defend themselves to have such logs.
In fact, I can imagine a strong legal case that providing
untracable access to an IP network is an attractive nuisance
that the ISP knew, or should have known, would be used
in the commission of felonies. Big time liabilities lurking.
A binary parsing program? Oh you mean like RPC
or CORBA, or any of a thousand existing debugged
solutions that are more efficient in terms of
processing overhead and network utilization?
Oh that's right. I forgot. Those were designed
by Neanderthals before HTTP existed, so they
aren't worth looking at.
OK, if you have an extraordinary amount of CPU time
to waste, then compressed XML would work just fine.
You also need to be able to postpone processing
until large chunks are received, because compression
doesn't work well over small data transfers.
In the real world however, XML wastes bandwidth and
at least some processing power. Dynamic compression
would reduce the bandwidth waste (perhaps even
eliminate it) but only by increasing the processing
power being wasted to a truly bothersome level.
i have no problems with file transfers delivering
XML, just with using XML for what a binary protocol
or an adaptation layer (RPC, RMI, CORBA, etc.) should
have solved.
The "benefit" usually cited for using XMLs is that it
looks like HTTP traffic. Bypassing firewall controls
is not a benefit.
TRON is one of many excellent real-time kernels that are available. They solve a simple problem, so it is not surprising that there are many of them that are excellent.
When you application needs a minimal kernel, you can
probably select any of several and find it supports your
project perfectly well.
The advantage of moving up to Linux/BSD/Darwin/whatever is that you gain the ability to add a vast
library of public domain daemons and applications.
The disadvantage is that you gain the overhead to
support that flexibility.
it is true that Linux/BSD/etc. can now be considered
for a wider range of applications than they could
have five years ago. But if your device does not need
thsee capabilities, there is no point going with something
as complex as Linux or BSD. The real-time kernels,
like TRON are a better fit.
As for translating TRON documentation: I think you're right.
Given the availability of several excellent kernels, why
would a development team pick the one with documentation they can't read?
Exactly. The problem is that worthless patents are being
granted when both the law and prior practice say they
should be denied.
A public comment system that allowed challenges based
upon a) prior art, b) obviousness or c) insufficient
disclosure to implement the invention would do
wonders to curtail abuse.
Even if the parsing could be done in zero execution time,
XML is still consuming excessive network bandwidth.
XML is very flexible, and an excellent solution when flexibility is truly required in what the next data element is.
Howeveer, doubling (or worse) the network bandwidth used in
downloading a table in order to allow each record to
have a different set of fields is just plain stupid.
A realistic compromise is to use XML to describe different
"row formats" that will be used. And then to deliver each
row in a compact tagged binary format.
Save the full flexibility for transfers that need it, a text
document is a great example. There are too many options
for what might apply to the next paragraph for
a fixed format to be useful.
Would people buy MP3s offered for download in a convenient way? I think Apple's iTunes store clearly
shows that they will.
That is unless you think consumers prefer
AAC to MP3. Or prefer mild DRM to no DRM.
iTunes store customers are buying because they find
the use of AAC with its DRM to be acceptable for the
convenience and selection provided. Would they prefer
simple, totally standard, totally unrestricted MP3s?
Of course, who wouldn't?
The real question is: will someobody who find an
album on the iTunes store at a reasonable price
go check another site to see if it is
available there in MP3 format at the same or
a lower price?
Unless the alternate site has much lower prices,
I doubt it. I am hoping for competition, but a compelling
alternate has to have enough of a selection to make it
worthwhile to browse there.If you use a DRM-free
format then you will be dealing almost exclusively
with indie artists. I periodically browse CDBaby,
as do lots of other customers, so there is a market
willing to check out a site that presents unknown music
in a way that you have a good shot at finding a new
artist that you will like.
Will consumers browse sample downloads without any
clue as to what type of music is there? I doubt it.
On the flip side, when Apple opens the iTunes store
to independent distributors you will have a tough time
convincing the artists as to why they should use MP3
distribution. If you actually manage to compete on price
with Apple, they'll be interested. But economies of scale
are going to go a long way to giving the iTunes store
(or any large-scale distributor) a major advantage.
If you publish in a forum available to strangers
the hash code and a description of the content
then you are publishing that material. The
method of delivery is irrelevant. Nobody
considers UPS or FEDEX to be publishers
If you only publish the hash code in private
emails, then it might even be fair use. It
probably won't be worth the RIAA's efforts.
If somebody gathers the descriptions but
cleverly claims not to be the publisher
they will be on very thin ice. If a reasonable
person reading the description that matched
the hashcode would know it was copyrighted
material, then the index publisher should
have known it.
There are clear precedents from flea markets.
The organizer of the event cannot be responsible
for knowing that every item sold is illegal, but
they cannot duck responsibility if most of the
items sold are illegal. It reaches a point where
anyone should have known.
So ultimately, the controlling point remains making
of easily understood public indexes. If you do that,
you're violating copyrights, no matter how you
distribute. If you don't do that, then you aren't
that much of a threat.
That's the point. How you actually share the files is almost irrelevant. If a strangre can find out what you are offering,
and successfully download it, then so can the RIAA.
Encryption only protects you from opporunistic snooping.
But it, and any other form of obfuscation, is irrelevant if
you intend to tell the entire world how to get around
that obfuscation.
So definitely don't go abusing UDP and messing up network performance. You won't hide from the RIAA, you'll just mess up the network.
I suppose there are legitimate applications for anonymous sharing. I don't really think that stealing music is one of them. But if you really want to do this, why not simply
obscure what is being shared? That way network congestion control is left intact.
Any well administered network will interpret these
packets as a Denial of Service attack and kill them anyway.
If you just encrypt the material, nobody will know what you
are sharing.
Except of course for the directory you published telling people how to get this really neat download of X.
It doesn't matter how you distribute the material. If you make it possible for strangers to find your content and download it, then it will be possible for the RIAA to be
one of those strangers.
What can be done to ensure that anti-piracy efforts have no adverse effect on legitimate network traffic?
Can sufficient enforcement be done by simply targetting "blatant" infringers who advertise copyrighted material they do not have right for as being available for download by stranger? Or will filters be required to flag "suspect" transfers, and then follow up with a demand for proof
that you had the right to transfer that data?
For example: How do you differentiate between someone giving away
somebody else's music, and somebody transferring their
own copies from their home to the laptop while they
are on the road?
Are data transfers entitled to a presumption of innocence?
And to the best of my recollection, the ability to
run multiple consoles and multiple X windows
has been around for ages on Unix. And yes,
you can be logged on differently on each.
I know I was running my Linux system that
way back around 97, and it certainly was
not cutting edge stuff.
Allowing "ad hoc" messaging between programs is one
of the best methods for allowing users to customize
interactions between seperate applications. This was
applied with great success using ARexx on
the Amiga, and some using OSA/Applescript on Mac OS.
So I do not believe it would be a good general solution
to limit messaging to those paths pre-envisioned by
the vendors themselves. Letting the reciever know what
authority context the sender was operating in would
be a better approach.
Selling of modded X-Boxes is clearly an abuse of Microsoft's Trademark.
Modding the X-Box to bypass game security is
clearly a violation of the DMCA. Even if you are running
unauthorized third-party games rather than illegal copies, you are still using Microsoft's Intellectual Property contrary
to the software lisence that was granted with the sale of the unit.
On the other hand, even if disrupts Microsoft's business plans, you have the right to throw your X-Box into th trash. If you have th right to throw it away, you have the
right to salvage the parts. My hunch is that if you
can turn an X-Box into a Linux box without using
Microsoft ROMs that you have merely salvaged parts that
you owned anyway. That's completely legit, especially if
you are essentially just enabling the PC industry standard
parts.
I was going to comment. By gamaboy already posted, and so obviously has the rights to make comments on this article. The patent doesn't have to be filed for nearly a year, so I better play it safe.
"Great Scientists" by whose definition? I could believe that the probability of someone being recognized as a brilliant solo contributor who far exceeds those that he works with is probably diminished when he gains the maturity to be able to share his life with a family.
But the ability to work as part of a team in a sustained problem solving effort that cannot be totally planned?
Seems to me that a spouse and children would help
One of the patent attorneys for a former employer told me that the ideal patent is one that is totally incomprehensible to the reader until they
have successfully infringed upon it.
After attempting to read this patent and determine
what the actual algorithms being patented are, all
I can say is that this may be an ideal patent.
There are aspects that can be evolved, and some that can't.
XP, as championed, seems to work when the fundamental architecture of the system is either inherited or otherwise
done outside of the XP process.
A quick analogy from building construction:
Traditional methodologies have wanted to overspecify the building before allowing construction to begin. But there is no need to know where every office going to be,
and where the whiteboard will be placed relative to the desk before you start laying the foundation.
(I heard this analogy first from Ed Yourdon in the 70s).
The "non-methodology" "results oriented" / "project driven" approaches, in contrast, won't waste any resources
on analyzing the need for a basement until the second floor
is finished. After all, the second floor is more important
to the customer.
A good architectural design ensures the greatest independence between components, while allowing
identification of the critical supporting infrastructure.
With the building analogy, I can make the floor a
"component" so that I now only care about how much
total weigtht, the range of power/water/heat consumption
that it is allowed to have, amount of traffic it will
generate, etc. That way you can design stairs, supports,
elevators, power conduits and plumbing. Interior Walls, lighting and carpeting are all details.
There is a similar need in a system to be built with distributed components to correctly identify the fundamental infrastructure issues. If you mis-identify
details as being architectural, you'll bog down the project.
But if you dismiss fundamentals as details to be dealt with later, you'll be soon thrashing yourself against those fundamental barriers.
My evaluation of XP remains that it fails to address
identification of fundamental architectural issues.
But in its defense, the chaos method shoots the
messenger for even mentioning them. And chaos
is the dominant methodology deployed today.
XP is better than no methodology. But I agree
that it has flaws. The most important of which is that it
does not recognize the need for architectural design.
But if your company currently has no process at all,
you aren't going to be able to get an architectural
process recognized. Officially adopt XP, and try to
do the architectural work "off the books". Even that
is better than "quick and dirty".
Not only does a stationwagon full of harddrives
have a respectable sustained throughput rate,
the contents don't get screened by the firewall.
Ditto for the hardrives in a briefcase, or those
USB drives on a keychain.
Exploding capacities of storage drives have
implications on attempts to keep data within
boundaries, as well as attempts to getting it
from point A to point B.
Oh, I forgot to add, this "software first, hardware later", development approach requires that the software development tools be of high quality. With too many of the systems I evaluated, the tools were not of the quality
that any open systems developer would expect.
Slashdot Mirror
To clarify my intent, I was merely pointing out that such an argument was a) inevitable and b) a sure winner.
For me the argument against allowing any large amount of anonymous transmitting over the web is SPAM. But protecting innocent consumers against money grubbing businessman does not seem to be a high priority with the Congress.
To me there is a very clear line. My car might be carrying all sorts of illegal contraband. But the police cannot just stop me and demand proof of ownership for everything within it.
That does not mean I have a right to carry illegal items in my auto, or that the police cannot stop me when they have reasonable grounds to believe that my car has illegal goods in it.
Similarly, the police/RIAA/whomever must never be given the right to "inspect" p2p traffic to see what is in it. My traffic is entitled to both a presumption of innocence and privacy. I should not have to prove on demand that I own the MP3 that I am transferring.
On the other hand, If I put up a web site announcing free Metallica downloads and giving my URL, I believe that constitutes "reasonable grounds" to search the material I offer for download.
At that point, even if I am not charging, I am operating in the commercial space. It has long been recognized that there is no right to provide goods and services anonymously.
Anonymous speech needs protection, not anonymous theft.
We need to focus on the preservation of the privacy of legitimate communications, not that we're losing access to a "free" cookie jar.
Exactly. The ISP needs to be able to prove that it is not the source of DoS attacks and/or spam. So ultimately for reasons totally unrelated to the RIAA they will have logs to show who was the authorized user of an IP address at any given instant.
Don't think of ISPs protecting file-sharers, shift it to protecting distributers of child pornography. There is no way that ISPs will not be forced by explicit law and/or by the need to defend themselves to have such logs.
In fact, I can imagine a strong legal case that providing untracable access to an IP network is an attractive nuisance that the ISP knew, or should have known, would be used in the commission of felonies. Big time liabilities lurking.
A binary parsing program? Oh you mean like RPC or CORBA, or any of a thousand existing debugged solutions that are more efficient in terms of processing overhead and network utilization?
Oh that's right. I forgot. Those were designed by Neanderthals before HTTP existed, so they aren't worth looking at.
OK, if you have an extraordinary amount of CPU time to waste, then compressed XML would work just fine.
You also need to be able to postpone processing until large chunks are received, because compression doesn't work well over small data transfers.
In the real world however, XML wastes bandwidth and at least some processing power. Dynamic compression would reduce the bandwidth waste (perhaps even eliminate it) but only by increasing the processing power being wasted to a truly bothersome level.
i have no problems with file transfers delivering XML, just with using XML for what a binary protocol or an adaptation layer (RPC, RMI, CORBA, etc.) should have solved.
The "benefit" usually cited for using XMLs is that it looks like HTTP traffic. Bypassing firewall controls is not a benefit.
TRON is one of many excellent real-time kernels that are available. They solve a simple problem, so it is not surprising that there are many of them that are excellent. When you application needs a minimal kernel, you can probably select any of several and find it supports your project perfectly well.
The advantage of moving up to Linux/BSD/Darwin/whatever is that you gain the ability to add a vast library of public domain daemons and applications.
The disadvantage is that you gain the overhead to support that flexibility.
it is true that Linux/BSD/etc. can now be considered for a wider range of applications than they could have five years ago. But if your device does not need thsee capabilities, there is no point going with something as complex as Linux or BSD. The real-time kernels, like TRON are a better fit.
As for translating TRON documentation: I think you're right. Given the availability of several excellent kernels, why would a development team pick the one with documentation they can't read?
Exactly. The problem is that worthless patents are being granted when both the law and prior practice say they should be denied.
A public comment system that allowed challenges based upon a) prior art, b) obviousness or c) insufficient disclosure to implement the invention would do wonders to curtail abuse.
Even if the parsing could be done in zero execution time, XML is still consuming excessive network bandwidth.
XML is very flexible, and an excellent solution when flexibility is truly required in what the next data element is.
Howeveer, doubling (or worse) the network bandwidth used in downloading a table in order to allow each record to have a different set of fields is just plain stupid.
A realistic compromise is to use XML to describe different "row formats" that will be used. And then to deliver each row in a compact tagged binary format.
Save the full flexibility for transfers that need it, a text document is a great example. There are too many options for what might apply to the next paragraph for a fixed format to be useful.
Would people buy MP3s offered for download in a convenient way? I think Apple's iTunes store clearly shows that they will.
That is unless you think consumers prefer AAC to MP3. Or prefer mild DRM to no DRM.
iTunes store customers are buying because they find the use of AAC with its DRM to be acceptable for the convenience and selection provided. Would they prefer simple, totally standard, totally unrestricted MP3s? Of course, who wouldn't?
The real question is: will someobody who find an album on the iTunes store at a reasonable price go check another site to see if it is available there in MP3 format at the same or a lower price?
Unless the alternate site has much lower prices, I doubt it. I am hoping for competition, but a compelling alternate has to have enough of a selection to make it worthwhile to browse there.If you use a DRM-free format then you will be dealing almost exclusively with indie artists. I periodically browse CDBaby, as do lots of other customers, so there is a market willing to check out a site that presents unknown music in a way that you have a good shot at finding a new artist that you will like.
Will consumers browse sample downloads without any clue as to what type of music is there? I doubt it.
On the flip side, when Apple opens the iTunes store to independent distributors you will have a tough time convincing the artists as to why they should use MP3 distribution. If you actually manage to compete on price with Apple, they'll be interested. But economies of scale are going to go a long way to giving the iTunes store (or any large-scale distributor) a major advantage.
And how do they get that hash code?
If you publish in a forum available to strangers the hash code and a description of the content then you are publishing that material. The method of delivery is irrelevant. Nobody considers UPS or FEDEX to be publishers
If you only publish the hash code in private emails, then it might even be fair use. It probably won't be worth the RIAA's efforts.
If somebody gathers the descriptions but cleverly claims not to be the publisher they will be on very thin ice. If a reasonable person reading the description that matched the hashcode would know it was copyrighted material, then the index publisher should have known it.
There are clear precedents from flea markets. The organizer of the event cannot be responsible for knowing that every item sold is illegal, but they cannot duck responsibility if most of the items sold are illegal. It reaches a point where anyone should have known.
So ultimately, the controlling point remains making of easily understood public indexes. If you do that, you're violating copyrights, no matter how you distribute. If you don't do that, then you aren't that much of a threat.
That's the point. How you actually share the files is almost irrelevant. If a strangre can find out what you are offering, and successfully download it, then so can the RIAA. Encryption only protects you from opporunistic snooping. But it, and any other form of obfuscation, is irrelevant if you intend to tell the entire world how to get around that obfuscation.
So definitely don't go abusing UDP and messing up network performance. You won't hide from the RIAA, you'll just mess up the network.
I suppose there are legitimate applications for anonymous sharing. I don't really think that stealing music is one of them. But if you really want to do this, why not simply obscure what is being shared? That way network congestion control is left intact.
Any well administered network will interpret these packets as a Denial of Service attack and kill them anyway.
If you just encrypt the material, nobody will know what you are sharing.
Except of course for the directory you published telling people how to get this really neat download of X.
It doesn't matter how you distribute the material. If you make it possible for strangers to find your content and download it, then it will be possible for the RIAA to be one of those strangers.
What can be done to ensure that anti-piracy efforts have no adverse effect on legitimate network traffic?
Can sufficient enforcement be done by simply targetting "blatant" infringers who advertise copyrighted material they do not have right for as being available for download by stranger? Or will filters be required to flag "suspect" transfers, and then follow up with a demand for proof that you had the right to transfer that data? For example: How do you differentiate between someone giving away somebody else's music, and somebody transferring their own copies from their home to the laptop while they are on the road?
Are data transfers entitled to a presumption of innocence?
And to the best of my recollection, the ability to run multiple consoles and multiple X windows has been around for ages on Unix. And yes, you can be logged on differently on each. I know I was running my Linux system that way back around 97, and it certainly was not cutting edge stuff.
Allowing "ad hoc" messaging between programs is one of the best methods for allowing users to customize interactions between seperate applications. This was applied with great success using ARexx on the Amiga, and some using OSA/Applescript on Mac OS.
So I do not believe it would be a good general solution to limit messaging to those paths pre-envisioned by the vendors themselves. Letting the reciever know what authority context the sender was operating in would be a better approach.
There are really three distinct issues here:
I was going to comment. By gamaboy already posted, and so obviously has the rights to make comments on this article. The patent doesn't have to be filed for nearly a year, so I better play it safe.
"Great Scientists" by whose definition? I could believe that the probability of someone being recognized as a brilliant solo contributor who far exceeds those that he works with is probably diminished when he gains the maturity to be able to share his life with a family.
But the ability to work as part of a team in a sustained problem solving effort that cannot be totally planned? Seems to me that a spouse and children would help
No 'C++' returns the current value of 'C', but then increments 'C', so that 'C' now has a higher value.
An amazingly accurate self-assessment.
One of the patent attorneys for a former employer told me that the ideal patent is one that is totally incomprehensible to the reader until they have successfully infringed upon it.
After attempting to read this patent and determine what the actual algorithms being patented are, all I can say is that this may be an ideal patent.
There are aspects that can be evolved, and some that can't. XP, as championed, seems to work when the fundamental architecture of the system is either inherited or otherwise done outside of the XP process.
A quick analogy from building construction:
A good architectural design ensures the greatest independence between components, while allowing identification of the critical supporting infrastructure. With the building analogy, I can make the floor a "component" so that I now only care about how much total weigtht, the range of power/water/heat consumption that it is allowed to have, amount of traffic it will generate, etc. That way you can design stairs, supports, elevators, power conduits and plumbing. Interior Walls, lighting and carpeting are all details.
There is a similar need in a system to be built with distributed components to correctly identify the fundamental infrastructure issues. If you mis-identify details as being architectural, you'll bog down the project. But if you dismiss fundamentals as details to be dealt with later, you'll be soon thrashing yourself against those fundamental barriers.
My evaluation of XP remains that it fails to address identification of fundamental architectural issues. But in its defense, the chaos method shoots the messenger for even mentioning them. And chaos is the dominant methodology deployed today.
That's the chaotic way of doing it.
The build-as-you-go approach releases a subset of the components with with a subset of the features. But that subset should still work.
XP is better than no methodology. But I agree that it has flaws. The most important of which is that it does not recognize the need for architectural design. But if your company currently has no process at all, you aren't going to be able to get an architectural process recognized. Officially adopt XP, and try to do the architectural work "off the books". Even that is better than "quick and dirty".
Not only does a stationwagon full of harddrives have a respectable sustained throughput rate, the contents don't get screened by the firewall. Ditto for the hardrives in a briefcase, or those USB drives on a keychain.
Exploding capacities of storage drives have implications on attempts to keep data within boundaries, as well as attempts to getting it from point A to point B.
Oh, I forgot to add, this "software first, hardware later", development approach requires that the software development tools be of high quality. With too many of the systems I evaluated, the tools were not of the quality that any open systems developer would expect.