I read the brief. You are the one who seems to have the trouble reading. Try reading the DMCA. You'll see that it does not require service providers to remove anything. It merely provides them with a safe-harbor if they do remove content and follow certain rules.
Consequently, a service provider that recieves a takedown notice under the DMCA must, to avoid potential ligiation and liability, remove ore edit speech without being provided with even the minimal information necessary to determine whether the notifying entity's material actually falls within the scope of the works protected by copyright law and/or whether the challenged posts are infringing.
The key word there is potential. The DMCA allows people to avoid potential litigation under copyright law. In order to qualify for protection under the DMCA, you have to remove the content. That's not the same as saying the DMCA forces you to remove content. The DMCA does not force the ISP to remove anything. It merely provides the ISP with a defense against copyright infringement if they do remove the content.
In this and other ways the DCMA unconstittionally shifts the burden to service providers, such as FatWallet...or face a substantial risk of litigation without sufficient information to assess the true nature of that risk.
Right, and it's a bullshit argument whether it's made by FatWallet's lawyers or made by some bozo on Slashdot, and the courts will recognize it as such. The DMCA does not shift any burdens. It provides ISPs with safe-harbor if they follow certain rules.
The DMCA provision allowing for the issuance of subpoenas seeking information identifying the customers of an online service provider...
The subpoena arugment is a completely different argument, and for the most part I agree with it.
Where it could impact RIAA and the MPAA is that they would actually have to have pending litigation in order to file the subpoenas.
So? They file a John Doe lawsuit in court and then get subpoenas, I don't see the big deal.
RIAA and the MPAA might think twice before going after a file trader if they actually had to have a case prepared or where willing to go to court over twenty music files. That is the implications of this suit.
From what I've read they were only going after people sharing hundreds of music files. And I don't see how filing a John Doe lawsuit is much more of a barrier than getting a subpoena from a judge. For the most severe cases, they're going to be willing to do it anyway. For petty cases, they're not.
Further reading of the brief, and I will save you the quotes, states that it is also a violation of the Federal Rules of Civil Procedure to issue and demand response in a court other than the defendants court. It is article number 55.
Presumably the DMCA would overide such rules, since it was passed later.
In theory, yes. In practice, you could invent a device that ended world hunger and cured cancer in babies, but if it included a CD writer, the RIAA would be able to use the DMCA to stop you making it.
A congresscritter is not going to buy that argument. Since it's ridiculously untrue, I don't buy it either.
Hmm, according to this thread it seems that it's accidental, and you might even get charged for it. In any case, do you need a special phone to use it? I have the serial cable adapter, but it only seems to work at 14.4 when I connect. Is there a different number you need to dial? I use #777, I think.
So experimental drivers should not be included in the linux kernel?
Not in a released version of the kernel. Only in beta versions.
So if someone wants to use an experimental driver, they're stuck with using an entire experimental kernel? That's ridiculous.
As the author, you don't know if it affects the program or not. All you know is whether you believe that it affects the program. That's what beta testing is for.
Unless your code is using random gotos that's just not true. Your experimental functions are not going to be called unless the user requests those experimental features. Otherwise your program is seriously screwed up at the most basic level.
Huh? So you think that a program running at your user level presents no threat?
No, of course a program running at your user level poses a threat. But in order to expose that threat, you'd need to enable the experimental features. If the person exposed to the threat is the same person that enabled the experimental features, then it's an acceptable risk.
You believe that it's okay if it can modify and delete all of the same files that you can?
Of course. rm can modify and delete all the same files you can. You just have to pass it the appropriate parameters. By enabling experimental features you are explicitly acknowledging that you might run into a buffer overflow. In other words, by creating an Elgamel key, you acknowledge that key creation might crash. And by enabling experimental features on a program which uses untrusted input, you are explicitly acknowledging that you might lose all of the files you have access to delete. So when you sign an untrusted file using Elgamel, you acknowledge that you might lose all your files due to a buffer overflow exploit.
OK. Now i think I understand. The signing code for Elgamel broke in GPG 1.0.2. That broke key creation because key signing is part of key creation (by default, or always?) when creating Elgamel sign+encrypt keys.
I'd still say that signing using Elgamel keys is an experimental feature, though. And creation of Elgamel signing keys certainly is (as you said you had to use special flags).
I don't want to find out that the "choice" I made for a key type is something that 0.04% of people chose and that, because of its rarity, it had an undiscovered flaw.
I see. You must have just failed to read the announcement:
Note also that
ElGamal signing keys cannot be generated without the use of a special
flag to enable hidden options and even then overriding a warning
message about this key type.
I'm ssorry. You enable special hidden options and override warnings, and you've got no one to blame but yourself for making that choice.
Have you ever heard the term "beta"? If a feature is not well-tested, then it should not be in the base code.
So experimental drivers should not be included in the linux kernel?
Most people don't compile their own executables. Period.
And that's a good reason why the standard binaries should include as many features as possible, regardless of whether or not those features are experimental, so long as the inclusion of those features does not affect the program when they are not used.
Something as important as encryption should not be released with "experimental" code in it.
This wasn't so much experimental code as it was an experimental feature. The code worked fine. It was the algorithm itself which was exploited.
What's to say that there could not be a buffer overrun exploit that's a part of some rarely used, minimally tested part of the code?
Unless the binary is set up as setuid or setgid, that's irrelevant. The user running the program using experimental options is taking the risk that there might be such an exploit.
One of the arguments made that will impact RIAA and the MPAA is that the DCMA [sic] shifts the burden of proof of the copyright from the person claiming copyright to the person accused of violation.
Nonsense. The DMCA has nothing to do with burdons of proof. The DMCA gives an ISP safe-harbor from copyright infringement lawsuits if they remove the content. If the ISP refuses to remove the content, the copyright holder can then sue the ISP, and the burdon of proof (preponderance of the evidence in a civil case) is upon the copyright holder. If the ISP does remove the content, then they can't even be sued in the first place.
The implications would be chilling for the RIAA. Why? Because instead of firing off a couple hundred law suits, they would be forced to prove to the ISP that the subject of the supeonia had in fact violated copyrights.
Nope. That's not how it worked before the DMCA, and that's not how it would work if the DMCA was ever found unconstitutional. Instead of a DMCA takedown notice, the RIAA would simply send a cease and desist. If the ISP refused to comply with the cease and desist, they could be sued for willful copyright infringement.
The DMCA takedown notices are actually an improvement over standard copyright law. Unlike a cease and desist, there are mechanisms for counter-notification, there is a requirement that takedown notices be made under penalty of perjury, and there are specific penalties for making false accusations in a takedown notice.
The DMCA is a bad law, but not because of the takedown notices. The bad parts of the law are the circumvention clauses, and the subpoena clauses.
I could garountee you that if you sat me down infront of the senate and asked me to explain to them why the DMCA is bad I could convince them within an hour as could just about any well educated technically inclined individual could.
I highly doubt it. The DMCA is a natural extension of copyright law. If you create a device whose primary purpose is to subvert copyright law, then you're guilty of violating the DMCA. I fail to see how you're going to convince someone who agrees with copyright law that such a law is bad. At least, without misinforming them with what the law actually says. And most senators aren't going to fall for such misinformation.
If Congress legally passes a law that is Constitutional and within the scope of their legal right to legislate, and a judge deny's the application of that law because it "subverts the liberties of the people" you have in effect no government at all.
Impossible. A law which subverts the liberties of the people is not Constitutional.
Yeah, but the announcement says that "According to the keyserver statistics, there are 848 primary ElGamal signing keys which are affected." Which is damn close to 850.
Someone decided to munge Werner's announcement in a poorly implemented attempt at stopping spam. You have to change each "foo at example.com" to "foo@example.com". Then the.sig will verify correctly.
I'm not so sure this was an example of that. This was an experimental setting to begin with, and the fact that it is included in the base GPG code doesn't affect the people using the standard settings. As long as the experimental or rarely used code is kept separate from the rest of the program, the only problem is the extra source code you have to download and the extra binary size (if there's no option to #ifdef those sections out).
Unless of course you choose to use the features which aren't highly tested, of course. Then you're on your own.
So yeah, in many cases, they should just forbid the internet. Most accountants don't need it to do accountancy, for example. Most secretaries don't either.
I think you're the one with the backward logic. The internet is a tool which can be quite useful for both accountants and secretaries. Taking it away will produce less efficient workers, not more.
42) seems like quite a stretch. They seem to be fully admitting that they don't have any standing, and are relying on some kind of injury by proxy. I'd suspect their constitutionality claims will be thrown out for lack of standing.
Moreover, the whole argument seems poorly made. The DMCA does not require that Fatwallet remove any content, it merely provides Fatwallet with safe-harbor from copyright law by removing the content. The problem here isn't the DMCA, it's copyright law. Actually it's not even copyright law, it's how copyright law is being applied.
It's a well-known fact that IM, even more than computer games, is a notorious productivity killer. So much so that many companies have started to firewall IM clients off and edict company rules forbidding the use of IM at the office.
Yeah, email and web are probably even bigger productivity killers. Hell, they should just forbid internet access.
Please. IM can be very useful. If people aren't going to be productive, they're not going to be productive. Take away everything in the room except their work, and they'll stare at the walls. Taking away IM is stupid.
According to the article: "Microsoft, Lotus, Sun, and Novell seem to have settled on SIP. Intel, H-P, Hitachi, Sony, and more or less the entire open source world is going toward XMPP, sometimes better known as Jabber."
Credit Cards already do forego the additional security for many purchases. I don't need a signature when I buy gas. I don't need a signature when I buy from the grocery store at the self-checkout line. I don't need a signature for the vast majority of online purchases. You're right that this isn't going to do any more than replace the credit card, and I totally agree with you that implanting is ludicrous, but as a replacement for the credit card it does have its advantages, since it doesn't have to be swiped.
Now to be really useful you'd need an active system. Embed a private key, PGP signing hardware, and a battery, and now you've got a system that can be used for fairly high value transactions. I'd still want to keep it on my keychain, though. Though if you embedded it I guess you could get rid of the battery and just have it suck energy right from your body. Heh.
When you purchase with a credit card you provide a username and a password. The user name is the credit card number. The password is your signature.
About 90% of my credit card purchases don't require a signature. Gas stations, grocery stores (at the self-serve checkout line), online purchases. None of these require signatures.
But in any case, you haven't shown how this is any better than biometrics. The only difference is you could potentially replace it. But that seems to me to be more of a detriment than an advantage. Otherwise, why bother embedding the RFID? I guess for some people that's supposed to be convenient. I'd just as well put it on my keychain, though, even if we get to the point where there are no keys.
Why not both, seems to be a better question. If I scan my hand to retrieve my account number, and then use biometrics to verify my identity, theft is virtually impossible.
How is that any more secure than just using biometrics? More efficient, perhaps (it's currently hard to use biometrics for identification when you have a large population of data). But I don't see how it's any more secure. Anyone who can steal your biometric data can just steal your RFID data at the same time.
Security is something you possess and something you know.
Not all security. Sure, the best security is a combination of something you have, something you know, and something you are, but not all applications require all three.
For instance, current vending machine security is solely a matter of something you have - cash.
I think that any biometric or RFID authentication technology should be combined with a PIN.
The best security is a combination of something you have (that's difficult to reproduce, RFIDs don't cut it), something you know, and something you are. But not every application needs to use all three of these things. We already use RFID authentiation for paying tolls using EZ-Pass, and paying for gas using EZ-Pay or whatever the hell it's called. Has anyone ever stolen money using these things? Probably, but the usefulness is so little that it's really not worth the time to reproduce the item and the risk of getting caught. A successful operation and you get some free gas, or free tolls. Working alone you aren't going to gain very much at all, and working as part of a large conspiracy you could come up with a lot more lucrative ways to steal or even earn money.
while biometrics themselves are harder to forge, the tool which reads them may be compromised/replaced/.. so unless there's a lot of authentication, this is very vulnerable to a man in the middle attack/sniffing/..
And that doesn't apply to RFID tags how?
Just read the output of a retina scan and replay it at another machine...
The question is, is it harder to reproduce a fake retina, fake cash, or a fake credit card?
If biometrics really get used everywhere, its security system will eventually get cracked and then you've got a major problem.. cause you can't re-issue new retinas:-)
You're assuming that reading a biometric is as easy as copying a biometric. That's clearly not the case. We use biometrics all the time, after all. That's how we recognize people. Just because I can describe a person in great detail doesn't mean I can make an exact replica of him.
But what if the input gets cracked, you ask? Think about an ATM machine. If I can manage to get past the glass and rewire the retinal scanner then I could probably just break in and get the cash itself.
I noticed that Matrix Revolutions got bad reviews, so I didn't go see it.
Are you sure it didn't have anything to do with the fact that everyone was saying it sucked? I mean, word of mouth is important for those fringe cases. But reviews... I don't trust reviewers. Most of them suck, and those that don't still hold very different opinions than I do a large percentage of the time.
Slashdot Mirror
I read the brief. You are the one who seems to have the trouble reading. Try reading the DMCA. You'll see that it does not require service providers to remove anything. It merely provides them with a safe-harbor if they do remove content and follow certain rules.
The key word there is potential. The DMCA allows people to avoid potential litigation under copyright law. In order to qualify for protection under the DMCA, you have to remove the content. That's not the same as saying the DMCA forces you to remove content. The DMCA does not force the ISP to remove anything. It merely provides the ISP with a defense against copyright infringement if they do remove the content.
Right, and it's a bullshit argument whether it's made by FatWallet's lawyers or made by some bozo on Slashdot, and the courts will recognize it as such. The DMCA does not shift any burdens. It provides ISPs with safe-harbor if they follow certain rules.
The subpoena arugment is a completely different argument, and for the most part I agree with it.
Where it could impact RIAA and the MPAA is that they would actually have to have pending litigation in order to file the subpoenas.
So? They file a John Doe lawsuit in court and then get subpoenas, I don't see the big deal.
RIAA and the MPAA might think twice before going after a file trader if they actually had to have a case prepared or where willing to go to court over twenty music files. That is the implications of this suit.
From what I've read they were only going after people sharing hundreds of music files. And I don't see how filing a John Doe lawsuit is much more of a barrier than getting a subpoena from a judge. For the most severe cases, they're going to be willing to do it anyway. For petty cases, they're not.
Further reading of the brief, and I will save you the quotes, states that it is also a violation of the Federal Rules of Civil Procedure to issue and demand response in a court other than the defendants court. It is article number 55.
Presumably the DMCA would overide such rules, since it was passed later.
In theory, yes. In practice, you could invent a device that ended world hunger and cured cancer in babies, but if it included a CD writer, the RIAA would be able to use the DMCA to stop you making it.
A congresscritter is not going to buy that argument. Since it's ridiculously untrue, I don't buy it either.
Hmm, according to this thread it seems that it's accidental, and you might even get charged for it. In any case, do you need a special phone to use it? I have the serial cable adapter, but it only seems to work at 14.4 when I connect. Is there a different number you need to dial? I use #777, I think.
So experimental drivers should not be included in the linux kernel?
Not in a released version of the kernel. Only in beta versions.
So if someone wants to use an experimental driver, they're stuck with using an entire experimental kernel? That's ridiculous.
As the author, you don't know if it affects the program or not. All you know is whether you believe that it affects the program. That's what beta testing is for.
Unless your code is using random gotos that's just not true. Your experimental functions are not going to be called unless the user requests those experimental features. Otherwise your program is seriously screwed up at the most basic level.
Huh? So you think that a program running at your user level presents no threat?
No, of course a program running at your user level poses a threat. But in order to expose that threat, you'd need to enable the experimental features. If the person exposed to the threat is the same person that enabled the experimental features, then it's an acceptable risk.
You believe that it's okay if it can modify and delete all of the same files that you can?
Of course. rm can modify and delete all the same files you can. You just have to pass it the appropriate parameters. By enabling experimental features you are explicitly acknowledging that you might run into a buffer overflow. In other words, by creating an Elgamel key, you acknowledge that key creation might crash. And by enabling experimental features on a program which uses untrusted input, you are explicitly acknowledging that you might lose all of the files you have access to delete. So when you sign an untrusted file using Elgamel, you acknowledge that you might lose all your files due to a buffer overflow exploit.
OK. Now i think I understand. The signing code for Elgamel broke in GPG 1.0.2. That broke key creation because key signing is part of key creation (by default, or always?) when creating Elgamel sign+encrypt keys.
I'd still say that signing using Elgamel keys is an experimental feature, though. And creation of Elgamel signing keys certainly is (as you said you had to use special flags).
I don't want to find out that the "choice" I made for a key type is something that 0.04% of people chose and that, because of its rarity, it had an undiscovered flaw.
I see. You must have just failed to read the announcement:
I'm ssorry. You enable special hidden options and override warnings, and you've got no one to blame but yourself for making that choice.
Have you ever heard the term "beta"? If a feature is not well-tested, then it should not be in the base code.
So experimental drivers should not be included in the linux kernel?
Most people don't compile their own executables. Period.
And that's a good reason why the standard binaries should include as many features as possible, regardless of whether or not those features are experimental, so long as the inclusion of those features does not affect the program when they are not used.
Something as important as encryption should not be released with "experimental" code in it.
This wasn't so much experimental code as it was an experimental feature. The code worked fine. It was the algorithm itself which was exploited.
What's to say that there could not be a buffer overrun exploit that's a part of some rarely used, minimally tested part of the code?
Unless the binary is set up as setuid or setgid, that's irrelevant. The user running the program using experimental options is taking the risk that there might be such an exploit.
One of the arguments made that will impact RIAA and the MPAA is that the DCMA [sic] shifts the burden of proof of the copyright from the person claiming copyright to the person accused of violation.
Nonsense. The DMCA has nothing to do with burdons of proof. The DMCA gives an ISP safe-harbor from copyright infringement lawsuits if they remove the content. If the ISP refuses to remove the content, the copyright holder can then sue the ISP, and the burdon of proof (preponderance of the evidence in a civil case) is upon the copyright holder. If the ISP does remove the content, then they can't even be sued in the first place.
The implications would be chilling for the RIAA. Why? Because instead of firing off a couple hundred law suits, they would be forced to prove to the ISP that the subject of the supeonia had in fact violated copyrights.
Nope. That's not how it worked before the DMCA, and that's not how it would work if the DMCA was ever found unconstitutional. Instead of a DMCA takedown notice, the RIAA would simply send a cease and desist. If the ISP refused to comply with the cease and desist, they could be sued for willful copyright infringement.
The DMCA takedown notices are actually an improvement over standard copyright law. Unlike a cease and desist, there are mechanisms for counter-notification, there is a requirement that takedown notices be made under penalty of perjury, and there are specific penalties for making false accusations in a takedown notice.
The DMCA is a bad law, but not because of the takedown notices. The bad parts of the law are the circumvention clauses, and the subpoena clauses.
I could garountee you that if you sat me down infront of the senate and asked me to explain to them why the DMCA is bad I could convince them within an hour as could just about any well educated technically inclined individual could.
I highly doubt it. The DMCA is a natural extension of copyright law. If you create a device whose primary purpose is to subvert copyright law, then you're guilty of violating the DMCA. I fail to see how you're going to convince someone who agrees with copyright law that such a law is bad. At least, without misinforming them with what the law actually says. And most senators aren't going to fall for such misinformation.
If Congress legally passes a law that is Constitutional and within the scope of their legal right to legislate, and a judge deny's the application of that law because it "subverts the liberties of the people" you have in effect no government at all.
Impossible. A law which subverts the liberties of the people is not Constitutional.
Yeah, but the announcement says that "According to the keyserver statistics, there are 848 primary ElGamal signing keys which are affected." Which is damn close to 850.
Someone decided to munge Werner's announcement in a poorly implemented attempt at stopping spam. You have to change each "foo at example.com" to "foo@example.com". Then the .sig will verify correctly.
I'm not so sure this was an example of that. This was an experimental setting to begin with, and the fact that it is included in the base GPG code doesn't affect the people using the standard settings. As long as the experimental or rarely used code is kept separate from the rest of the program, the only problem is the extra source code you have to download and the extra binary size (if there's no option to #ifdef those sections out).
Unless of course you choose to use the features which aren't highly tested, of course. Then you're on your own.
So yeah, in many cases, they should just forbid the internet. Most accountants don't need it to do accountancy, for example. Most secretaries don't either.
I think you're the one with the backward logic. The internet is a tool which can be quite useful for both accountants and secretaries. Taking it away will produce less efficient workers, not more.
42) seems like quite a stretch. They seem to be fully admitting that they don't have any standing, and are relying on some kind of injury by proxy. I'd suspect their constitutionality claims will be thrown out for lack of standing.
Moreover, the whole argument seems poorly made. The DMCA does not require that Fatwallet remove any content, it merely provides Fatwallet with safe-harbor from copyright law by removing the content. The problem here isn't the DMCA, it's copyright law. Actually it's not even copyright law, it's how copyright law is being applied.
It's a well-known fact that IM, even more than computer games, is a notorious productivity killer. So much so that many companies have started to firewall IM clients off and edict company rules forbidding the use of IM at the office.
Yeah, email and web are probably even bigger productivity killers. Hell, they should just forbid internet access.
Please. IM can be very useful. If people aren't going to be productive, they're not going to be productive. Take away everything in the room except their work, and they'll stare at the walls. Taking away IM is stupid.
ICQ, YIM, and GG? Maybe that's why you're nont using IM. AIM and MSN Messenger are the only two I can stand.
According to the article: "Microsoft, Lotus, Sun, and Novell seem to have settled on SIP. Intel, H-P, Hitachi, Sony, and more or less the entire open source world is going toward XMPP, sometimes better known as Jabber."
Credit Cards already do forego the additional security for many purchases. I don't need a signature when I buy gas. I don't need a signature when I buy from the grocery store at the self-checkout line. I don't need a signature for the vast majority of online purchases. You're right that this isn't going to do any more than replace the credit card, and I totally agree with you that implanting is ludicrous, but as a replacement for the credit card it does have its advantages, since it doesn't have to be swiped.
Now to be really useful you'd need an active system. Embed a private key, PGP signing hardware, and a battery, and now you've got a system that can be used for fairly high value transactions. I'd still want to keep it on my keychain, though. Though if you embedded it I guess you could get rid of the battery and just have it suck energy right from your body. Heh.
When you purchase with a credit card you provide a username and a password. The user name is the credit card number. The password is your signature.
About 90% of my credit card purchases don't require a signature. Gas stations, grocery stores (at the self-serve checkout line), online purchases. None of these require signatures.
But in any case, you haven't shown how this is any better than biometrics. The only difference is you could potentially replace it. But that seems to me to be more of a detriment than an advantage. Otherwise, why bother embedding the RFID? I guess for some people that's supposed to be convenient. I'd just as well put it on my keychain, though, even if we get to the point where there are no keys.
Why not both, seems to be a better question. If I scan my hand to retrieve my account number, and then use biometrics to verify my identity, theft is virtually impossible.
How is that any more secure than just using biometrics? More efficient, perhaps (it's currently hard to use biometrics for identification when you have a large population of data). But I don't see how it's any more secure. Anyone who can steal your biometric data can just steal your RFID data at the same time.
Security is something you possess and something you know.
Not all security. Sure, the best security is a combination of something you have, something you know, and something you are, but not all applications require all three.
For instance, current vending machine security is solely a matter of something you have - cash.
I think that any biometric or RFID authentication technology should be combined with a PIN.
The best security is a combination of something you have (that's difficult to reproduce, RFIDs don't cut it), something you know, and something you are. But not every application needs to use all three of these things. We already use RFID authentiation for paying tolls using EZ-Pass, and paying for gas using EZ-Pay or whatever the hell it's called. Has anyone ever stolen money using these things? Probably, but the usefulness is so little that it's really not worth the time to reproduce the item and the risk of getting caught. A successful operation and you get some free gas, or free tolls. Working alone you aren't going to gain very much at all, and working as part of a large conspiracy you could come up with a lot more lucrative ways to steal or even earn money.
while biometrics themselves are harder to forge, the tool which reads them may be compromised/replaced/.. so unless there's a lot of authentication, this is very vulnerable to a man in the middle attack/sniffing/..
And that doesn't apply to RFID tags how?
Just read the output of a retina scan and replay it at another machine...
The question is, is it harder to reproduce a fake retina, fake cash, or a fake credit card?
If biometrics really get used everywhere, its security system will eventually get cracked and then you've got a major problem.. cause you can't re-issue new retinas :-)
You're assuming that reading a biometric is as easy as copying a biometric. That's clearly not the case. We use biometrics all the time, after all. That's how we recognize people. Just because I can describe a person in great detail doesn't mean I can make an exact replica of him.
But what if the input gets cracked, you ask? Think about an ATM machine. If I can manage to get past the glass and rewire the retinal scanner then I could probably just break in and get the cash itself.
Wouldn't we have an awful lot of false alarms using that system?
I noticed that Matrix Revolutions got bad reviews, so I didn't go see it.
Are you sure it didn't have anything to do with the fact that everyone was saying it sucked? I mean, word of mouth is important for those fringe cases. But reviews... I don't trust reviewers. Most of them suck, and those that don't still hold very different opinions than I do a large percentage of the time.