If a malicious program had access to a token that performed decryptions using the master key, it could have the token decrypt all the sector keys and then peruse the disk at its leisure without further access to the token.
Just because you are a linux fanatic, doesn't change the fact that IBM is one of the most evil, terrible corporations in existance. But hey, its not like knowingly designing systems to more efficiently track and kill jews is even close to the evils of accusing someone of copyright infringment, right?
Corporations are amoral. Their actions may be wrong and terrible, but they cannot accrue moral guilt. Only the people responsible can. Any people who might have committed the acts you allege are surely no longer involved with IBM. It is silly to suggest that IBM is evil in perpetuity.
Both of your replies are potentially ways to get around DRM. However, I still don't see how DRM on Linux, to which they would have to publish the source code, gets us that much.
Of course, there's a little clause in the GPL about modifying and redistributing the software...
You fail to understand how technologies such as TCPA and Palladium (or whatever they're calling it now) are going to work. The availability of the source code would change nothing. The key to implementing DRM is that the security chip on the motherboard would possess a private key not obtainable by the end user, and the corresponding public key would be signed by the motherboard manufacturer. The hardware would be such that the security chip would only attest, using its private key, that the computer was running a Trusted Operating Root with a particular hash if it were actually doing so. The availability of source code to the TOR would make it easier to create a modified version, but DRM-protected content providers would presumably only supply content to systems running a TOR from a list of those known to correctly implement DRM.
The plans I am aware of for implementing DRM that go by such names as "Trusted Computing" represent a sound use of cryptography, in the sense that they simply cannot be bypassed by software without breaking the underlying cryptographic primitives, unless there are errors in the implementation.
Number of security flaws acknowledged by DJB, you mean? It might hurt your religious feelings, but even the holy qmail is not perfect.
Although that page does list various bugs and idiosyncratic, intentional RFC violations by DJB, it is still quite noteworthy that the only security issues involve resource exhaustion and delayed bounces, and the resource exhaustion attack can be fixed with ulimit. One could have left qmail running on a box 4 years ago, and it would not be compromised today, and if someone could reboot it if DOS'd, it would still be working properly. The same can be said for very few other network services.
There's a bright red section that says all ideas for code and/or challenges must be the coder's alone. Using a tool, which you yourself didn't write, to generate actual code, is thus not permitted because the tool will use ideas that aren't yours to generate the code.
I grant that this rule is very fuzzy (e.g., code that implements a well-known algorithm is fine, even though the idea for the algorithm isn't yours), but the rules give TopCoder and/or Google the right to interpret the fuzzy rule however they want, and this is how they will, based on a thread in the discussion boards on TopCoder's site a while ago.
I know you're joking, but since the AC reply says that's an interesting idea, I just wanted to point out that it's against the rules unless you wrote the converter yourself (it's fine to do so ahead of time).
Unless I'm parsing this wrong, it sounds like one can't use any language, only 1 of the 4 listed. (It's also odd that C isn't there but some proprietary languages are)
Just for the record, although you're parsing that sentence correctly, the way TopCoder works is that there are 3 problems per contest, and you may use any of the 4 available languages for each problem, so you could use 3 of the 4 listed if you really wanted to. I would hope it's spelled out correctly somewhere in the official rules, as opposed to Google's promotional copy.
Actually, the GTLD servers are not returning results consistent with each other, which accounts for the fact that some people are seeing NXDOMAIN somtimes and not others. Currently, it looks like a through e return 64.94.110.11, and f through m return NXDOMAIN.
The following is edited to satisfy the lameness filter.
$ for i in a b c d e f g h i j k l m; do host `apg -M l -m 15 -n 1`.com $i.gtld-servers.net; echo; done
Using domain server: Name: a.gtld-servers.net
tacbimutuvorgox.com has address 64.94.110.11
Using domain server: Name: b.gtld-servers.net
dyrithsarsujbel.com has address 64.94.110.11
Using domain server: Name: c.gtld-servers.net
reorwomreackbie.com has address 64.94.110.11
Using domain server: Name: d.gtld-servers.net
pojkoarkojwonja.com has address 64.94.110.11
Using domain server: Name: e.gtld-servers.net
rarnenwobnajfun.com has address 64.94.110.11
Using domain server: Name: f.gtld-servers.net
Host ebtupbyljocfeik.com not found: 3(NXDOMAIN)
Using domain server: Name: g.gtld-servers.net
Host bojawadudeownaw.com not found: 3(NXDOMAIN)
Using domain server: Name: h.gtld-servers.net
Host outkabebdadbeaf.com not found: 3(NXDOMAIN)
Using domain server: Name: i.gtld-servers.net
Host apdysespirsosso.com not found: 3(NXDOMAIN)
Using domain server: Name: j.gtld-servers.net
Host duafkocediotyad.com not found: 3(NXDOMAIN)
Using domain server: Name: k.gtld-servers.net
Host nervejadmofmajy.com not found: 3(NXDOMAIN)
Using domain server: Name: l.gtld-servers.net
Host quejrajcezavdio.com not found: 3(NXDOMAIN)
Using domain server: Name: m.gtld-servers.net
Host esfomuvwegonnye.com not found: 3(NXDOMAIN)
Though honestly, you could use whatever you wanted with the proper network setup. After all, if the stuff isn't visible to the rest of the world, then it doesn't matter what you use. Worst case scenerio is that you might stumble upon a computer in the real world with the same IP address as you, but that'd be rare. It might not even be a problem if you accessed it by a DNS entry through a DNS server that was external to your network, but I can't say that for sure.
You're wrong. How the computer obtains the IP address is irrelevant. When it attempts to send a packet to that IP address, it will be routed to the computer with that address on the private network rather than the one in the real world.
Re:So if you run kazaa through something like this
on
MIT Roofnet
·
· Score: 1
Pfft. I go to MIT, and I've never heard of anyone being kicked out for file sharing that infringed copyright. That would have been major news.
Indeed, MIT has a specific official policy for handling notices of copyright infringement, as it does for many things. To summarize, first offense: warning, second offense: temporary loss of network access, third offense: indefinite loss of network access, subject to the outcome of a hearing before the Committee on Discpline. The COD has incredible discretionary power, but I would be surprised if the consequence was disproportionate to the consequence for the second offense. However, I would also be surprised if a student were stupid enough to continue copyright infringement so persistently that it would get to that point.
Furthermore, MIT does not scan its networks for copyright infringement, as it respects privacy fairly strictly. Of course, it will act if notified of infringement.
In summary, being sued for significant damages is much worse than being punished by MIT.
The scenario Jane Doe is fighting is the one where you don't know about the subpoena until the RIAA shows up at your door with a summons and a lawsuit. In any case, I strongly suggest seeking legal advice to deal with it. That's not a plug for lawyers, it's just that
I've heard lots of people voice bad ideas about how to respond and many of those ideas would just make a bad situation worse.
BS. Cheaters and those that make the cheats are nothing more than criminals. Illegally reverse engineering copywrited software. You should be treated the same as others who crack software.
It's not illegal to reverse engineer copyrighted software under the DMCA, it's illegal to do it to circumvent a measure that controls access to a copyrighted work. I.e., it's illegal to crack copy protection. I don't see any reason why it would be illegal to reverse engineer a game to create a cheat. Even if it is illegal, it shouldn't be, IMO, because reverse engineering a product you bought should not be a crime. However, IANAL.
No, it doesn't. If SCO didn't explicitely choose to include the code in Linux (it really is stolen, as they claim), then SCO also didn't explicitely choose to license the code under the GPL. And if that's the case, then the GPL doesn't apply to their code, and it reverts to the standard Berne Convention rules.
OK, fine, let's say SCO has not released their code under the GPL. Then they are distributing Linux, which they do not hold the copyright to, without complying with the terms of the GPL, which requires them to cause it (which allegedly includes their proprietary code) to become licensed to all third parties under the terms of the GPL, so they are guilty of willful copyright infringement (since they continued to distribute it long after filing the suit).
I own a company which writes a proprietary application sold to the public. It contains lib 'a' which is used for manipulating the general class of 'foo', something very useful. One of my employees releases the lib 'a' source under the GPL without corporate knowledge or acquiescence. This is then incorporated into several other GPL'd applications, one of which we happen to distribute without knowing that a part of this application contains our source. Is lib 'a' now covered under the GPL because of our mistake?
It need not be. You need not agree to the GPL, because you have never signed it. However, you have no right to distribute the GPL'd application (except for lib 'a' itself) in question without following the terms of the GPL, becuase you do not hold the copyright to it. You should thus immediately stop distributing versions of the application that contain lib 'a' (as should third parties, who have no right to distribute lib 'a' at all). In contrast, SCO has continued to distribute Linux long after filing this suit. If they have not caused their proprietary code to be licensed under the GPL, they are committing willful copyright infringement. I don't see how there can be other options available to them. (Also, in your example, one would expect your company to inform third parties that you hold the copyright to lib 'a' specifically and ask them to stop distributing it. SCO has not done this. No one yet knows what SCO is claiming copyright to sepcifically.)
The point is that others cannot distribute GPL'd software containing SCO's proprietary code, but neither can SCO itself. That is the whole point of the GPL! If its claim that Linux contains SCO's proprietary code is correct, it must cease distributing Linux, or at least excise its code from the version it distributes. If SCO continues to distribute Linux without excising its code or releasing its code under the GPL, it should be sued for copyright infringement by the kernel team.
Here's why: If I get a job at Microsoft, and slip a bit of GPL code into the next Windows and Office release, without Microsoft's knowledge, it is just too bad for them and the whole thing is free (as in beer) now?
No, it means that Microsoft has either released it under the GPL or committed copyright infringement. They can cease distributing the version that includes the code they have no right to, and pay damages to the copyright holder. The latter option is no different than the consequences of an employee slipping in code copyrighted by someone else but not covered by the GPL.
Likewise, SCO can either claim that they have released the code in question under the GPL, or that they have committed copyright infringement by distributing code covered by the GPL (the rest of Linux that isn't the alleged proprietary SCO code) without complying with the terms of the GPL. The difference between the SCO case and the hypothetical Microsoft case is that the SCO case would be willful infringement, since they have continued to distribute Linux since they filed the suit.
The paper seems to skip around the huge unanswered question: Is there a private key that third parties know that it is impossible for the owner of the computer to know?
The second paper on the page answers that question in the affirmative (sort of). The private part of the endorsement key is stored on the chip, the manufacturer may record the public part. The paper states that IBM does not currently and has never recorded endorsement keys. (Note that technically the answer to your question is "no": there would be a private key that the user does not know, but no third party would know it either. You misunderstand public key cryptography. However, your general point is well-taken, because the endorsement key could be used to implement DRM, subject to the obvious caveat the author brings up, that it would be vulnerable to local hardware attacks.)
StringBuffer is a major offender; in a lame attempt to save one object allocation, it uses a simple reference counting device which requires synchronization for operations as trivial as appending a character. Writing a simple UnsynchronizedStringBuffer gave a measurable performance boost.
An UnsynchronizedStringBuffer will indeed be faster, but I don't understand your proposal for how StringBuffer could modify itself in a thread-safe manner without using synchronization. Could you explain? This seems quite impossible.
You don't appear to know much about synchronization in Java.
Take your first example. Synchronized methods obtain locks on the object this (or the Class object in the case of static methods), not on the variable referenced therein. If bar() is called while foo() is executing, bar() will not begin executing until foo() finishes. If this were the only synchronized code in a program, it would not be possible for that program to deadlock. However, Java does not find or break deadlocks.
Your second example is, as you say, a horrible use of synchronization. However, the correct way to be more fine-grained is to place the println statement in a synchronized block.
You are correct that using synchronization requires you to make sure your code doesn't deadlock, and to consider the reduction in concurrency. However, that really has little to do with the article. Nobody who seriously complains about Java's performance does so because it is possible to use synchronization improperly. This is a programmer error, not a language issue. The article addresses the myth that Java's implementation of locking is horrendously slow.
Slashdot Mirror
I don't believe you. Cite?
Note that both ECC and RSA are NP-complete
This has not been proven, nor is it even commonly believed to be true.
You do not know how SMTP works. No proper client will transmit the body of the message unless at least one RCPT TO command is accepted.
The George Foreman USB iGrill was an April Foll's joke. Your "coworker" couldn't possibly have one.
If a malicious program had access to a token that performed decryptions using the master key, it could have the token decrypt all the sector keys and then peruse the disk at its leisure without further access to the token.
Just because you are a linux fanatic, doesn't change the fact that IBM is one of the most evil, terrible corporations in existance. But hey, its not like knowingly designing systems to more efficiently track and kill jews is even close to the evils of accusing someone of copyright infringment, right?
Corporations are amoral. Their actions may be wrong and terrible, but they cannot accrue moral guilt. Only the people responsible can. Any people who might have committed the acts you allege are surely no longer involved with IBM. It is silly to suggest that IBM is evil in perpetuity.
Both of your replies are potentially ways to get around DRM. However, I still don't see how DRM on Linux, to which they would have to publish the source code, gets us that much.
Let them put DRM into Linux. That would be great!
Of course, there's a little clause in the GPL about modifying and redistributing the software...
You fail to understand how technologies such as TCPA and Palladium (or whatever they're calling it now) are going to work. The availability of the source code would change nothing. The key to implementing DRM is that the security chip on the motherboard would possess a private key not obtainable by the end user, and the corresponding public key would be signed by the motherboard manufacturer. The hardware would be such that the security chip would only attest, using its private key, that the computer was running a Trusted Operating Root with a particular hash if it were actually doing so. The availability of source code to the TOR would make it easier to create a modified version, but DRM-protected content providers would presumably only supply content to systems running a TOR from a list of those known to correctly implement DRM.
The plans I am aware of for implementing DRM that go by such names as "Trusted Computing" represent a sound use of cryptography, in the sense that they simply cannot be bypassed by software without breaking the underlying cryptographic primitives, unless there are errors in the implementation.
Number of security flaws acknowledged by DJB, you mean? It might hurt your religious feelings, but even the holy qmail is not perfect.
Although that page does list various bugs and idiosyncratic, intentional RFC violations by DJB, it is still quite noteworthy that the only security issues involve resource exhaustion and delayed bounces, and the resource exhaustion attack can be fixed with ulimit. One could have left qmail running on a box 4 years ago, and it would not be compromised today, and if someone could reboot it if DOS'd, it would still be working properly. The same can be said for very few other network services.
There's a bright red section that says all ideas for code and/or challenges must be the coder's alone. Using a tool, which you yourself didn't write, to generate actual code, is thus not permitted because the tool will use ideas that aren't yours to generate the code.
I grant that this rule is very fuzzy (e.g., code that implements a well-known algorithm is fine, even though the idea for the algorithm isn't yours), but the rules give TopCoder and/or Google the right to interpret the fuzzy rule however they want, and this is how they will, based on a thread in the discussion boards on TopCoder's site a while ago.
I know you're joking, but since the AC reply says that's an interesting idea, I just wanted to point out that it's against the rules unless you wrote the converter yourself (it's fine to do so ahead of time).
Unless I'm parsing this wrong, it sounds like one can't use any language, only 1 of the 4 listed. (It's also odd that C isn't there but some proprietary languages are)
Just for the record, although you're parsing that sentence correctly, the way TopCoder works is that there are 3 problems per contest, and you may use any of the 4 available languages for each problem, so you could use 3 of the 4 listed if you really wanted to. I would hope it's spelled out correctly somewhere in the official rules, as opposed to Google's promotional copy.
At my last check, only the "a", "c", and "d" COM servers are serving the global A record for *.COM.
Unfortunately, if only a, c, and d were doing it for *.com three hours ago, it's spreading. Now a through e are doing it for *.com.
Also, they're all currently doing it for *.net, so if you want to ignore broken nameservers, you have to ignore all the GTLD servers.
My personal DNS cache is simply returning NXDOMAIN for any query whose result contains a certain IP address :-)
Actually, the GTLD servers are not returning results consistent with each other, which accounts for the fact that some people are seeing NXDOMAIN somtimes and not others. Currently, it looks like a through e return 64.94.110.11, and f through m return NXDOMAIN.
The following is edited to satisfy the lameness filter.
$ for i in a b c d e f g h i j k l m; do host `apg -M l -m 15 -n 1`.com $i.gtld-servers.net; echo; doneUsing domain server: Name: a.gtld-servers.net
tacbimutuvorgox.com has address 64.94.110.11
Using domain server: Name: b.gtld-servers.net
dyrithsarsujbel.com has address 64.94.110.11
Using domain server: Name: c.gtld-servers.net
reorwomreackbie.com has address 64.94.110.11
Using domain server: Name: d.gtld-servers.net
pojkoarkojwonja.com has address 64.94.110.11
Using domain server: Name: e.gtld-servers.net
rarnenwobnajfun.com has address 64.94.110.11
Using domain server: Name: f.gtld-servers.net
Host ebtupbyljocfeik.com not found: 3(NXDOMAIN)
Using domain server: Name: g.gtld-servers.net
Host bojawadudeownaw.com not found: 3(NXDOMAIN)
Using domain server: Name: h.gtld-servers.net
Host outkabebdadbeaf.com not found: 3(NXDOMAIN)
Using domain server: Name: i.gtld-servers.net
Host apdysespirsosso.com not found: 3(NXDOMAIN)
Using domain server: Name: j.gtld-servers.net
Host duafkocediotyad.com not found: 3(NXDOMAIN)
Using domain server: Name: k.gtld-servers.net
Host nervejadmofmajy.com not found: 3(NXDOMAIN)
Using domain server: Name: l.gtld-servers.net
Host quejrajcezavdio.com not found: 3(NXDOMAIN)
Using domain server: Name: m.gtld-servers.net
Host esfomuvwegonnye.com not found: 3(NXDOMAIN)
Though honestly, you could use whatever you wanted with the proper network setup. After all, if the stuff isn't visible to the rest of the world, then it doesn't matter what you use. Worst case scenerio is that you might stumble upon a computer in the real world with the same IP address as you, but that'd be rare. It might not even be a problem if you accessed it by a DNS entry through a DNS server that was external to your network, but I can't say that for sure.
You're wrong. How the computer obtains the IP address is irrelevant. When it attempts to send a packet to that IP address, it will be routed to the computer with that address on the private network rather than the one in the real world.
Pfft. I go to MIT, and I've never heard of anyone being kicked out for file sharing that infringed copyright. That would have been major news.
Indeed, MIT has a specific official policy for handling notices of copyright infringement, as it does for many things. To summarize, first offense: warning, second offense: temporary loss of network access, third offense: indefinite loss of network access, subject to the outcome of a hearing before the Committee on Discpline. The COD has incredible discretionary power, but I would be surprised if the consequence was disproportionate to the consequence for the second offense. However, I would also be surprised if a student were stupid enough to continue copyright infringement so persistently that it would get to that point.
Furthermore, MIT does not scan its networks for copyright infringement, as it respects privacy fairly strictly. Of course, it will act if notified of infringement.
In summary, being sued for significant damages is much worse than being punished by MIT.
From the interview:
Wow, it looks like he reads Slashdot.
And $0.0007 * 100000 = $70, which means literally "seventy dollars", not "seventy cents."
BS. Cheaters and those that make the cheats are nothing more than criminals. Illegally reverse engineering copywrited software. You should be treated the same as others who crack software.
It's not illegal to reverse engineer copyrighted software under the DMCA, it's illegal to do it to circumvent a measure that controls access to a copyrighted work. I.e., it's illegal to crack copy protection. I don't see any reason why it would be illegal to reverse engineer a game to create a cheat. Even if it is illegal, it shouldn't be, IMO, because reverse engineering a product you bought should not be a crime. However, IANAL.
No, it doesn't. If SCO didn't explicitely choose to include the code in Linux (it really is stolen, as they claim), then SCO also didn't explicitely choose to license the code under the GPL. And if that's the case, then the GPL doesn't apply to their code, and it reverts to the standard Berne Convention rules.
OK, fine, let's say SCO has not released their code under the GPL. Then they are distributing Linux, which they do not hold the copyright to, without complying with the terms of the GPL, which requires them to cause it (which allegedly includes their proprietary code) to become licensed to all third parties under the terms of the GPL, so they are guilty of willful copyright infringement (since they continued to distribute it long after filing the suit).
I own a company which writes a proprietary application sold to the public. It contains lib 'a' which is used for manipulating the general class of 'foo', something very useful. One of my employees releases the lib 'a' source under the GPL without corporate knowledge or acquiescence. This is then incorporated into several other GPL'd applications, one of which we happen to distribute without knowing that a part of this application contains our source. Is lib 'a' now covered under the GPL because of our mistake?
It need not be. You need not agree to the GPL, because you have never signed it. However, you have no right to distribute the GPL'd application (except for lib 'a' itself) in question without following the terms of the GPL, becuase you do not hold the copyright to it. You should thus immediately stop distributing versions of the application that contain lib 'a' (as should third parties, who have no right to distribute lib 'a' at all). In contrast, SCO has continued to distribute Linux long after filing this suit. If they have not caused their proprietary code to be licensed under the GPL, they are committing willful copyright infringement. I don't see how there can be other options available to them. (Also, in your example, one would expect your company to inform third parties that you hold the copyright to lib 'a' specifically and ask them to stop distributing it. SCO has not done this. No one yet knows what SCO is claiming copyright to sepcifically.)
The point is that others cannot distribute GPL'd software containing SCO's proprietary code, but neither can SCO itself. That is the whole point of the GPL! If its claim that Linux contains SCO's proprietary code is correct, it must cease distributing Linux, or at least excise its code from the version it distributes. If SCO continues to distribute Linux without excising its code or releasing its code under the GPL, it should be sued for copyright infringement by the kernel team.
Here's why: If I get a job at Microsoft, and slip a bit of GPL code into the next Windows and Office release, without Microsoft's knowledge, it is just too bad for them and the whole thing is free (as in beer) now?
No, it means that Microsoft has either released it under the GPL or committed copyright infringement. They can cease distributing the version that includes the code they have no right to, and pay damages to the copyright holder. The latter option is no different than the consequences of an employee slipping in code copyrighted by someone else but not covered by the GPL.
Likewise, SCO can either claim that they have released the code in question under the GPL, or that they have committed copyright infringement by distributing code covered by the GPL (the rest of Linux that isn't the alleged proprietary SCO code) without complying with the terms of the GPL. The difference between the SCO case and the hypothetical Microsoft case is that the SCO case would be willful infringement, since they have continued to distribute Linux since they filed the suit.
The paper seems to skip around the huge unanswered question: Is there a private key that third parties know that it is impossible for the owner of the computer to know?
The second paper on the page answers that question in the affirmative (sort of). The private part of the endorsement key is stored on the chip, the manufacturer may record the public part. The paper states that IBM does not currently and has never recorded endorsement keys. (Note that technically the answer to your question is "no": there would be a private key that the user does not know, but no third party would know it either. You misunderstand public key cryptography. However, your general point is well-taken, because the endorsement key could be used to implement DRM, subject to the obvious caveat the author brings up, that it would be vulnerable to local hardware attacks.)
StringBuffer is a major offender; in a lame attempt to save one object allocation, it uses a simple reference counting device which requires synchronization for operations as trivial as appending a character. Writing a simple UnsynchronizedStringBuffer gave a measurable performance boost.
An UnsynchronizedStringBuffer will indeed be faster, but I don't understand your proposal for how StringBuffer could modify itself in a thread-safe manner without using synchronization. Could you explain? This seems quite impossible.
You don't appear to know much about synchronization in Java.
Take your first example. Synchronized methods obtain locks on the object this (or the Class object in the case of static methods), not on the variable referenced therein. If bar() is called while foo() is executing, bar() will not begin executing until foo() finishes. If this were the only synchronized code in a program, it would not be possible for that program to deadlock. However, Java does not find or break deadlocks.
Your second example is, as you say, a horrible use of synchronization. However, the correct way to be more fine-grained is to place the println statement in a synchronized block.
You are correct that using synchronization requires you to make sure your code doesn't deadlock, and to consider the reduction in concurrency. However, that really has little to do with the article. Nobody who seriously complains about Java's performance does so because it is possible to use synchronization improperly. This is a programmer error, not a language issue. The article addresses the myth that Java's implementation of locking is horrendously slow.