Like Comcast they can forge packets on BOTH sides of the router if they were doing it and therefore you'd get RST packets on both sides. Therefore merely comparing the output on both sides is not enough to determine if forging RST packets is occurring.
You need to log, at each end, what each end is both sending and receiving. Then compare the results.
Unless you installed a stateful firewall or a proxy server, there shouldn't be anything in the middle changing the packets. If there is, it's useful to know that.
It's Roland the Plogger again, pushing his ad-laden blog.
The actual research summary is here. The real paper won't be out until July.
This isn't new. JPL has been trying various levels of self-healing for years.
The original article describes a cluster of five machines, set up so that if one fails,
others take over tasks running on the failed machine. That's what the better
server management systems do. I went to a talk last week by Amazon's CTO, and he
described how their platform does that.
The project web site makes things clearer. There are two levels of recovery. The upper level works like cluster fallover. The lower level tries to reconfigure the FPGAs to use different cells in the FPGA to work around faults. That's likely to be a delicate process; you'd need substantial on-chip test resources to reliably do gate-level fault isolation on an FPGA that's been hit hard by a cosmic ray. It's not clear how fine-grained this is; this may be more like having multiple units like GPU shaders replicated in an FPGA, with the ability to turn off the failed ones. Sort of like the way Sony ships PS3 machines with eight Cell processors, at least seven of which work.
The available info isn't enough to tell whether this is a good idea or not. About typical for Roland the Plogger.
This approach to testing is stupid. One correct approach is to record all the packets sent and received at both ends of the connection, then compare them after the session. Any unexpected packets are bogus.
There are some routers that will generate bogus packets through out and out bugs. The Sveasoft Linux software for Linksys routers had that problem a few years back. If you had more than one or two packets queued for the air link, some of the packets would get garbled.
Most users never saw this, because they were connecting to the Internet via a low bandwidth link. In that mode, you can't saturate the air link, and you never build up a transmit queue. We were doing big downloads from a local file server to a local client, with no traffic to the outside world at all. (We were using this for a robot vehicle, with long debug logs and code updates being transferred.) An FTP connection wouldn't work for more than about fifteen seconds. It would stall, retransmitting until the connection timed out. We finally put packet sniffers on the links and found out that TCP packets were being garbled by the "internal firewall", even when it was supposedly turned off. The garble wasn't random; it occurred in a repeatable way that made each TCP retransmit fail.
In 2007, I found a transparency problem with Coyote Point load balancers. This one would mysteriously block connections. If you made an HTTP connection through a Coyote Point load balancer, and sent an HTTP header with a "User-agent" string ending in "m" but not containing another "m", and the HTTP header contained no additional fields, the load balancer would not pass any TCP packets to the systems behind the load balancer. This turned up on a site where I know the people who run the site, and we did packet dumps on both sides of the load balancer to confirm this. Coyote Point parses HTTP headers with regular expressions, and I suspect that, somewhere in the built-in rules, someone wrote "\m" where they meant to write "\n".
In a typical non-response, Coyote Point suggested we upgrade the load balancer. I pointed out that Coyote Point's own site had the same problem.
So a good network transparency test for end users would be a useful tool to have around. The existing tools tend to be part of protocol analyzers, and assume the user knows TCP/IP/Ethernet down to the bit level.
If you add the address to the contact page, SiteTruth should pick it up in 30 days or so.
The whole point of SiteTruth is to associate a business name and address with a web site.
Any site that's even vaguely commercial should have a clearly visible business name and physical address. In some jurisdictions that's required by law. We're trying to make a dent in the "on the Internet, no one knows if you're a dog" problem. Which, after all, was what SSL certificates were originally supposed to be for - validation of the identity of the remote party.
The "commercial/non-commercial" distinction is hard. Yahoo R&D tried training a Bayesian spam filter to make that distinction, but it didn't work out too well and that was only deployed on the R&D site. We initially presume ".com", ".net", and ".biz", plus their country domain counterparts like ".co.uk", to be commercial, while ".org" and ".edu" are presumed noncommercial. An Open Directory listing in a suitable category can override this. Presence of ad links makes a site commercial.
The main use of SiteTruth is not the search engine front end; it's AdRater, which rates Google ads as they go by. SiteTruth is a technology demo, an alpha test, and a means for gathering information about Google advertisers (not users). So we like to get comments from knowledgeable people. More uses of the data are coming.
We're one of the few operations out there seriously trying to do something about all the junk sites on the web.
That site has the address only on the "AUP" page, an unlikely place for a user to look for it. SiteTruth checked the "Contact" page, and didn't find it there. We look at about forty keywords ("contact", "about", "office", "address", "site map", etc.) likely to lead to an address, much as a user would.
The site does have an SSL certificate, but it's from StartCom, a relatively new root certificate authority, and we don't have them listed as a valid root CA. Now that Firefox is accepting them, we should start; we generally use the same root CA set as Firefox, but only update once a year or so. Many browsers won't recognize StartCom certs yet, either.
Buy a real SSL cert, one with "Location" (L field) information and a real business name (not a domain name) in the "Organization" (O field). Avoid those cheap "Instant SSL" "Domain Control Only Validated" certs.
At SiteTruth, we consider the low-end certs worthless. They don't provide any information about who you're dealing with. We encourage other developers of certificate-validation software to take a similar position. You don't want to input a credit card number to a site with a "domain control only validated" certificate. "Domain control only" validated certs are enough for logging into a blog, perhaps, but not more than that.
There's nothing good to program in. This is a serious problem.
We have C. C isn't a bad language, but the "pointer=array" concept, while it provided some performance gains in the PDP-11 days, continues to cause millions of crashes and intrusions every day. The fundamental problem is that you can't even express the size of an array in the language. Given that, the odds of consistently getting subscripts right is low.
This could be fixed, but it will never happen.
There's C++. C++ has lost its way, as I've pointed out before. The C++ committee is off in template la-la land, putting in features that few will use and fewer still will use correctly. (Coming soon: "concepts"). The real problem with C++ is that it's no safer than C, but hides more.
There were once better languages. Delphi is better, but it's Borland. Modula 3 was a good systems programming language, but it died with DEC. Various attempts at improvement, from Ada to Eiffel to Sather, have almost died off. Amazingly, "D", which is Walter Bright's successor to C++, has a measurable market share.
Some progress is being made on numeric issues, like compiling Matlab to efficient code for parallel hardwware. But that doesn't help systems programming much. Hard-compiled Python would have potential, if Guido wasn't against it. (Python has a speed penalty of about 10x to 60x over C/C++. Maybe at some point Google management will decide that a hard-compiled Python system would be cheaper than building additional data centers at former aluminum-smelter sites.)
As for garbage collection, it's a headache. "Finalizer" and "destructor" semantics get weird. (See "Managed C++") Reference counting leads to saner semantics and repeatable timing, but is inefficient unless the compiler knows how to hoist reference count updates out of loops. (Incidentally, about 90% of subscript checks can be hoisted out of loops, and you can almost always hoist them out of inner FOR loops. So subscript checking is almost free if done right.) Note that Perl is reference-counted, and Perl programmers don't spend much attention on memory management. If you have strong and weak pointers, reference counting, and treat cycles as errors, you don't really need garbage collection.
Worst case for the telcos, they have to refund some amount to each customer. Maybe rebate the "CALEA fee" for a year or two, plus pay the EFF's legal bills. It's not going to be a big dollar cost.
No, it's embarrassment to the Bush Administration that the Bush Administration is worried about.
This doesn't look too tough. Take the original image, the one where you're supposed to find the "center of the image", bring it into Photoshop and apply Gaussian blur with about 4 pixels. That gets rid of the noise. Then, as an experiment, try "find edges". This brings out some, but not all, of the edges, finding some that aren't horizontal or vertical. What's needed is an edge finder that recognizes only long vertical and horizontal edges. That will bring out rectangular areas, and a program can then find and report the center of rectangles. It won't be perfect, but it doesn't have to be.
The second stage test consists of a black grid superimposed on a noisy image. First, remove the black grid and interpolate the missing pixels. Then do a Gaussian blur at about 2-3 pixels to get rid of the noise. Now you have a blurry picture. The site probably has only a small library of original pictures, and relies on making them look different by distortion. After you've identified some number of them by hand, duplicates will start to emerge. Use a simple matcher to match pictures against your library of identified pictures, and expect a reasonable success rate.
Most of the necessary code can be obtained from OpenCV.
So this isn't likely to work for a major site worth attacking.
There are real 3-CPU parts. The XBox 360 has one; three PowerPC CPUs share a cache. The chip
layout is four quadrants, three with CPUs and one with the L2 cache.
I'd be more impressed if he was standing next to a 5000 gallon tank of the stuff. On a small scale, if you're not worried about cost, you can make just about any hydrocarbon from any other hydrocarbon. It's hard to measure operating costs until the process is scaled up. So I'm skeptical of the cost claims.
I just came back from the Embedded Systems Conference, where you see systems running on shake tables, or submerged in aquaria. With fish. -18C to 50C is not an industrial temperature range.
Normally, the "commercial range" is 0C to 70C, and "industrial range" is -40C to +85C.
It's all solid state memory, so there's not much of a temperature problem at the low end, as long as the humidity is low enough to avoid condensation or ice. "Thermo-fluid analysis to achieve semi-hermetic construction." - right.
Also, the thing has a MIPS processor, and it's a bit late for that. It's not even AMD product any more; the Alchemy line was sold off to Raza years ago.
It's encouraging to see NASA's PR budget cut. NASA does way too much PR, and too much non-space stuff. All of NASA's non-space research should be moved to the National Science Foundation.
Oh, quit bitching about patents. Most of the people whining about this on Slashdot have never solved a significant tough problem that has stumped others.
There are some real problems with the patent system, but they're not the ones most Slashdot readers think of. There's the interaction of standards and patents, where a narrow patent become valuable because it's the standard, but that's really an antitrust problem. There are problems in the pharmaceutical area, where the industry has convinced Congress to give that industry new, weird kinds of intellectual property, like exclusivity rights in clinical testing results. There's the "business method" area, which needs work. There's the excessive time for examination problem. And there are still overly broad "Claim 1" claims that slip through.
But if it weren't for patents, only big companies would innovate.
I've used Blender extensively. I've even used the Game Kit and extended Blender in Python.
Even after you know it, the UI still sucks. There's not enough feedback, it's too modal, the tools for aligning objects are weak, the keyboard shortcuts manual is over forty pages, and things that aren't implemented just silently don't work. Other than that...
It's not like this is a newly discovered phenomenon. After all, there have been many unmanned moon landings and equipment has operated through the "magnetotail" many times. The USSR landed two lunar rovers, both of which worked for months. Lunokhod 1 was operational for 322 days, and Lunokhod 2 was operational for about four months. This was in the early 1970s.
I go by the Tesla dealership site in Menlo Park regularly, and it's still not open. Not even close. Their blog claims the car "began regular production" on March 17th, but they're not actually delivering cars.
They may still be struggling with the fragile transmission problem and the motor cooling problem.
It's one of those stupid divorce-type business litigations, where someone involved with the project went off to do one of their own. It's a vague trade secret case. But the
"secrets" are available to anyone who buys one and takes it apart. That, incidentally, is normal practice in the auto industry; all the big automakers buy each other's new models and disassemble them.
There's not really much innovation in the Tesla; it's a bunch of laptop batteries, an electric drivetrain, and liquid cooling on the batteries and motor. It's like a Prius with a case mod and a Coolermaster.
The real Lojack system, for cars, predates the Internet and GPS. It's pretty good. About 90% of Lojack-equipped cars are recovered when stolen. When you buy Lojack, an installer comes out and installs a little box somewhere on your car. You don't know where, and they have many alternative locations. It gets power from the car, so it keeps itself charged.
The unit finds an FM broadcast station with the Lojack subcarrier and listens for a message with its serial number. If your car is stolen in an area with Lojack coverage (which includes most major US cities), a police stolen car report is copied to Lojack's computers, which then tell the subcarrier transmitter at the broadcast stations to start broadcasting messages with the unit's serial number. The unit in the car then starts emitting a beacon signal.
Lojack has good integration with big-city police departments. They equip police cars with Lojack receivers at Lojack's expense.
Any Lojack receiver that's emitting turns on indicators in police cars, showing direction and approximate range. When you see a police car with four antennas in a square on the roof, that car has a Lojack receiver.
In Los Angeles, the LAPD's air force, both rotary and fixed-wing, has Lojack receivers. This has resulted in some dramatic stolen car recoveries. Cops like the system, because not only do they get cars back, they often find someone they want driving the stolen car.
But "Lojack for Laptops" doesn't use that system. It just reports IP addresses when the unit connects to the Internet. A company called Absolute Software seems to have just licensed the Lojack name; it's apparently not part of Lojack Corporation at all.
This is a known problem in the intelligence community. Not only are circular references possible, there's the false confirmation problem. This occurs when what appears to be confirming information originates from the same source, but is collected via a different route.
That's not a confirmation and does not increase the reliability of the information; in fact, it may increase the odds that it's disinformation.
Journalists need to watch for this, too. Bloggers should, but that's probably asking too much.
Here's the
actual bill. $60 million per year. 15 cosponsors.
This is another piece of Bush Administration "security theater".
Write to your representatives in Congress and your Senators to get them to put this money into fighting spam and computer crime.
With Comcast's monitoring of user traffic, they could provide reliable stats for their customer base. We ought to get something back from all this Big Brother stuff.
Slashdot Mirror
Like Comcast they can forge packets on BOTH sides of the router if they were doing it and therefore you'd get RST packets on both sides. Therefore merely comparing the output on both sides is not enough to determine if forging RST packets is occurring.
You need to log, at each end, what each end is both sending and receiving. Then compare the results. Unless you installed a stateful firewall or a proxy server, there shouldn't be anything in the middle changing the packets. If there is, it's useful to know that.
If that's what you want, read Karma Girl, by Jennifer Estep. It's superhero chick lit.
It's Roland the Plogger again, pushing his ad-laden blog. The actual research summary is here. The real paper won't be out until July.
This isn't new. JPL has been trying various levels of self-healing for years.
The original article describes a cluster of five machines, set up so that if one fails, others take over tasks running on the failed machine. That's what the better server management systems do. I went to a talk last week by Amazon's CTO, and he described how their platform does that.
The project web site makes things clearer. There are two levels of recovery. The upper level works like cluster fallover. The lower level tries to reconfigure the FPGAs to use different cells in the FPGA to work around faults. That's likely to be a delicate process; you'd need substantial on-chip test resources to reliably do gate-level fault isolation on an FPGA that's been hit hard by a cosmic ray. It's not clear how fine-grained this is; this may be more like having multiple units like GPU shaders replicated in an FPGA, with the ability to turn off the failed ones. Sort of like the way Sony ships PS3 machines with eight Cell processors, at least seven of which work.
The available info isn't enough to tell whether this is a good idea or not. About typical for Roland the Plogger.
This approach to testing is stupid. One correct approach is to record all the packets sent and received at both ends of the connection, then compare them after the session. Any unexpected packets are bogus.
There are some routers that will generate bogus packets through out and out bugs. The Sveasoft Linux software for Linksys routers had that problem a few years back. If you had more than one or two packets queued for the air link, some of the packets would get garbled. Most users never saw this, because they were connecting to the Internet via a low bandwidth link. In that mode, you can't saturate the air link, and you never build up a transmit queue. We were doing big downloads from a local file server to a local client, with no traffic to the outside world at all. (We were using this for a robot vehicle, with long debug logs and code updates being transferred.) An FTP connection wouldn't work for more than about fifteen seconds. It would stall, retransmitting until the connection timed out. We finally put packet sniffers on the links and found out that TCP packets were being garbled by the "internal firewall", even when it was supposedly turned off. The garble wasn't random; it occurred in a repeatable way that made each TCP retransmit fail.
In 2007, I found a transparency problem with Coyote Point load balancers. This one would mysteriously block connections. If you made an HTTP connection through a Coyote Point load balancer, and sent an HTTP header with a "User-agent" string ending in "m" but not containing another "m", and the HTTP header contained no additional fields, the load balancer would not pass any TCP packets to the systems behind the load balancer. This turned up on a site where I know the people who run the site, and we did packet dumps on both sides of the load balancer to confirm this. Coyote Point parses HTTP headers with regular expressions, and I suspect that, somewhere in the built-in rules, someone wrote "\m" where they meant to write "\n". In a typical non-response, Coyote Point suggested we upgrade the load balancer. I pointed out that Coyote Point's own site had the same problem.
So a good network transparency test for end users would be a useful tool to have around. The existing tools tend to be part of protocol analyzers, and assume the user knows TCP/IP/Ethernet down to the bit level.
If you add the address to the contact page, SiteTruth should pick it up in 30 days or so. The whole point of SiteTruth is to associate a business name and address with a web site. Any site that's even vaguely commercial should have a clearly visible business name and physical address. In some jurisdictions that's required by law. We're trying to make a dent in the "on the Internet, no one knows if you're a dog" problem. Which, after all, was what SSL certificates were originally supposed to be for - validation of the identity of the remote party.
The "commercial/non-commercial" distinction is hard. Yahoo R&D tried training a Bayesian spam filter to make that distinction, but it didn't work out too well and that was only deployed on the R&D site. We initially presume ".com", ".net", and ".biz", plus their country domain counterparts like ".co.uk", to be commercial, while ".org" and ".edu" are presumed noncommercial. An Open Directory listing in a suitable category can override this. Presence of ad links makes a site commercial.
The main use of SiteTruth is not the search engine front end; it's AdRater, which rates Google ads as they go by. SiteTruth is a technology demo, an alpha test, and a means for gathering information about Google advertisers (not users). So we like to get comments from knowledgeable people. More uses of the data are coming.
We're one of the few operations out there seriously trying to do something about all the junk sites on the web.
Updated the root CA file on the SiteTruth servers to the Mozilla version of April 7, 2008. SiteTruth will now recognize StartCom-issued certs.
Now we get:
This certificate identifies the domain only, not the actual business.
Domain www.roysdon.net
It's one of those low-rent "domain validated only" certs.
That site has the address only on the "AUP" page, an unlikely place for a user to look for it. SiteTruth checked the "Contact" page, and didn't find it there. We look at about forty keywords ("contact", "about", "office", "address", "site map", etc.) likely to lead to an address, much as a user would.
The site does have an SSL certificate, but it's from StartCom, a relatively new root certificate authority, and we don't have them listed as a valid root CA. Now that Firefox is accepting them, we should start; we generally use the same root CA set as Firefox, but only update once a year or so. Many browsers won't recognize StartCom certs yet, either.
Buy a real SSL cert, one with "Location" (L field) information and a real business name (not a domain name) in the "Organization" (O field). Avoid those cheap "Instant SSL" "Domain Control Only Validated" certs.
At SiteTruth, we consider the low-end certs worthless. They don't provide any information about who you're dealing with. We encourage other developers of certificate-validation software to take a similar position. You don't want to input a credit card number to a site with a "domain control only validated" certificate. "Domain control only" validated certs are enough for logging into a blog, perhaps, but not more than that.
There's nothing good to program in. This is a serious problem.
We have C. C isn't a bad language, but the "pointer=array" concept, while it provided some performance gains in the PDP-11 days, continues to cause millions of crashes and intrusions every day. The fundamental problem is that you can't even express the size of an array in the language. Given that, the odds of consistently getting subscripts right is low. This could be fixed, but it will never happen.
There's C++. C++ has lost its way, as I've pointed out before. The C++ committee is off in template la-la land, putting in features that few will use and fewer still will use correctly. (Coming soon: "concepts"). The real problem with C++ is that it's no safer than C, but hides more.
There were once better languages. Delphi is better, but it's Borland. Modula 3 was a good systems programming language, but it died with DEC. Various attempts at improvement, from Ada to Eiffel to Sather, have almost died off. Amazingly, "D", which is Walter Bright's successor to C++, has a measurable market share.
Some progress is being made on numeric issues, like compiling Matlab to efficient code for parallel hardwware. But that doesn't help systems programming much. Hard-compiled Python would have potential, if Guido wasn't against it. (Python has a speed penalty of about 10x to 60x over C/C++. Maybe at some point Google management will decide that a hard-compiled Python system would be cheaper than building additional data centers at former aluminum-smelter sites.)
As for garbage collection, it's a headache. "Finalizer" and "destructor" semantics get weird. (See "Managed C++") Reference counting leads to saner semantics and repeatable timing, but is inefficient unless the compiler knows how to hoist reference count updates out of loops. (Incidentally, about 90% of subscript checks can be hoisted out of loops, and you can almost always hoist them out of inner FOR loops. So subscript checking is almost free if done right.) Note that Perl is reference-counted, and Perl programmers don't spend much attention on memory management. If you have strong and weak pointers, reference counting, and treat cycles as errors, you don't really need garbage collection.
Worst case for the telcos, they have to refund some amount to each customer. Maybe rebate the "CALEA fee" for a year or two, plus pay the EFF's legal bills. It's not going to be a big dollar cost.
No, it's embarrassment to the Bush Administration that the Bush Administration is worried about.
This doesn't look too tough. Take the original image, the one where you're supposed to find the "center of the image", bring it into Photoshop and apply Gaussian blur with about 4 pixels. That gets rid of the noise. Then, as an experiment, try "find edges". This brings out some, but not all, of the edges, finding some that aren't horizontal or vertical. What's needed is an edge finder that recognizes only long vertical and horizontal edges. That will bring out rectangular areas, and a program can then find and report the center of rectangles. It won't be perfect, but it doesn't have to be.
The second stage test consists of a black grid superimposed on a noisy image. First, remove the black grid and interpolate the missing pixels. Then do a Gaussian blur at about 2-3 pixels to get rid of the noise. Now you have a blurry picture. The site probably has only a small library of original pictures, and relies on making them look different by distortion. After you've identified some number of them by hand, duplicates will start to emerge. Use a simple matcher to match pictures against your library of identified pictures, and expect a reasonable success rate.
Most of the necessary code can be obtained from OpenCV.
So this isn't likely to work for a major site worth attacking.
Is AMD having fab problems?
There are real 3-CPU parts. The XBox 360 has one; three PowerPC CPUs share a cache. The chip layout is four quadrants, three with CPUs and one with the L2 cache.
Microsoft is still promoting PlaysForSure. "Same Compatibility Promise - Different Name".
What part of "false advertising" did you not understand.
Here's the home page of the University of Amherst prof who did this. There's a picture of him holding a test tube of synthetic fuel derived from biomass sugars.
I'd be more impressed if he was standing next to a 5000 gallon tank of the stuff. On a small scale, if you're not worried about cost, you can make just about any hydrocarbon from any other hydrocarbon. It's hard to measure operating costs until the process is scaled up. So I'm skeptical of the cost claims.
I just came back from the Embedded Systems Conference, where you see systems running on shake tables, or submerged in aquaria. With fish. -18C to 50C is not an industrial temperature range. Normally, the "commercial range" is 0C to 70C, and "industrial range" is -40C to +85C. It's all solid state memory, so there's not much of a temperature problem at the low end, as long as the humidity is low enough to avoid condensation or ice. "Thermo-fluid analysis to achieve semi-hermetic construction." - right.
Also, the thing has a MIPS processor, and it's a bit late for that. It's not even AMD product any more; the Alchemy line was sold off to Raza years ago.
It's encouraging to see NASA's PR budget cut. NASA does way too much PR, and too much non-space stuff. All of NASA's non-space research should be moved to the National Science Foundation.
Oh, quit bitching about patents. Most of the people whining about this on Slashdot have never solved a significant tough problem that has stumped others.
There are some real problems with the patent system, but they're not the ones most Slashdot readers think of. There's the interaction of standards and patents, where a narrow patent become valuable because it's the standard, but that's really an antitrust problem. There are problems in the pharmaceutical area, where the industry has convinced Congress to give that industry new, weird kinds of intellectual property, like exclusivity rights in clinical testing results. There's the "business method" area, which needs work. There's the excessive time for examination problem. And there are still overly broad "Claim 1" claims that slip through.
But if it weren't for patents, only big companies would innovate.
I've used Blender extensively. I've even used the Game Kit and extended Blender in Python.
Even after you know it, the UI still sucks. There's not enough feedback, it's too modal, the tools for aligning objects are weak, the keyboard shortcuts manual is over forty pages, and things that aren't implemented just silently don't work. Other than that...
It's Roland the Plogger, wrong as usual.
It's not like this is a newly discovered phenomenon. After all, there have been many unmanned moon landings and equipment has operated through the "magnetotail" many times. The USSR landed two lunar rovers, both of which worked for months. Lunokhod 1 was operational for 322 days, and Lunokhod 2 was operational for about four months. This was in the early 1970s.
I go by the Tesla dealership site in Menlo Park regularly, and it's still not open. Not even close. Their blog claims the car "began regular production" on March 17th, but they're not actually delivering cars.
They may still be struggling with the fragile transmission problem and the motor cooling problem.
It's one of those stupid divorce-type business litigations, where someone involved with the project went off to do one of their own. It's a vague trade secret case. But the "secrets" are available to anyone who buys one and takes it apart. That, incidentally, is normal practice in the auto industry; all the big automakers buy each other's new models and disassemble them.
There's not really much innovation in the Tesla; it's a bunch of laptop batteries, an electric drivetrain, and liquid cooling on the batteries and motor. It's like a Prius with a case mod and a Coolermaster.
The real Lojack system, for cars, predates the Internet and GPS. It's pretty good. About 90% of Lojack-equipped cars are recovered when stolen. When you buy Lojack, an installer comes out and installs a little box somewhere on your car. You don't know where, and they have many alternative locations. It gets power from the car, so it keeps itself charged.
The unit finds an FM broadcast station with the Lojack subcarrier and listens for a message with its serial number. If your car is stolen in an area with Lojack coverage (which includes most major US cities), a police stolen car report is copied to Lojack's computers, which then tell the subcarrier transmitter at the broadcast stations to start broadcasting messages with the unit's serial number. The unit in the car then starts emitting a beacon signal.
Lojack has good integration with big-city police departments. They equip police cars with Lojack receivers at Lojack's expense. Any Lojack receiver that's emitting turns on indicators in police cars, showing direction and approximate range. When you see a police car with four antennas in a square on the roof, that car has a Lojack receiver.
In Los Angeles, the LAPD's air force, both rotary and fixed-wing, has Lojack receivers. This has resulted in some dramatic stolen car recoveries. Cops like the system, because not only do they get cars back, they often find someone they want driving the stolen car.
But "Lojack for Laptops" doesn't use that system. It just reports IP addresses when the unit connects to the Internet. A company called Absolute Software seems to have just licensed the Lojack name; it's apparently not part of Lojack Corporation at all.
This is a known problem in the intelligence community. Not only are circular references possible, there's the false confirmation problem. This occurs when what appears to be confirming information originates from the same source, but is collected via a different route. That's not a confirmation and does not increase the reliability of the information; in fact, it may increase the odds that it's disinformation.
Journalists need to watch for this, too. Bloggers should, but that's probably asking too much.
Here's the actual bill. $60 million per year. 15 cosponsors.
This is another piece of Bush Administration "security theater". Write to your representatives in Congress and your Senators to get them to put this money into fighting spam and computer crime.
With Comcast's monitoring of user traffic, they could provide reliable stats for their customer base. We ought to get something back from all this Big Brother stuff.