I also suspect they've managed to botch the technical aspect of it as well.
Presumably the plan was to put their caching name servers in front of the real no-ip servers, and gather the mappings for the malware suspect sites and then blackhole them after getting what they want. The problem was that Microsoft's side appears to have melted down, thus taking everything down. They won't be getting logs, behavior analysis or anything, because its all a pile of wreckage in a crater. Meanwhile, all the "bad guys(TM)" have now had hours head start to delete their C&C node registrations while microsoft's servers are down. And now they've ticked off the no-ip folks, so I wouldn't expect them to be in a cooperative mood to try and help.
Bone headed all round. There's no other way to put it.
A quick skim of the motion for the court order gave me the "boilerplate" and "cut & paste" feeling. There is a lot of sloppy line blurring between actions and complaints directed at the Malware authors and the no-ip folks. Sometimes they refer to the "Malware Defendants" and other times the generic "Defendants" when they meant the former. Really sloppy legal work.
There are some real gems in there:
From section 7: "There is good cause to believe that immediate and irreparable damage to this Court’s ability to grant effective final relief will result from the sale, transfer, or other disposition or concealment by Defendants of the Internet domains at issue" Say what? How is that related anything? Its not like the TRO will actually prevent people from being able to hit 'delete' via the control panel. Given that everything's busted by their own doing, the bad guys got a huge head start.
From section 8: "... and the interest of justice require that this Order be Granted without prior notice to Defendants..." Wow...
It seems to me that regardless of what good intentions that Microsoft may have had, they've really fouled up the execution. They'll be remembered more for taking out millions of legitimate users than the malware they *might* be able to take down.
The TSA does a whole lot of pre-flight data mining on passenger lists. I recall some discussion a while back about how they included included things like the credit card numbers, billing addresses etc in the mix.
Paying with Bitcoin has the same problem as paying with straight-up cash - it sets of all sorts of red flags because there's no real way to see if you're "connected" to other "interesting" people or not. No data = guilty until proven innocent etc.
When you're on the clock for getting to your departing flight, you really don't want to be on the wrong side of the extra special friendly pat-downs reserved for special troublemakers.
People like Expedia won't be wanting to mess with this can of worms for now, so they'll keep their bitcoin experiments a nice safe distance from the US Federal Government universe.
Most likely, they screwed up and lost their private keys. ie: Plain old incompetence.
The code that was leaked to pastebin made it look like they were storing these in something like instances on Amazon EC2. If it turned out they were storing it on ephemeral storage rather than EBS, I don't know if I'd laugh or cry. But it would be an explanation if it were true. Again tough, that would come back to incompetence.
No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion...how hackable is it; Xcode(SDK) will only work on Mac OS X.
GPL didn't stop Xcode existing when it operated around gcc. Xcode will always be an OS X thing, it has nothing to do with the back end compiler license.
Yes, they get a lot of mileage out of tightly coupling Xcode with llvm - eg: they don't have to write the same level of context sensitive language support for editing when you can do constant incremental compiling and inspect the state of the compiler's trees.
BTW; Apple use LLVM for far more than just Xcode. They used it in the display subsystem to run-time optimize code to the actual machine's display configuration.
Being GPLv3 is a bonus for Apple, but it's about more than that. Competition is a good thing.
Well.. GPLv3 specifically. FreeBSD is stuck on GCC-4.2, the last GPLv2 gcc compiler. It's getting quite dated now. It's a switch from gcc-4.2.2+ hacks/patches to clang instead of a GPLv3'd gcc-4.6 or later.
"Stuck"? FreeBSD gets a foot in the door of companies where GPL (and GPLv3 in particular) is something they'd prefer not to deal with. Being able to use a modern GPL-free OS as a foundation of a product is a convenient option to have. And being GPLv3-free can be even more compelling.
Yes. The article is vague, and the title on/. is worse - implies the source repository. It seems people have been easily mislead as a result. Always read the actual article, not a 2nd or 3rd hand summary.
From there:
"The code modifications did not made it into our source control, just the final package. We are currently investigating older packages to see if they were also compromised. "
As has been stated 10 million times above, they're not reading/etc/passwd. They're calling the C/Posix API function getpwuid(). Why? Because it is the safest way to find the user's home directory - in order to locate a firefox profile. They probably check $HOME as well.
Why check the firefox profile? Because they can look at your proxy settings, to see if it needs to use a socks4 or socks5 proxy at all.
This is all part of their "just works" auto-configuration. It is far from the end of the world.
Which is a more reasonable explanation? 1) Skype is data mining stuff to create a giant database of user names and firefox profiles; or 2) Skype is doing its best to "just work" with your network configuration if possible.
Option #2 explains all of the "suspicious" activity quite nicely. #1 is absurd if you think about it.
Yes, it does actually work. It works because: * every single device is a repeater! * they repeat by simulcasting. if 10 of your 50 devices hear the signal, all 10 will retransmit together in unison, generating one seriously strong signal. * Unlike X10, they are very very fast. X10 has 1/3 to 1/2 second latency. Insteon is practically instant. Certainly fast enough to be percieved as "instant", anyway. * Unlike X10 which degrades as you add devices, Insteon improves as you add devices. * You have RF bridges that you can add to bring the signal via RF to weak spots, if you somehow have any. Usually you need an RF bridge to cross phases in the house, but once you get enough devices even that is unnecessary.
I have 50-something of these installed. They are more reliable than UPB here. X10 was an utter disaster in this house... we have UPS's everewhere, loads and loads of noisy fluroescent lights, noisy fish aquarium electronics, etc. Insteon handles it without missing a beat.
HOWEVER.. All is not perfect. It is a young technology. Smarthome have made mistakes and to their credit are fixing them.
My current problem is that their Appliance modules seem to be troubled by electrical noise, eg: EMF spikes from turning fluroescent lights on/off. It seems to crash the microcontroller on them. Older models used to burn out their load sense circuit with those electrical spikes. They're fixing them, but just not fast enough for my liking.
Computer interface software has been very slow, but being fixed on a daily basis. 3rd parties are adding Insteon support to their home automation software on a near weekly basis these days.
Smarthome are providing a cost-cut version under the 'ICON' brand and are in the process of getting them into Home Depot stores. $20 for a decent remote controllable dimmer compares pretty nicely to the dumb electronic dimmers they have.
Yes, you can get developer docs via a SDK (comes with hardware to test with). Yes, it is easy to write unix software for it - I've done it myself. They do have a certification requirement if you're going to use the Insteon brand on your "product" though. But you can give it away as open source if you don't pretend it is certified.
I think Insteon will ultimately win the defacto standard stakes. ie: it will be as ubiquitous as X10 at its height.
You know, I would *LOVE* to have the problem of having to try and make this work. But somehow I really can't get excited about that, especially since we'll be having to futz with the calendar sometime "soon" to deal with the leap second issue. I really don't care that there is an integer overflow in libc when time_t hits 56 bits in FreeBSD:-)
Except of course that there is an integer overflow somewhere up at the high end of the scale in the libc code. Oh we,, I guess we've got a few million years or so to figure it out.
My unix time_t goes for a few hundred million years or so, not 2038. All current 64-bit FreeBSD systems have a 64 bit time_t. libc's time suite (eg: mktime/ctime etc) all support Jan 1 1900 through a Very Long Time. We had to cut off below 1900 because we don't have timezone info for that and allowing tm_year (years after 1900) to be negative causes all sorts of interesting problems in software.
peter@daintree[2:14pm]~-157> cat t.c #include #include main() {
time_t t = LONG_MAX;
printf("end of the world: %s", ctime(&t)); } peter@daintree[2:14pm]~-158> cc -o t t.c peter@daintree[2:14pm]~-159>./t end of the world: Sun Dec 4 07:30:07 219250468
It was suprising how little software breaks with a 64 bit time_t.
Precisely that. Supposedly they want to limit how long it takes them to crack an encrypted conversation between terrorists, foreign agents, etc etc. However, the big hole in that argument is that the assumption that terrorists are outside the US is false, as is the assumption that they can only use US provided tools to communicate.
Anyway, you can bet that the moment a 'person of interest' holds a skype conversation after eBay is at the helm, that the crypto strength will become an 'issue'.
However, the real interesting thing is how does eBay, a US company, get around the US export restrictions? eg: it's been mentioned that 128 bit AES is the limit that you can get export approval for. Given skype's 256 bit AES, will eBay have to weaken it when they release it after the ownership transfer is complete?
Or do they have wiggle room and claim that its produced offshore and therefore isn't exported from the US, even though its now owned by a US company? I doubt that will go down well with the powers-that-be, because (among other things) that will just encourage US companies to offshore all their products-with-crypto work to get around the regulations.
Tivo give you the source of the kernel, the source of the tools, the source of the packaging tools including the signature generator. The signature of the virgin kernels are there for the taking too.
So, you can use their tools to produce a kernel and it comes out identical. You have the signature and the tools to insert the signature in the.px file. You have everything that you need to produce the binary that tivo distribute. This is what the GPL requires.
But you don't have the private key to generate a signature. So if you modify what tivo gives you, you can't generate a signature.
But nobody has thought of a legal argument to compel tivo to give out the private key.
Or, from a completely different perspective. Suppose you take a linux.tgz file and sign it with your private gpg key. You then distribute the kernel, the source and the signature. Should you be compelled to distribute your personal private key too so that anybody can produce your signature saying its a good kernel?
Tivo's hardware just happens to insist that there is a recognized signature on anything that it'll run. That's not a GPL issue.
Whether it should be is a different issue. GPLv2 predates the whole DRM and signature issue. It just never occurred to the authors that signatures would be used this way. You can bet the GPLv3 will have something to say about this oversight.
There's the issue of identical twins vs souls too. If you take the fundamentalist "given" that the soul begins with conception.. what happens when the cell cluster breaks into two pieces after conception? ie: a natural clone. Does the original soul split in two?
Bingo! There is no such GPL clause. Take tivo hardware for example. They publish the modified kernel source that they use, but its near useless because the firmware checks for the signatures for authorized kernels. If you dont have the signature, you don't get to play. (Or you have to hack/subvert it somehow).
Heh, except that (again) there is no such thing as a free lunch. The electricity that you get from the brakes is simply a partial recovery of the kinetic energy that originated from the car engine. Unless you were pushing the car yourself, the energy ultimately came from the fuel in the tank in the first place. Even if it was from braking on a downhill run, the engine still had to work extra hard to get up the hill in the first place. And of course, at each transition there is wastage.
I believe it would be significantly more energy efficient to put an electric compressor in the car for A/C operation when the engine isn't running than use peltier cooler.
There are some distinct advantages to peltier coolers compared to fluid phase change heat pumps, but energy efficiency isn't one of them. They're cheaper, lighter and simpler (no noisy moving parts!!), but that's about it.
You want a peltier cooler for your aquarium during the summer, not your car.
"Freon is a trade name for a group of chlorofluorocarbons used primarily as a refrigerant. The word Freon is a registered trademark belonging to DuPont."
R-12 refrigerant is a chloroflurocarbon. ie: Freon.
My closing comment was too brief. I probably should have said "there is no such thing as a free lunch".
See my comments in #13120817about the efficiency aspects of it though.
Peltier coolers contain no greenhouse gasses nor ozone depleters. But they still need lots of energy to run, which comes from a greenhouse gas producer (internal combustion engine).
Car A/C systems contain greenhouse gasses which can escape to the atmosphere in accidents or when idiots do stupid things. Older ones contain ozone depleters. And they too use energy to run.
A decent car A/C system should leave a peltier system in the dust for energy efficiency. Of course, that is assuming there are decent car A/C systems.
And then there's the financial incentives. R-12 is increasing in value at a quite nice rate. It is extracted from old A/C systems and resold to repair other systems that haven't been retrofitted yet. R-12 is quite valuable these days.
Of course, all the environmental impact of the gasses assumes that the gasses escape... The $25000 fine for deliberately releasing R-12, plus the high price of R-12 makes it well and truely worth recovering.
I bet more geeks have released difluroethane or tetrafluroethane into the atmosphere via dust remover / compressed "air" cans than they'll ever release via car airconditioner leakage. This "air" can is of course the same gas that is used in R-134a (tetrafluroethane).
To refer to posts above, the peltier coolers have a severe disadvantage.
#13120684: Normal peltiers have an efficiencies of less than 30% Modern air conditioners have an efficiencies approaching 400%.
#13120746: Modern aircon works by using matter phase change and using pump to move the fluids. It transfers more heat than the energy consumed in moving the fluids.
So while I don't have one of these, I'm really really sceptical that the CO2 and other greenhouse emissions per unit of cooling by a peltier can get anywhere near a modern air conditioner.
Freon (R-12) hasn't been used in new cars for something like a decade now. R-12 is an ozone depleter. It hasn't been manufactured in the US since the mid 90's or so
Newer car air conditioners use refrigerant R-134a. This is *not* an ozone destroyer, but it is still a greenhouse gas.
Peltier coolers use electricity, which is generated by the horribly inefficient internal combustion engine which produces greenhouse gasses and other toxins by the boatload.
In case anybody's interested, yahoo's firefox toolbar has been around for a while. It worked out of the box for me on Linux and FreeBSD machines, including a 64-bit build of firefox for FreeBSD/amd64. http://toolbar.yahoo.com/firefox?fr=firefoxtoolbar
Slashdot Mirror
The bug was in the unreleased FreeBSD-11 work-in-progress developer tree.
If you are running an actual release, or one of the stable branches, you are not affected.
The main cause for concern is if you are generating keys in some form on the developer tree.
I also suspect they've managed to botch the technical aspect of it as well.
Presumably the plan was to put their caching name servers in front of the real no-ip servers, and gather the mappings for the malware suspect sites and then blackhole them after getting what they want. The problem was that Microsoft's side appears to have melted down, thus taking everything down. They won't be getting logs, behavior analysis or anything, because its all a pile of wreckage in a crater. Meanwhile, all the "bad guys(TM)" have now had hours head start to delete their C&C node registrations while microsoft's servers are down. And now they've ticked off the no-ip folks, so I wouldn't expect them to be in a cooperative mood to try and help.
Bone headed all round. There's no other way to put it.
The motion is here: http://www.noticeoflawsuit.com...
A quick skim of the motion for the court order gave me the "boilerplate" and "cut & paste" feeling. There is a lot of sloppy line blurring between actions and complaints directed at the Malware authors and the no-ip folks. Sometimes they refer to the "Malware Defendants" and other times the generic "Defendants" when they meant the former. Really sloppy legal work.
There are some real gems in there:
From section 7:
"There is good cause to believe that immediate and irreparable damage to this Court’s ability to grant effective final relief will result from the sale, transfer, or other disposition or concealment by Defendants of the Internet domains at issue"
Say what? How is that related anything? Its not like the TRO will actually prevent people from being able to hit 'delete' via the control panel. Given that everything's busted by their own doing, the bad guys got a huge head start.
From section 8: ..." ...
"... and the interest of justice require that this Order be Granted without prior notice to Defendants
Wow
The full motion text: http://www.noticeoflawsuit.com...
It seems to me that regardless of what good intentions that Microsoft may have had, they've really fouled up the execution. They'll be remembered more for taking out millions of legitimate users than the malware they *might* be able to take down.
The TSA does a whole lot of pre-flight data mining on passenger lists. I recall some discussion a while back about how they included included things like the credit card numbers, billing addresses etc in the mix.
Paying with Bitcoin has the same problem as paying with straight-up cash - it sets of all sorts of red flags because there's no real way to see if you're "connected" to other "interesting" people or not. No data = guilty until proven innocent etc.
When you're on the clock for getting to your departing flight, you really don't want to be on the wrong side of the extra special friendly pat-downs reserved for special troublemakers.
People like Expedia won't be wanting to mess with this can of worms for now, so they'll keep their bitcoin experiments a nice safe distance from the US Federal Government universe.
Yes. This.
Most likely, they screwed up and lost their private keys. ie: Plain old incompetence.
The code that was leaked to pastebin made it look like they were storing these in something like instances on Amazon EC2. If it turned out they were storing it on ephemeral storage rather than EBS, I don't know if I'd laugh or cry. But it would be an explanation if it were true. Again tough, that would come back to incompetence.
No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion...how hackable is it; Xcode(SDK) will only work on Mac OS X.
GPL didn't stop Xcode existing when it operated around gcc. Xcode will always be an OS X thing, it has nothing to do with the back end compiler license.
Yes, they get a lot of mileage out of tightly coupling Xcode with llvm - eg: they don't have to write the same level of context sensitive language support for editing when you can do constant incremental compiling and inspect the state of the compiler's trees.
BTW; Apple use LLVM for far more than just Xcode. They used it in the display subsystem to run-time optimize code to the actual machine's display configuration.
Being GPLv3 is a bonus for Apple, but it's about more than that. Competition is a good thing.
Well.. GPLv3 specifically. FreeBSD is stuck on GCC-4.2, the last GPLv2 gcc compiler. It's getting quite dated now. It's a switch from gcc-4.2.2+ hacks/patches to clang instead of a GPLv3'd gcc-4.6 or later.
"Stuck"? FreeBSD gets a foot in the door of companies where GPL (and GPLv3 in particular) is something they'd prefer not to deal with. Being able to use a modern GPL-free OS as a foundation of a product is a convenient option to have. And being GPLv3-free can be even more compelling.
Yes. The article is vague, and the title on /. is worse - implies the source repository. It seems people have been easily mislead as a result. Always read the actual article, not a 2nd or 3rd hand summary.
From there:
"The code modifications did not made it into our source control, just the final package. We are currently investigating older packages to see if they were also compromised. "
As has been stated 10 million times above, they're not reading /etc/passwd. They're calling the C/Posix API function getpwuid(). Why? Because it is the safest way to find the user's home directory - in order to locate a firefox profile. They probably check $HOME as well.
Why check the firefox profile? Because they can look at your proxy settings, to see if it needs to use a socks4 or socks5 proxy at all.
This is all part of their "just works" auto-configuration. It is far from the end of the world.
Which is a more reasonable explanation?
1) Skype is data mining stuff to create a giant database of user names and firefox profiles; or
2) Skype is doing its best to "just work" with your network configuration if possible.
Option #2 explains all of the "suspicious" activity quite nicely. #1 is absurd if you think about it.
Yes, it does actually work. It works because:
* every single device is a repeater!
* they repeat by simulcasting. if 10 of your 50 devices hear the signal, all 10 will retransmit together in unison, generating one seriously strong signal.
* Unlike X10, they are very very fast. X10 has 1/3 to 1/2 second latency. Insteon is practically instant. Certainly fast enough to be percieved as "instant", anyway.
* Unlike X10 which degrades as you add devices, Insteon improves as you add devices.
* You have RF bridges that you can add to bring the signal via RF to weak spots, if you somehow have any. Usually you need an RF bridge to cross phases in the house, but once you get enough devices even that is unnecessary.
I have 50-something of these installed. They are more reliable than UPB here. X10 was an utter disaster in this house... we have UPS's everewhere, loads and loads of noisy fluroescent lights, noisy fish aquarium electronics, etc. Insteon handles it without missing a beat.
HOWEVER.. All is not perfect. It is a young technology. Smarthome have made mistakes and to their credit are fixing them.
My current problem is that their Appliance modules seem to be troubled by electrical noise, eg: EMF spikes from turning fluroescent lights on/off. It seems to crash the microcontroller on them. Older models used to burn out their load sense circuit with those electrical spikes. They're fixing them, but just not fast enough for my liking.
Computer interface software has been very slow, but being fixed on a daily basis. 3rd parties are adding Insteon support to their home automation software on a near weekly basis these days.
Smarthome are providing a cost-cut version under the 'ICON' brand and are in the process of getting them into Home Depot stores. $20 for a decent remote controllable dimmer compares pretty nicely to the dumb electronic dimmers they have.
Yes, you can get developer docs via a SDK (comes with hardware to test with). Yes, it is easy to write unix software for it - I've done it myself. They do have a certification requirement if you're going to use the Insteon brand on your "product" though. But you can give it away as open source if you don't pretend it is certified.
I think Insteon will ultimately win the defacto standard stakes. ie: it will be as ubiquitous as X10 at its height.
You know, I would *LOVE* to have the problem of having to try and make this work. But somehow I really can't get excited about that, especially since we'll be having to futz with the calendar sometime "soon" to deal with the leap second issue. I really don't care that there is an integer overflow in libc when time_t hits 56 bits in FreeBSD :-)
Except of course that there is an integer overflow somewhere up at the high end of the scale in the libc code. Oh we,, I guess we've got a few million years or so to figure it out.
My unix time_t goes for a few hundred million years or so, not 2038. All current 64-bit FreeBSD systems have a 64 bit time_t. libc's time suite (eg: mktime/ctime etc) all support Jan 1 1900 through a Very Long Time. We had to cut off below 1900 because we don't have timezone info for that and allowing tm_year (years after 1900) to be negative causes all sorts of interesting problems in software.
./t
peter@daintree[2:14pm]~-157> cat t.c
#include
#include
main()
{
time_t t = LONG_MAX;
printf("end of the world: %s", ctime(&t));
}
peter@daintree[2:14pm]~-158> cc -o t t.c
peter@daintree[2:14pm]~-159>
end of the world: Sun Dec 4 07:30:07 219250468
It was suprising how little software breaks with a 64 bit time_t.
Precisely that. Supposedly they want to limit how long it takes them to crack an encrypted conversation between terrorists, foreign agents, etc etc. However, the big hole in that argument is that the assumption that terrorists are outside the US is false, as is the assumption that they can only use US provided tools to communicate.
Anyway, you can bet that the moment a 'person of interest' holds a skype conversation after eBay is at the helm, that the crypto strength will become an 'issue'.
However, the real interesting thing is how does eBay, a US company, get around the US export restrictions? eg: it's been mentioned that 128 bit AES is the limit that you can get export approval for. Given skype's 256 bit AES, will eBay have to weaken it when they release it after the ownership transfer is complete?
Or do they have wiggle room and claim that its produced offshore and therefore isn't exported from the US, even though its now owned by a US company? I doubt that will go down well with the powers-that-be, because (among other things) that will just encourage US companies to offshore all their products-with-crypto work to get around the regulations.
Tivo give you the source of the kernel, the source of the tools, the source of the packaging tools including the signature generator. The signature of the virgin kernels are there for the taking too.
.px file. You have everything that you need to produce the binary that tivo distribute. This is what the GPL requires.
So, you can use their tools to produce a kernel and it comes out identical. You have the signature and the tools to insert the signature in the
But you don't have the private key to generate a signature. So if you modify what tivo gives you, you can't generate a signature.
But nobody has thought of a legal argument to compel tivo to give out the private key.
Or, from a completely different perspective. Suppose you take a linux.tgz file and sign it with your private gpg key. You then distribute the kernel, the source and the signature. Should you be compelled to distribute your personal private key too so that anybody can produce your signature saying its a good kernel?
Tivo's hardware just happens to insist that there is a recognized signature on anything that it'll run. That's not a GPL issue.
Whether it should be is a different issue. GPLv2 predates the whole DRM and signature issue. It just never occurred to the authors that signatures would be used this way. You can bet the GPLv3 will have something to say about this oversight.
There's the issue of identical twins vs souls too. If you take the fundamentalist "given" that the soul begins with conception.. what happens when the cell cluster breaks into two pieces after conception? ie: a natural clone. Does the original soul split in two?
Bingo! There is no such GPL clause. Take tivo hardware for example. They publish the modified kernel source that they use, but its near useless because the firmware checks for the signatures for authorized kernels. If you dont have the signature, you don't get to play. (Or you have to hack/subvert it somehow).
And the GPLv2 has nothing to stop this situation.
Heh, except that (again) there is no such thing as a free lunch. The electricity that you get from the brakes is simply a partial recovery of the kinetic energy that originated from the car engine. Unless you were pushing the car yourself, the energy ultimately came from the fuel in the tank in the first place. Even if it was from braking on a downhill run, the engine still had to work extra hard to get up the hill in the first place. And of course, at each transition there is wastage.
I believe it would be significantly more energy efficient to put an electric compressor in the car for A/C operation when the engine isn't running than use peltier cooler.
There are some distinct advantages to peltier coolers compared to fluid phase change heat pumps, but energy efficiency isn't one of them. They're cheaper, lighter and simpler (no noisy moving parts!!), but that's about it.
You want a peltier cooler for your aquarium during the summer, not your car.
Umm, no.
"Freon is a trade name for a group of chlorofluorocarbons used primarily as a refrigerant. The word Freon is a registered trademark belonging to DuPont."
R-12 refrigerant is a chloroflurocarbon. ie: Freon.
R-134a is tetrafluroethane. ie: not Freon.
My closing comment was too brief. I probably should have said "there is no such thing as a free lunch".
See my comments in #13120817about the efficiency aspects of it though.
Peltier coolers contain no greenhouse gasses nor ozone depleters. But they still need lots of energy to run, which comes from a greenhouse gas producer (internal combustion engine).
Car A/C systems contain greenhouse gasses which can escape to the atmosphere in accidents or when idiots do stupid things. Older ones contain ozone depleters. And they too use energy to run.
A decent car A/C system should leave a peltier system in the dust for energy efficiency. Of course, that is assuming there are decent car A/C systems.
And then there's the financial incentives. R-12 is increasing in value at a quite nice rate. It is extracted from old A/C systems and resold to repair other systems that haven't been retrofitted yet. R-12 is quite valuable these days.
Of course, all the environmental impact of the gasses assumes that the gasses escape... The $25000 fine for deliberately releasing R-12, plus the high price of R-12 makes it well and truely worth recovering.
I bet more geeks have released difluroethane or tetrafluroethane into the atmosphere via dust remover / compressed "air" cans than they'll ever release via car airconditioner leakage. This "air" can is of course the same gas that is used in R-134a (tetrafluroethane).
To refer to posts above, the peltier coolers have a severe disadvantage.
#13120684: Normal peltiers have an efficiencies of less than 30% Modern air conditioners have an efficiencies approaching 400%.
#13120746: Modern aircon works by using matter phase change and using pump to move the fluids. It transfers more heat than the energy consumed in moving the fluids.
So while I don't have one of these, I'm really really sceptical that the CO2 and other greenhouse emissions per unit of cooling by a peltier can get anywhere near a modern air conditioner.
Freon (R-12) hasn't been used in new cars for something like a decade now. R-12 is an ozone depleter. It hasn't been manufactured in the US since the mid 90's or so
:-(
Newer car air conditioners use refrigerant R-134a. This is *not* an ozone destroyer, but it is still a greenhouse gas.
Peltier coolers use electricity, which is generated by the horribly inefficient internal combustion engine which produces greenhouse gasses and other toxins by the boatload.
It's all bad.
In case anybody's interested, yahoo's firefox toolbar has been around for a while. It worked out of the box for me on Linux and FreeBSD machines, including a 64-bit build of firefox for FreeBSD/amd64.r
http://toolbar.yahoo.com/firefox?fr=firefoxtoolba