Well, to be fair, this is about core logic chipsets (nForce). They aren't exactly core to NVIDIA's business
Based on their 2007 financial statements, core logic (what they call MCP) accounted for $660M of revenue, compared to $1990M for GPUs. I'd hardly call a clear quarter of their business "not exactly core".
However, assuming that the system looks for the plate in a specific location on a car, you could always take it off and put it in your back window or something to throw it off...
Having written ANPR software myself (automatic entry to secure parking areas) I can tell you that this is not how they find the plate. They scan the entire frame for areas of the approximate correct size that contain lines that mathematically resemble text, and run those areas through an OCR system. This generates false positives that are then weeded out by comparison with a database (in the case I was developing for) or human operator (in this case).
Moving your plates will not work. Direction sensitive filters will not work, because the camera is probably mounted so as to get a fairly low-angled view in order to reduce distortion of the text on the plate. One trick that has been known to work is an LCD film that obscures sections of the plate, varying which section is obscured at high frequency. This is not detectable by eye or regular photograph, but to a CCD it produces an incomplete image of the plate that cannot be automatically processed.
What if the government spent billions hiring enough police that they could call the insurance companies manually for each car that drove past? Would that be suitable?
Why would anyone think that would work, even if the scale was feasible? Why do you expect insurance companies to be in a position to definitively state whether or not a car is insured without knowing the identity of the driver?
Fine with me, since I keep insurance and don't want uninsured drivers (who cannot compensate me for any damage they do) on the roads.
I'm not sure how insurance works in the US, but here in the UK we've had systems like this for several years now. And I can tell you it's a total pain in the ass. There's supposedly a complete database which states whether any particular car has insurance or not. This is bullshit. The problem is this: insurance attaches to the driver, not the vehicle. I, for instance, have insurance to drive "any vehicle with the owner's permission". I have confirmed with my insurance company that this does not require the owner to have their own insurance on the vehicle. Yet, I am routinely stopped by the police for driving without insurance when I do this.
Now, Cryptome has posted that the Hushmail encryption program is no longer the same program for which Hushmail releases their source. Is Hushmail even safe to use anymore?
I think the submitter answered his own question.
Except the submitter just revealed that they didn't understand what was going on. The original author of TFA only did a hashcode comparison between the compiled sources and the copy served up by hushmail. They didn't bother reading the instructions for verification which state that you need to run the compiled code through a particular configuration of compiled code compressor.
Hushmail was never safe, not from a cryptographic perspective. Hushmail kept a copy of your private key, AND the passphrase for that key would be sent to their servers.
Hushmail is available in two versions. In one of them, the passphrase is sent to their servers. In the other one it isn't. The article is talking about the latter version (implemented via java applet) not the former (implemented via javascript).
Hushmail only stores your private key in encrypted form, encrypted with your passphrase. It gets decrypted only on your machine, by the Java applet.
1. Note that hushmail now has a "no-java" option. Don't use it. It sends your passphrase to them so they can do server-side decryption.
2. The article doesn't seem to be misleading in the slightest. All it does is attempt to call into question whether or not the applet hushmail serve up is the same one they've provided source code for, but instead just shows up the ignorance of its author.
The other problem is that it's not GPG. Honestly, there is no way I'd trust any other file crypto software today. Why should I? GPG is there and works and people use it.
There are a lot of reasons to use hushmail over GPG. They may not apply to you. If they don't, then go ahead and use GPG. The reasons I use hushmail is that I need to access my email from sites where I don't have permission to install software. Since GPG is therefore impossible for me to use, I use hushmail as a next-best option.
Crypto is almost unbelievably hard to get right, and the odds of more than a tiny handful of programs pulling it off is slim
Bullshit. The requirements of a good cryptography implementation are well known and can be implemented as well as they are in GPG by anybody with a reasonable understanding of the processes involved. Sure, there are pitfalls waiting for the unwary, but they're all well documented if you know where to look.
As for Hushmail - its secure if you trust them to use suitable encryption algorithm,
Their encryption algorithm is available for public inspection as part of the source code of their applet. You can decompile their applet using any of several commonly available java decompilers to check it corresponds to the source code they publish, if you wish.
key material, psuedo random number generator,
Similarly, you can see the source code of their key generator and PRNG which use mouse motion as a source of random data.
secure processes (not the program kind, the how to do the job kind), secure network, no shady or otherwise agreements with third parties (inc. governments) to provide decrypted data
Because of how their software works, none of this seems particularly relevant. They don't have enough information to provide decrypted data (as long as you don't use their javascript-based service).
not to store your orginal plain-text mail for any longer than the time it takes to encrypt it,
The encryption occurs on your machine. There's no storage of plaintext other than in your browser's memory.
securely erase the plain-text version etc etc etc.
This is the only place the security of hushmail actually falls down. Because it runs using java in a web browser, there is no way to securely lock the plaintext in RAM, so you would need to securely wipe your swap area after using it if you wanted to be sure no trace of plaintext remained. As the entire point of hushmail is that you can use it on just about any random PC you encounter without needing admin priveleges, there's no possible solution to this problem.
Probably enough holes to drive a bus through...
Only if its a particularly small bus, with a particularly skilled and somewhat lucky driver.
At this point, it would be nice for some organisation to just start signing PGP keys when you fax them a driving license or something, the equivalent to a CA but for PGP keys which traditionally needed huge effort to figure-out if the key matches the person.
Anytime your private encryption key is "over there" you are at risk. If your private key is stored on *their* servers in such a manner that *they* can get to it, your privacy is at risk.
The originally-advertised benefit of hushmail over other web-based services was that your private key is not stored on their servers in such a manner that they can get to it. It was stored AES256 encrypted on their servers, sent encrypted to a java applet running on your machine and decrypted via passphrase locally.
The problems came when they introduced a javascript based version of the service that uploaded the passphrase. Using this was optional, but a lot of people did it because (a) it's more convenient and (b) hushmail rather stupidly made it the default.
IIRC, Hushmail started passing out 'bad' java applets so that they could grab encryption keys.
No, this is not what they did. If they had changed their applet in order to achieve this, myself and lots of other regular hushmail users would have noticed when we were prompted to approve a new version to execute in our browsers.
What they did do was introduce a javascript-only version which sends the keys to their servers, and make it an insecure-by-default choice. Anyone not paying attention could have easily uploaded their keys.
So if intel's atom (haven't been following it) uses an in-order core and hyperthreading that just don't make much sense
I think single issue is an even more relevant problem. I can see how HT could help with an in-order dispatch dual issue core (the primary thread could execute the next two instructions if they were completely independent while the secondary thread could execute an instruction whenever the next two instructions in the primary thread weren't independent), but in terms of single issue... dunno.
I remember there was a processor in the early 80s (I can't remember whether it was a Cray or CDC processor, but it was one of those) that had two threads and dispatched instructions alternating between the threads so that it could have a deeper pipeline without waiting for dependencies. Perhaps that's what's going on?
Try opening a fast food restaurant called "McRonalds" and selling "Big Mick" burgers and see how well your argument holds up in court.
I didn't mean to say that this was legal behaviour. I was attempting to respond to the notion that a trademark deserves to be longer-lived because it is for consumer protection. I don't see how protection of similar but hard-to-confuse words protects consumers.
Trademarks do not expire, nor is there a strong argument that they should, other than after a company stops selling the product.
The test in trademark law is "likelihood of confusion." Which is to say, if you went up to a man in the street, and said, "We have a game where you spell words using tiles on a crossword like board, and get points for the letters, and it's called Scrabulous" is there a reasonable chance a person might confuse that with Scrabble, the trademarked Hasbro game?
First off, the claim in question isn't only for trademark infringement. Hasbro are claiming copyright infringement and "unfair competition". Hasbro also seem to believe that the design of the board and the layout of the tiles used in the game are trademarks.
Secondly, I doubt many people at all would be confused. "Scrabulous" and "Scrabble" are clearly distinct but related words. My suspicion is that almost anyone you asked that question to would (a) assume the game is similar to Scrabble but (b) be aware that it isn't an official version of Scrabble.
they aren't suing someone on the grounds that they are making a word game but because they are trying (at least in Hasbros opinion) to associate with their trademark - which has to be defended or can be lost
Quoting from the complaint:
"44. Defendants have infringed Hasbro's copyrights in the SCRABBLE(R) crossword game and The Official SCRABBLE(R) Players Dictionary by copying and publicly displaying and/or preparing or authorizing the preparation of a derivative work of copyrightable matter in Hasbro's SCRABBLE(R) crossword game and The Official SCRABBLE(R) Players Dictionary, without Hasbro's consent or authorization. [...] 48. [...] defendants have infringed Hasbro's trademarks in the SCRABBLE(R) crossword game..."
The suit is primarily for copyright infringement. The trademark complaint is there (and, BTW, doesn't only refer to the name "Scrabble", but it is claimed that the layout of the board and the design of the tiles are also trademarks), but the copyright claim is what the writers of the suit have put most emphasis on.
The claim is also for unfair competition.
It's also worth noting the claim was filed in a New York state court against individuals who are not residents of NY, or even of the US.
Scrabulous used the Scabble game board (and that was a big part of why it was successful with existing Scrabble players), so they're probably doomed - it's a genuine old-school copyright violation, no DMCA required.
Except that Scrabble was first published in 1938, which I believe means it is now out of copyright in the US...?
Is obviously to do a study on software no-one's EVER heard of.
To be fair to the report's authors, if you're a Java web app developer (which is their target audience, as they're trying to sell a Java web app security analyzer) you probably recognize most of these projects. Derby was the only one I didn't know.
. Is the study claiming that the middleware is faulty? Or that the apps other people write on top of that middleware has issues? If it's the apps, then the middleware is likely blameless. Even if it is the middleware, why isn't the app filtering out erronious inputs? And why is the middleware being run in a container with excessive permissions?
They appear to be claiming the middleware is faulty. Note that the authors of the report sell a Java-based static analysis tool for detecting the kinds of security fault they're reporting. What proportion of the flaws it has located are actually flaws is kind-of an interesting question. If it's analysing middleware, it probably depends heavily on how the middleware is used, and chances are some of these supposed flaws are pretty unlikely to be encountered in real production code.
Here's an example I can imagine:
When an exception occurs in a servlet and it's configured to do so, Tomcat dumps the stack trace to the output web page. Now, it's plausible that the stack trace isn't quoted during output; there would not normally be any need to do so. Now imagine I create a servlet that produces and executes bytecode containing a method with a name specified by a user. Because it isn't going through a compiler, I suspect you may be able to get away with calling that method '<script>alert("hello")</script>'. This might create an XSS vulnerability, which would (at least from a static analysis tool's perspective) be in the application server's code.
I imagine this is the kind of tortured thinking that's necessary to see many of these as faults in the middleware.
Not paying much attention to the Web Services arena, are these some of the most popular Java projects?
Yes. Judging by the recruitment adverts I see, Tomcat+Hibernate+Struts is probably the most common combination of server & frameworks for new Java-based web projects right now. The others are pretty close, though. I'm surprised they missed out Spring, but that's a more generic and not web-biased framework. Also, it's probably not particularly susceptible to static analysis, as it does most of its work via runtime code generation, I believe.
Fortify identified a total of 22,826 cross-site scripting and 15,612 SQL injection issues associated with multiple versions of the 11 open source software packages examined.
The projects in question: Tomcat, Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts.
For those who don't play in Java often:
Derby is an embedded database. Tomcat, Geronimo, JBoss, Resin and JOnAS are Java (EE) app servers. Hipergate and OpenCMS are (you guessed it) content management systems. Hibernate is a persistent framework. Struts is a web framework.
So of any of these, it seems that the only projects that would be open to XSS or SQL injection would be the CMS products. Unless they're referring to the web administration for the app servers?
The only way to have SQL injection attacks in javaland is if you're not using prepared statements or if your database driver isn't preparing/escaping properly.
So they're saying two CMS projects have tens of thousands of XSS and SQL injection vulnerabilities?
You're just on the edge, I suspect, of the reason they didn't get good responses from the maintainers of the code for the "vulnerabilities" they reported. That's because, in most cases, they probably weren't vulnerabilities. The authors of the report are the producers of a static analysis tool that -- you guessed it -- detects potential XSS and SQL injection vulnerabilities. Of course, it (like all such tools) has a very high false positive rate. In the case of code that automatically generates SQL code algorithmically (not using hard-coded prepared statements, for example) like Hibernate, or generates HTML code algorithmically (like, say, pretty much any JSP implementation or templating language), the number of false positives is going to be huge.
Any bets they didn't bother stripping out those false positives before reporting the "vulnerabilities"?
I had to buy (with my own money) Resharper just so I could read and follow the code.
I'm sorry... you work for a company so stingy that it won't buy a $350 piece of software that _saves it employees time_. I don't know about you, but I estimate working with resharper (particularly its error-fixing capability) saves me about half an hour of work per day. At that rate, it pays for itself in weeks...
All of my equipment has only become more reliable with each generation. (With the exception of my TI 99-4a. No moving parts, would probably survive an EMP.)
Strange. I've been through two of them. In both, the video modulator / power supply unit failed. Could be environmental conditions, or a difference between the PAL and NTSC models (I assume you're in an NTSC area?)
Slashdot Mirror
Well, to be fair, this is about core logic chipsets (nForce). They aren't exactly core to NVIDIA's business
Based on their 2007 financial statements, core logic (what they call MCP) accounted for $660M of revenue, compared to $1990M for GPUs. I'd hardly call a clear quarter of their business "not exactly core".
However, assuming that the system looks for the plate in a specific location on a car, you could always take it off and put it in your back window or something to throw it off...
Having written ANPR software myself (automatic entry to secure parking areas) I can tell you that this is not how they find the plate. They scan the entire frame for areas of the approximate correct size that contain lines that mathematically resemble text, and run those areas through an OCR system. This generates false positives that are then weeded out by comparison with a database (in the case I was developing for) or human operator (in this case).
Moving your plates will not work. Direction sensitive filters will not work, because the camera is probably mounted so as to get a fairly low-angled view in order to reduce distortion of the text on the plate. One trick that has been known to work is an LCD film that obscures sections of the plate, varying which section is obscured at high frequency. This is not detectable by eye or regular photograph, but to a CCD it produces an incomplete image of the plate that cannot be automatically processed.
What if the government spent billions hiring enough police that they could call the insurance companies manually for each car that drove past? Would that be suitable?
Why would anyone think that would work, even if the scale was feasible? Why do you expect insurance companies to be in a position to definitively state whether or not a car is insured without knowing the identity of the driver?
The system has a basic flaw. It cannot work.
Fine with me, since I keep insurance and don't want uninsured drivers (who cannot compensate me for any damage they do) on the roads.
I'm not sure how insurance works in the US, but here in the UK we've had systems like this for several years now. And I can tell you it's a total pain in the ass. There's supposedly a complete database which states whether any particular car has insurance or not. This is bullshit. The problem is this: insurance attaches to the driver, not the vehicle. I, for instance, have insurance to drive "any vehicle with the owner's permission". I have confirmed with my insurance company that this does not require the owner to have their own insurance on the vehicle. Yet, I am routinely stopped by the police for driving without insurance when I do this.
Except the submitter just revealed that they didn't understand what was going on. The original author of TFA only did a hashcode comparison between the compiled sources and the copy served up by hushmail. They didn't bother reading the instructions for verification which state that you need to run the compiled code through a particular configuration of compiled code compressor.
Hushmail was never safe, not from a cryptographic perspective. Hushmail kept a copy of your private key, AND the passphrase for that key would be sent to their servers.
Hushmail is available in two versions. In one of them, the passphrase is sent to their servers. In the other one it isn't. The article is talking about the latter version (implemented via java applet) not the former (implemented via javascript).
1. Note that hushmail now has a "no-java" option. Don't use it. It sends your passphrase to them so they can do server-side decryption.
2. The article doesn't seem to be misleading in the slightest. All it does is attempt to call into question whether or not the applet hushmail serve up is the same one they've provided source code for, but instead just shows up the ignorance of its author.
Nothing to see here. Move along.
The other problem is that it's not GPG. Honestly, there is no way I'd trust any other file crypto software today. Why should I? GPG is there and works and people use it.
There are a lot of reasons to use hushmail over GPG. They may not apply to you. If they don't, then go ahead and use GPG. The reasons I use hushmail is that I need to access my email from sites where I don't have permission to install software. Since GPG is therefore impossible for me to use, I use hushmail as a next-best option.
Crypto is almost unbelievably hard to get right, and the odds of more than a tiny handful of programs pulling it off is slim
Bullshit. The requirements of a good cryptography implementation are well known and can be implemented as well as they are in GPG by anybody with a reasonable understanding of the processes involved. Sure, there are pitfalls waiting for the unwary, but they're all well documented if you know where to look.
Their encryption algorithm is available for public inspection as part of the source code of their applet. You can decompile their applet using any of several commonly available java decompilers to check it corresponds to the source code they publish, if you wish.
Similarly, you can see the source code of their key generator and PRNG which use mouse motion as a source of random data.
Because of how their software works, none of this seems particularly relevant. They don't have enough information to provide decrypted data (as long as you don't use their javascript-based service).
The encryption occurs on your machine. There's no storage of plaintext other than in your browser's memory.
This is the only place the security of hushmail actually falls down. Because it runs using java in a web browser, there is no way to securely lock the plaintext in RAM, so you would need to securely wipe your swap area after using it if you wanted to be sure no trace of plaintext remained. As the entire point of hushmail is that you can use it on just about any random PC you encounter without needing admin priveleges, there's no possible solution to this problem.
Only if its a particularly small bus, with a particularly skilled and somewhat lucky driver.
See, e.g., http://www.verisign.com/authentication/individual-authentication/digital-id/index.html or look for similar services from a CA you trust.
Anytime your private encryption key is "over there" you are at risk. If your private key is stored on *their* servers in such a manner that *they* can get to it, your privacy is at risk.
The originally-advertised benefit of hushmail over other web-based services was that your private key is not stored on their servers in such a manner that they can get to it. It was stored AES256 encrypted on their servers, sent encrypted to a java applet running on your machine and decrypted via passphrase locally.
The problems came when they introduced a javascript based version of the service that uploaded the passphrase. Using this was optional, but a lot of people did it because (a) it's more convenient and (b) hushmail rather stupidly made it the default.
No, this is not what they did. If they had changed their applet in order to achieve this, myself and lots of other regular hushmail users would have noticed when we were prompted to approve a new version to execute in our browsers.
What they did do was introduce a javascript-only version which sends the keys to their servers, and make it an insecure-by-default choice. Anyone not paying attention could have easily uploaded their keys.
So if intel's atom (haven't been following it) uses an in-order core and hyperthreading that just don't make much sense
I think single issue is an even more relevant problem. I can see how HT could help with an in-order dispatch dual issue core (the primary thread could execute the next two instructions if they were completely independent while the secondary thread could execute an instruction whenever the next two instructions in the primary thread weren't independent), but in terms of single issue... dunno.
I remember there was a processor in the early 80s (I can't remember whether it was a Cray or CDC processor, but it was one of those) that had two threads and dispatched instructions alternating between the threads so that it could have a deeper pipeline without waiting for dependencies. Perhaps that's what's going on?
Try opening a fast food restaurant called "McRonalds" and selling "Big Mick" burgers and see how well your argument holds up in court.
I didn't mean to say that this was legal behaviour. I was attempting to respond to the notion that a trademark deserves to be longer-lived because it is for consumer protection. I don't see how protection of similar but hard-to-confuse words protects consumers.
The only thing they copied was the rules. How are the rules protected? Copyright?
To be fair, at least according to Hasbro's complaint, they also copied the official dictionary.
Trademarks do not expire, nor is there a strong argument that they should, other than after a company stops selling the product.
The test in trademark law is "likelihood of confusion." Which is to say, if you went up to a man in the street, and said, "We have a game where you spell words using tiles on a crossword like board, and get points for the letters, and it's called Scrabulous" is there a reasonable chance a person might confuse that with Scrabble, the trademarked Hasbro game?
First off, the claim in question isn't only for trademark infringement. Hasbro are claiming copyright infringement and "unfair competition". Hasbro also seem to believe that the design of the board and the layout of the tiles used in the game are trademarks.
Secondly, I doubt many people at all would be confused. "Scrabulous" and "Scrabble" are clearly distinct but related words. My suspicion is that almost anyone you asked that question to would (a) assume the game is similar to Scrabble but (b) be aware that it isn't an official version of Scrabble.
they aren't suing someone on the grounds that they are making a word game but because they are trying (at least in Hasbros opinion) to associate with their trademark - which has to be defended or can be lost
Quoting from the complaint:
"44. Defendants have infringed Hasbro's copyrights in the SCRABBLE(R) crossword game and The Official SCRABBLE(R) Players Dictionary by copying and publicly displaying and/or preparing or authorizing the preparation of a derivative work of copyrightable matter in Hasbro's SCRABBLE(R) crossword game and The Official SCRABBLE(R) Players Dictionary, without Hasbro's consent or authorization.
[...]
48. [...] defendants have infringed Hasbro's trademarks in the SCRABBLE(R) crossword game..."
The suit is primarily for copyright infringement. The trademark complaint is there (and, BTW, doesn't only refer to the name "Scrabble", but it is claimed that the layout of the board and the design of the tiles are also trademarks), but the copyright claim is what the writers of the suit have put most emphasis on.
The claim is also for unfair competition.
It's also worth noting the claim was filed in a New York state court against individuals who are not residents of NY, or even of the US.
Except that Scrabble was first published in 1938, which I believe means it is now out of copyright in the US...?
No, sorry, I'm wrong. 1933 is the cut-off date, not 1938. Ignore me.
Scrabulous used the Scabble game board (and that was a big part of why it was successful with existing Scrabble players), so they're probably doomed - it's a genuine old-school copyright violation, no DMCA required.
Except that Scrabble was first published in 1938, which I believe means it is now out of copyright in the US...?
Is obviously to do a study on software no-one's EVER heard of.
To be fair to the report's authors, if you're a Java web app developer (which is their target audience, as they're trying to sell a Java web app security analyzer) you probably recognize most of these projects. Derby was the only one I didn't know.
. Is the study claiming that the middleware is faulty? Or that the apps other people write on top of that middleware has issues? If it's the apps, then the middleware is likely blameless. Even if it is the middleware, why isn't the app filtering out erronious inputs? And why is the middleware being run in a container with excessive permissions?
They appear to be claiming the middleware is faulty. Note that the authors of the report sell a Java-based static analysis tool for detecting the kinds of security fault they're reporting. What proportion of the flaws it has located are actually flaws is kind-of an interesting question. If it's analysing middleware, it probably depends heavily on how the middleware is used, and chances are some of these supposed flaws are pretty unlikely to be encountered in real production code.
Here's an example I can imagine:
When an exception occurs in a servlet and it's configured to do so, Tomcat dumps the stack trace to the output web page. Now, it's plausible that the stack trace isn't quoted during output; there would not normally be any need to do so. Now imagine I create a servlet that produces and executes bytecode containing a method with a name specified by a user. Because it isn't going through a compiler, I suspect you may be able to get away with calling that method '<script>alert("hello")</script>'. This might create an XSS vulnerability, which would (at least from a static analysis tool's perspective) be in the application server's code.
I imagine this is the kind of tortured thinking that's necessary to see many of these as faults in the middleware.
Not paying much attention to the Web Services arena, are these some of the most popular Java projects?
Yes. Judging by the recruitment adverts I see, Tomcat+Hibernate+Struts is probably the most common combination of server & frameworks for new Java-based web projects right now. The others are pretty close, though. I'm surprised they missed out Spring, but that's a more generic and not web-biased framework. Also, it's probably not particularly susceptible to static analysis, as it does most of its work via runtime code generation, I believe.
You're just on the edge, I suspect, of the reason they didn't get good responses from the maintainers of the code for the "vulnerabilities" they reported. That's because, in most cases, they probably weren't vulnerabilities. The authors of the report are the producers of a static analysis tool that -- you guessed it -- detects potential XSS and SQL injection vulnerabilities. Of course, it (like all such tools) has a very high false positive rate.
In the case of code that automatically generates SQL code algorithmically (not using hard-coded prepared statements, for example) like Hibernate, or generates HTML code algorithmically (like, say, pretty much any JSP implementation or templating language), the number of false positives is going to be huge.
Any bets they didn't bother stripping out those false positives before reporting the "vulnerabilities"?
I had to buy (with my own money) Resharper just so I could read and follow the code.
I'm sorry... you work for a company so stingy that it won't buy a $350 piece of software that _saves it employees time_. I don't know about you, but I estimate working with resharper (particularly its error-fixing capability) saves me about half an hour of work per day. At that rate, it pays for itself in weeks...
All of my equipment has only become more reliable with each generation. (With the exception of my TI 99-4a. No moving parts, would probably survive an EMP.)
Strange. I've been through two of them. In both, the video modulator / power supply unit failed. Could be environmental conditions, or a difference between the PAL and NTSC models (I assume you're in an NTSC area?)