They're dumb, but they're not that dumb, and I'm not _that_ bright. One of them would think of those soon enough.
Just like PWNtcha (though that's far worse) - hiding your head in the sand and not publishing these won't stop them from figuring it out - there's money to be made by defeating captcha tests, so there's considerable incentive. And it's not like it's that tough an idea to figure out.
Like I said - make it annoying/painful/expensive enough and it no longer becomes worth their while. Of course, that can make it annoying for all of us too...
Sorry, typing quickly. (And it could be JS code ala AJAX/Google Maps/etc, in theory - might be harder, though, but more compatible.)
Re:spammer's low-tech way
on
Defeating Captcha
·
· Score: 3, Insightful
It's trivial to hack a browser (hell, you don't even have to actually hack it, just know how it works) to snag the image for you. Then repeat as per grandparent (have a unwitting (or witting) human do it for you).
Next stage: make the captcha Java code that generates the warped image dynamically. Reponse: send the JS to the unwitting human.
Next stage: make the Java code generate the token using something intrinsic to the machine running it (IP, etc, etc). Response: snatch the image from display ram to present to the unwitting human.
Next stage: include in the image information about what the image is for (site, etc). Response: block those parts, or use witting humans who don't care or are otherwise paid (in porn, 3rd-world wages, etc).
You can make it progressively harder, but you can't make it impossible. You might be able to make it hard enough, though.
Those are good suggestions, though ground-source heat pumps can have 5-10 year paybacks - depending on the type and situation and energy costs. Here (SE PA) we pay 14+ cents kWhr (16.5+ if you sign up for all wind power, 6.5 or 9 cents in the winter if you have the "electric heating" rate).
It also depends on how much heat you need. Our old, sprawling, leaky 4100 sq. ft. house with ~80 windows (quite a few of them quite large) has 11.5 tons of heat pumps (5, 2.5 and 4 - 13, 15 and 10 SEER). (We've greatly improved the sealing, and added some insulation including to a sunroom which had no insulation (not even an airspace) in the ceiling - now it's ~R20 of high-density foam board). As for $75/month - I'd kill for that.:-) During Jan/Feb, our heating bill (without the 2.5 cent wind surcharge) is around $450/month, even at the 6.5 cent all-electric rate and using our woodstove daily. Outside temps are in the 5-20 at night, and 15-35 in the day generally.
You also have to try to predict future energy prices. They may not be as stable as today... You can also get considerably reduced costs for heating domestic hot water, especially in the summer, and hot water is often 30% of a family's yearly energy bill.
That said, installation and equipment cost is the primary issue. You need around 80-100' of borehole per ton in this area, and I think drillers charge around $7/ft or more. (This is for a standard water-coupled closed-loop pump.) Plus you have to trench to the house. Direct Exchange heatpumps (no water involved; working gas/fluid goes directly into smaller pipes in the ground) is more efficient and less moving parts, though it's a newer technology. However, it's harder to find an installer, and they may charge more, especially if they have to come a distance or they're overbooked.
In our case, after looking at it a lot, we decided it was just not worth it (yet) - payback was at best 7-10+ years, maybe more. We went with good 2-stage air-source units and put in a high-efficiency non-cat woodstove to supplement during the coldest months.
As stated in comments to other replies to this message, ground source heat pumps work fine even into the far north. Even air-source heat pumps (with appropriate auxilliaries) are efficient into the northern tier of states. And natural gas is no longer cheap.
Geothermal cost comparisons: http://tristate.apogee.net/geo/minneap.asp (NOTE: those are based on 6/ kWh; 60/ ccf gas; $1.00/gal oil). In most places, it's 8-10 cents/kWh, well over $1/ccf, and $1/gal oil? Ha! Try $2-2.50 at least. Even at the prices they list, in MN (not exactly a warm place), air-source is on a par with oil and better than propane, though behind natural gas. Ground-source beats them all be a significant margin; if you update the figures for current fuel/electric prices, even air-source heatpumps probably beat natural gas, and ground source beats oil by a 2x factor (circa $1000-1500/year), and beats natural gas probably by at least $500-800, maybe more.
A good energy costs calculator (for relative costs): http://www.hearth.com/articles/47_0_1_0_M7.html. Note: for heat pumps, use electric and put in an efficiency value of around 250. That will be a pessimistic guess for year-round efficiency unless you live very far north; year-round average is probably more like 275, perhaps 300 in middle to southern states. Ground-source heatpumps - use a value of 350 to 400. And don't forget to update the local costs of different fuels and efficiencies for furnaces!
Re:anecdote about a canuckistani heat pump
on
Creating a Clever Home?
·
· Score: 2, Informative
As someone else stated, that's a plain air-source heat pump in all likelyhood (though even with ground-source, it may be more efficient/cost-effective to not size it for the coldest possible days of the winter, and use an auxilliary to supplement on the coldest 5% of days).
Note that when a heat pump (air or ground source) can't keep up, it still produces a lot of heat, just not as much as the structure loses. The controller then calls for Aux heat, which can be electric (most common), propane/oil/nat.gas boiler via a heat-exchange coil, etc. Or it can be manual (wood stove).
Typical modern air-source heatpumps have an efficiency ratio at 17 degrees of around 2.1-2.5 - i.e., they produce 210 to 250% of the heat you'd get by running the same electricity into a resistive heater (100% efficient). They're usually over 300% (even 350%) at 45 degrees.
Ground-source heatpumps are more efficient because the source is a fairly constant 45-60 degrees, depending on where you live. In the mid-atlantic, 50-55 is the norm. New Hampshire is around 45-50. Texas is probably 60-65. (Bush has a ground-source heatpump (for cooling)). Thus in heating mode, they run at 300-400% efficiency regardless of outside temps (minus some pumping/etc losses). In cooling mode, they're also more efficient since they're dumping heat into a 45-60 degree heat sink, instead of trying to dump it into 90+ degree outside air. They also usually last longer (20-25+ years, as opposed to circa 13-15 for air conditioners and air-source heatpumps) since they're not exposed to the elements. Downside: considerably higher installation costs for trenching or drilling; hard to find local installers (this may change).
We have 3 heat pumps (air-source, 2 dual-speed) with electric auxilliary (3 sections of the house with no way to duct between them). When outside temps get below 20-25ish, the aux's will occasionally turn on. We run a wood stove pretty much all winter, especially when it's very cold. With a small woodstove in the main section, it rarely if ever calls for aux if the outside temp is above 10, and not often when it's below 10.
It varies, a lot, in the US. In urban and suburban areas, it's generally cheap and available.
These are minimums; higher bandwidths are generally available: DSL is generally $35ish/month which is now ~1.5Mbps down, 256-384K up (this has gone up a bunch in the last year or two from 768 down, 128 up).
Cable is generally 1.5-6 Mbps down, 150-384K up (Comcast, the largest by far, is switching to all 6 down, 384 up or better, or about that). Price is a little higher, circa $45/month. In the last 2 years, it was from 1.5-2Mbps/150-256K. They're starting to offer VoIP.
Verizon and SBC are rolling out fiber to the premises or curb. Verizon is 5Mbps down, 2Mbps up, for $35. They justify it by providing phone over fiber (not necessarily VoIP though), and are starting to roll out video to fully compete with the cable companies.
The main reason for low prices for broadband is competition - DSL and cable are very competitive, and that brings prices down and encourages them to compete on bandwidth/features.
In rural areas, sometimes DSL or cable is available (often lower speeds due to distance for DSL), or dialup. When on vacation in the mountains (but only 1.5 hours from two major urban areas), we used dialup for $20/month, but it's often available cheaper.
There's a reason they say "interconnected" VoIP providers - those are ones that interconnect to the PSTN. Pure IP-to-IP isn't covered, at least by that portion of the ruling. Interconnected providers have all the data going through PSTN lines on the destination end, so you can make an argument that those calls are subject to tapping and CALEA anyways.
Now, the way they phrased things about "facilities-based broadband internet access service suppliers and VoIP providers that offer services permitting users to receive calls from, and place calls to, the public switched telephone network" is open to interpretation - it depends on how the 'and' is parsed, and of course this isn't the actual rule, but the press release about the rule. If it only applies to calls to and from PSTN gateways, and then only on the companies offering such gateway service, it has far less impact on general internet access. Of course, that's a big 'if'.
VoIP gateway providers like Level 3 (used extensively by Vonage) provide CALEA processing, and have always expected to be included under CALEA (aka "lawful intercept"). Typically it would only occur at the same point where PSTN interface occurs (since the traffic is there anyways). There are I believe two types of intercept - "trap and trace" (aka who called who, but not the traffic), and a full capture of any calls. Also, since this is going through a voice gateway, it's effectively a MITM attack as far as any encryption is concerned - if there is encryption to the gateway (and I don't think any support it currently anyways), they can record after decryption for conversion to PSTN/SS7.
This is also why they're not expanding it to IP to IP calls - yet. The VoIP providers have no easy way to intercept those calls without giving away that it's being monitored (i.e. the IP address of the destination would be different). The exception for IP to IP calls would be calls that go through a TURN server, border controller, or other provider-controlled RTP relay.
My assumption is that once IP to IP calls start to increase in number, and additional technical solutions are available, they would expand it to those as best they can. It's very tough to do if no provider/service is involved, though - direct SIP calls with no server, for example. (Of course, allowing direct SIP opens you up to SPIM (SIP spam calls) in theory). That would provide the justification to allow trapping all traffic to/from an internet user - which they can do now with things like carnivore, but not as easily as if the internet provider would provide the packet-record mechanism under CALEA. And the next step to note is that trapping the packets of an IP to IP call won't help if they're encrypted, so they'd want back-doors to devices with encryption capabilities, and/or get the ISP to help them provide a MITM attack. Or outlaw encrypted calls ("when encryption is outlawed, only outlaws will have encryption" - from a button I've owned for 20 years). Or make it a crime not to provide keys on request (ala proposals in britain).
The base problem is that the journalist needs to know their source and communicate with them, and perhaps let an editor know the source's name as well, but they need to do so without leaving a record trail that would allow someone else trying to track down the source to figure it out.
We can mostly leave the "how do you prove who it is that is leaking" up to the leaker and the reporter. The problem is the untracable after-the-fact communications channel (and preferably hard to intercept as a general case, so wiretaps aren't effective).
Communications channels: 1) Personal contact. There is the issue of how do you know to make contact in person, but that's handlable. Biggest danger here is the increasing number of random video cameras that might be reviewed afterwards to figure out who met with Reporter X. Easiest if there are other reasons they'd meet anyways.
2) snail mail. Easily destroyed after reception. Generally impossible to track after-the-fact - at most the date and rough location of the source. Vulnerable to interception if that's set up ahead of time, but generally requires real court acquiesence (modulo Patriot Act). Mail drops can be used, or sent via friends/neighbors/etc.
3) Regular/cell phone calls. Lots of records; easy to trace after-the-fact. Simplest way to avoid tracing: use public phones (becoming rare). Use a phone not likely to be suspected of being the destination (call the reporter when they're visiting a friend/neighbor/family member). May be tracable if they check records of outgoing calls from someone suspected.
4) voip, especially point-to-point SIP. Not generally tracable after-the-fact; if a sniffer has been installed it can generally be traced unless routing games are played.
5) email from/to "free" email accounts. Similar to voip - hard to trace after-the-fact, though easier than voip - records may be kept on the email supplier, and computers may indicate what ID's to check. Best done from a public-access PC (libraries); in that case it's very hard to find after-the-fact unless the general vector is exposed in some manner - and it may be. Still may be hard to trace.
6) Prepaid cell phones - but only if they can't easily be traced to either party. Even then, traffic analysis could rat you out - they get records from the cell company about all calls in a cell that includes where the reporter lives or works, and sort through them - especially if they know approximately when and where the reporter was called.
etc.
There are I'm sure lots of posts about how to in a hidden way do web/etc stuff. That's not really the point.
The big issue is that the reporter has to be cognizant that ANYTHING tracable may give away the source. Phone records and email of course, but knowing when data was transferred, knowing too much about what data was given, doing web searches based on the data received, etc. If they really want to maintain anonymity of their sources, they need to be very careful. Verbal discussion with editors of identities only. Never call them or be called. Never write down their name or anything else identifiable, or if you do destroy it (well).
Now, this level of paranoia may only be needed for "big stakes" anonymous sources. If it's over someone on city council taking a kickback, only a modicum of anonymizing may be needed (though avoiding written/electronic records is still a really good idea).
a) they can trivially break your VoIP security if they do a MITM attack, unless you have a functioning PKI (that you can verify),
That's not an unlikely 'unless.' Exchanging public keys (or fingerprints, I should say) would be quite easy unless you are initiating a call with a complete stranger. Even if you haven't had a chance to swap details with your partner beforehand, you can always begin the conversation with "my fingerprint is..."
Telephones are often used for calling strangers. Also, this basically devolves to the original PGPhone security model - unless you have an out-of-band secure channel for exchanging certs, you can't easily avoid MITM attacks, except by a PGPhone-like "read off some words that authenticate the session key" trick. And who will do that at the start of every call? And that assumes the certs are visible and easily read off/verified, which normally they're not.
As for SSL tunnels, as I said, it depends on trusting Verisign (or whomever) to authenticate the other side. From the Diffie-Hellman wiki page you pointed to:
the Diffie-Hellman exchange by itself does not provide authentication of the parties, and is thus vulnerable to man in the middle attack.
As for encrypting POTS calls: take audio. digitize. Encrypt*. Translate back to audio (modem chipsets are fine). Send. At the other end, do the reverse. The issue is encryption and keys and key exchange, of course. My friends were using some fancy method to provide a pseudo-OTP and avoid having to do serious encryption in HW/SW in realtime (this was ~1983, remember). Never went anywhere, and some of them got paranoid after the "business" guy (perpetual student/MBA type) met with eastern european officials. MUCH easier to do today. Back then, even the modem chips I suggested would have been a stretch for doing full audio - 2400 baud was good back then.
As for CALEA, I suspect Skype does it for SkypeOut (or will, or rather their partners do/will). Regular Skype - perhaps not, but you have to trust them...
If it's a TCP tunnel, you add really bad delay and jitter in response to packet loss.
If it keeps UDP as a form of UDP (IPSEC might do this), you only lose the QOS flags plus any VPN-related delay (which may be non-trivial, or may be no worse than direct SRTP encryption).
Re:Anonymous Diffie-Hellman would be "good enough"
on
VoIP Security
·
· Score: 1
As you imply, though, anonymous (no working PKI infrastructure (that you can trust)) DH will NOT protect you from MITM attacks. As others have mentioned, security agencies certainly can MITM you (hell, they can just tell Comcast or Verizon to give you DHCP pointing your DNS servers to ones they control). So can organized crime (read the post about 3rd-world hotels (Phillipines) where they will use captive DNS servers to direct you to sophisticated phishing sites). Etc.
Not to say that anonymous DH w/ SRTP isn't worlds better than in-the-clear RTP, modulo call setup time.
a) they can trivially break your VoIP security if they do a MITM attack, unless you have a functioning PKI (that you can verify), or you trust a central authority (and can you?) Yes, you exchange keys with them, but who is "them"? The original Zimmerman PGPhone used user-read english words to verify that the keys used for the session were the keys each side thought were in use, thus in theory detecting MITM attacks. That's not directly part of any modern VoIP security. Check the cert/keying stuff for SIP used to choose keys for SRTP. To do it securely at all, you need a functioning PKI or a TLS connection to the SIP server - and you need to trust that TLS connection and that SIP server.
Ditto for SSL - you accept the certificate because it's signed by Verisign and it says they are who they say they are. In theory, you can examine it and verify if out-of-band, but no one does. I'd be shocked if the NSA didn't have the ability to "sign" certs as Verisign and so institute a MITM attack on someone thinking an SSL connection is sacrosanct.
b) You can encrypt audio in POTS phone calls. The HW for it isn't trivially available, but it's certainly doable. I had friends who made virtually uncrackable digital audio telephone scramblers back in 1983ish at RPI, and tried to start a company to sell them.
c) CALEA - the VoIP provider is being required to allow tapping of calls. Currently that's targetting calls that go through their equipment aka POTS gateways.
I finally got rid of the 5 Sun-2's in my basement when I moved a couple of years ago (less basement space in the new, bigger house). These were used to develop the AmigaOS back in the mid to late 80's (before we moved all the modules to native compilation). Along with them went the PDP 11/64. I kept the SunOS tapes, though.
Moments: getting my 2MB huge Zorro-I expansion card for my Amiga 1000, and figuring out how to do all my work from (recoverable across crashes) ramdisk. Playing Faery Tale Adventure. Playing Mule on a C64 with the homeless druggie friend of a roommate in college. Running the weird hypnotic graphics demo that came on one of the Amiga 1000 disks during parties and seeing people get stuck watching it.
Playing Netrek on the 'net on a league team (the Buddies) back in circa 1990.
One measurement I found was 2.2MB over 2 hours; average about 4.8 Kbps. I've read other estimates of 1-2Kbps. Probably depends a lot on what you're doing, how over you switch areas, how much time you spend in towns (lots of people running around and talking), adventuring with humans or hirelings, etc. Running around the wilderness with hirelings might use almost no BW.
Of course, in a player party, the PC's may be communicating largely directly with each other instead of via the server (so it doesn't use _their_ bandwidth). Haven't Ethereal'd it to see yet.
Is "safe machine" by IP or cookie? Cookie I'll bet, since dialup, some DSL (and occasionally cable) IP's change often.
If it's by cookie, it's stealable, though harder to do - but how many machines are running spyware? The method for getting spyware installed could a) capture your password with a keylogger, and b) capture your cookies, and c) send them to the phisher. By IP won't work as per above. Cookies will also not stop MITM attacks - to do that, you need to verify who the other party really is.
So this is vulnerable to spyware attacks and MITM attacks.
The second password could be clicking on "your" image (or images) instead of 3 questions. Image-selection passwords have been shown to be highly memorable and resistant to dictionary attacks. However, there's still the MITM attack to phish the secondary password (and images) to worry about. That's the problem - you have to verify you're talking to the bank, not to the scammer, even if it's an SSL connection.
Ignore what I said - including at least that sort of image as a link will NOT work due to MITM attacks. However, perhaps there still is a way to leverage this somehow. It's worth thinking about.
As another poster pointed out, the Phisher can (instead of capturing your password) just initiate a MITM attack - create a spoof website that takes your info, passes it to the bank, and shows you what the bank sends you. Unless the bank overlays the apparent IP address (and the user knows if it's correct) of the source, this will work. More hassle, but lets them get all your info, then pass you off to finish your transaction, then they log in to strip your account.
There is a way to deal with this problem too, but I can't go into it at present. (Sorry)
This will work even better for emails - include this button in any emails from the company, or better yet include the actual image. (Including the image itself in the email is a security risk, though smaller and of a different type, but it could be an image in the (ugh) HTML email.)
Combined with some improvements in browsers that are being worked on, this is not bad. Though the answer 3 questions part has problems and isn't in theory any better than a password, it does get around the "I use the same password everywhere" problem.
Trace the network flows for Guild Wars - FAR less traffic goes to/from their servers (I imagine) than in a "normal" MMO game. As someone mentioned, it's closer to Diablo II model when it comes to how it works. That also why you can play it over dialup quite reasonably (especially once the initial patches are downloaded) - try that in most MMOs.
Ummm. Since when are the BTUs in electricity variable? Answer: when you include generation and transmission. 3416 is (about) 100% efficient conversion to heat (which isn't hard). That's the number you used - however, it misses out on a major component: electricity consumed (in BTU) is way less than the BTU burned to supply it.
Generation averages http://www.energetics.com/gridworks/grid.html around 33%. Overall system inputs are a bit over 10,000 BTU http://www.eia.doe.gov/emeu/mecs/mecs94/ei/elec.ht ml to deliver 1 KWHr (3400 BTU) to the user, including generation and transmission. So it's totally unreasonable to assume no overhead, which is what you did by using 3416 BTU/KWHr. If we use the DOE numbers, the electricity use is roughly triple what you show, or around 300,000,000,000 BTU. That doesn't change the overall result (surplus goes down to around 800,000,000,000 BTU).
So, around 2.2 TBTU spent, and net result 3TBTU (positive 700 GBTU). So at best the payback is around 1.3x input.
You also have to add in fuel costs for transport to the refinery, transport to the end-use point (you can't transport it in pipelines), fuel used for planting, fertilizing, spraying, harvesting. Also energy costs for insecticides.
The problem is that while the corn absorbs energy from sunlight, a) Only a small fraction of the biomass generated is converted (the kernels, though they store more concentrated energy than the leaves & stalks) b) Considerable fertilizer and pesticides are required. Producing them requires lots of energy, plus some for transport and applications. c) harvesting and transport requires energy d) Conversion requires energy. e) distribution requires energy - note that fossil fuels require that too.
The numbers I saw were that burning N BTUs of ethanol required N*1.7+ or more BTUs of fossil fuels to be extracted; i.e. you'd use less fossil fuels just to use them directly. So it's more like use 17 kwh of fuel, make 10 kwh of ethanol. Rinse, repeat.
That's why subsidies are required (it's an indirect subsidy to the corn industry for votes and political donations).
Now, if you want to make a go of it, don't use a heavy-fertilizer-based crop like corn. Use micro-algae in very large vats. There was a good article about it in, I think, MIT's tech review. Basically, an area in the southwest roughly the size of a small New England state could supply enough biodiesel for all road transport in the US, at least in theory. Practice may be another thing, but fundamentally it should work much better - algae requires less processing than corn; and the residue makes good fertilizer for the next batch, so energy inputs are low. Transporting it is probably the biggest hit. The water would be recycled largely. No expensive (capital or energywise) harvesting required (just run some pumps). No soil erosion - though you will end up covering a lot of desert or other such areas, which would be an issue, though small compared to the costs of fossil fuels long-term.
This sort of compiler technology goes back to the early days of RISC (MIPS, etc). The compiler has to schedule instructions, manage speculative execution directly, etc.
If you think Itanium is complex, you should see some modern DSPs. 8 functional units/8 instructions per cycle, all sorts of dependencies on cross data paths, etc. Not to mention huge numbers of specialized instructions for working on multiple data (like "add 4 8-bit values to 4 others and saturate the results"). The compilers will not equal a good human, but they do a pretty darn good job.
Like most programmers I tend to over-parenthesize (American spelling). Even worse, I embed one parenthetical remark within another.
An excellent early (ok, old) discussion of "hacker" english is in the Jargon File, aka The New Hacker's Dictionary. In particular, read chapter 5, "Hacker Writing Style". (And note that I follow said style, including aspects such as not pulling punctuation into quotes.)
Slashdot Mirror
They're dumb, but they're not that dumb, and I'm not _that_ bright. One of them would think of those soon enough.
Just like PWNtcha (though that's far worse) - hiding your head in the sand and not publishing these won't stop them from figuring it out - there's money to be made by defeating captcha tests, so there's considerable incentive. And it's not like it's that tough an idea to figure out.
Like I said - make it annoying/painful/expensive enough and it no longer becomes worth their while. Of course, that can make it annoying for all of us too...
Sorry, typing quickly. (And it could be JS code ala AJAX/Google Maps/etc, in theory - might be harder, though, but more compatible.)
It's trivial to hack a browser (hell, you don't even have to actually hack it, just know how it works) to snag the image for you. Then repeat as per grandparent (have a unwitting (or witting) human do it for you).
Next stage: make the captcha Java code that generates the warped image dynamically. Reponse: send the JS to the unwitting human.
Next stage: make the Java code generate the token using something intrinsic to the machine running it (IP, etc, etc). Response: snatch the image from display ram to present to the unwitting human.
Next stage: include in the image information about what the image is for (site, etc). Response: block those parts, or use witting humans who don't care or are otherwise paid (in porn, 3rd-world wages, etc).
You can make it progressively harder, but you can't make it impossible. You might be able to make it hard enough, though.
Those are good suggestions, though ground-source heat pumps can have 5-10 year paybacks - depending on the type and situation and energy costs. Here (SE PA) we pay 14+ cents kWhr (16.5+ if you sign up for all wind power, 6.5 or 9 cents in the winter if you have the "electric heating" rate).
:-) During Jan/Feb, our heating bill (without the 2.5 cent wind surcharge) is around $450/month, even at the 6.5 cent all-electric rate and using our woodstove daily. Outside temps are in the 5-20 at night, and 15-35 in the day generally.
It also depends on how much heat you need. Our old, sprawling, leaky 4100 sq. ft. house with ~80 windows (quite a few of them quite large) has 11.5 tons of heat pumps (5, 2.5 and 4 - 13, 15 and 10 SEER). (We've greatly improved the sealing, and added some insulation including to a sunroom which had no insulation (not even an airspace) in the ceiling - now it's ~R20 of high-density foam board). As for $75/month - I'd kill for that.
You also have to try to predict future energy prices. They may not be as stable as today... You can also get considerably reduced costs for heating domestic hot water, especially in the summer, and hot water is often 30% of a family's yearly energy bill.
That said, installation and equipment cost is the primary issue. You need around 80-100' of borehole per ton in this area, and I think drillers charge around $7/ft or more. (This is for a standard water-coupled closed-loop pump.) Plus you have to trench to the house. Direct Exchange heatpumps (no water involved; working gas/fluid goes directly into smaller pipes in the ground) is more efficient and less moving parts, though it's a newer technology. However, it's harder to find an installer, and they may charge more, especially if they have to come a distance or they're overbooked.
In our case, after looking at it a lot, we decided it was just not worth it (yet) - payback was at best 7-10+ years, maybe more. We went with good 2-stage air-source units and put in a high-efficiency non-cat woodstove to supplement during the coldest months.
As stated in comments to other replies to this message, ground source heat pumps work fine even into the far north. Even air-source heat pumps (with appropriate auxilliaries) are efficient into the northern tier of states. And natural gas is no longer cheap.
Geothermal cost comparisons: http://tristate.apogee.net/geo/minneap.asp
(NOTE: those are based on 6/ kWh; 60/ ccf gas; $1.00/gal oil). In most places, it's 8-10 cents/kWh, well over $1/ccf, and $1/gal oil? Ha! Try $2-2.50 at least. Even at the prices they list, in MN (not exactly a warm place), air-source is on a par with oil and better than propane, though behind natural gas. Ground-source beats them all be a significant margin; if you update the figures for current fuel/electric prices, even air-source heatpumps probably beat natural gas, and ground source beats oil by a 2x factor (circa $1000-1500/year), and beats natural gas probably by at least $500-800, maybe more.
A good energy costs calculator (for relative costs):
http://www.hearth.com/articles/47_0_1_0_M7.html. Note: for heat pumps, use electric and put in an efficiency value of around 250. That will be a pessimistic guess for year-round efficiency unless you live very far north; year-round average is probably more like 275, perhaps 300 in middle to southern states. Ground-source heatpumps - use a value of 350 to 400. And don't forget to update the local costs of different fuels and efficiencies for furnaces!
As someone else stated, that's a plain air-source heat pump in all likelyhood (though even with ground-source, it may be more efficient/cost-effective to not size it for the coldest possible days of the winter, and use an auxilliary to supplement on the coldest 5% of days).
Note that when a heat pump (air or ground source) can't keep up, it still produces a lot of heat, just not as much as the structure loses. The controller then calls for Aux heat, which can be electric (most common), propane/oil/nat.gas boiler via a heat-exchange coil, etc. Or it can be manual (wood stove).
Typical modern air-source heatpumps have an efficiency ratio at 17 degrees of around 2.1-2.5 - i.e., they produce 210 to 250% of the heat you'd get by running the same electricity into a resistive heater (100% efficient). They're usually over 300% (even 350%) at 45 degrees.
Ground-source heatpumps are more efficient because the source is a fairly constant 45-60 degrees, depending on where you live. In the mid-atlantic, 50-55 is the norm. New Hampshire is around 45-50. Texas is probably 60-65. (Bush has a ground-source heatpump (for cooling)). Thus in heating mode, they run at 300-400% efficiency regardless of outside temps (minus some pumping/etc losses). In cooling mode, they're also more efficient since they're dumping heat into a 45-60 degree heat sink, instead of trying to dump it into 90+ degree outside air. They also usually last longer (20-25+ years, as opposed to circa 13-15 for air conditioners and air-source heatpumps) since they're not exposed to the elements. Downside: considerably higher installation costs for trenching or drilling; hard to find local installers (this may change).
We have 3 heat pumps (air-source, 2 dual-speed) with electric auxilliary (3 sections of the house with no way to duct between them). When outside temps get below 20-25ish, the aux's will occasionally turn on. We run a wood stove pretty much all winter, especially when it's very cold. With a small woodstove in the main section, it rarely if ever calls for aux if the outside temp is above 10, and not often when it's below 10.
It varies, a lot, in the US. In urban and suburban areas, it's generally cheap and available.
These are minimums; higher bandwidths are generally available:
DSL is generally $35ish/month which is now ~1.5Mbps down, 256-384K up (this has gone up a bunch in the last year or two from 768 down, 128 up).
Cable is generally 1.5-6 Mbps down, 150-384K up (Comcast, the largest by far, is switching to all 6 down, 384 up or better, or about that). Price is a little higher, circa $45/month. In the last 2 years, it was from 1.5-2Mbps/150-256K. They're starting to offer VoIP.
Verizon and SBC are rolling out fiber to the premises or curb. Verizon is 5Mbps down, 2Mbps up, for $35. They justify it by providing phone over fiber (not necessarily VoIP though), and are starting to roll out video to fully compete with the cable companies.
The main reason for low prices for broadband is competition - DSL and cable are very competitive, and that brings prices down and encourages them to compete on bandwidth/features.
In rural areas, sometimes DSL or cable is available (often lower speeds due to distance for DSL), or dialup. When on vacation in the mountains (but only 1.5 hours from two major urban areas), we used dialup for $20/month, but it's often available cheaper.
CALEA doesn't work that way, and won't for VoIP.
:-(
There's a reason they say "interconnected" VoIP providers - those are ones that interconnect to the PSTN. Pure IP-to-IP isn't covered, at least by that portion of the ruling. Interconnected providers have all the data going through PSTN lines on the destination end, so you can make an argument that those calls are subject to tapping and CALEA anyways.
Now, the way they phrased things about "facilities-based broadband internet access service suppliers and VoIP providers that offer services permitting users to receive calls from, and place calls to, the public switched telephone network" is open to interpretation - it depends on how the 'and' is parsed, and of course this isn't the actual rule, but the press release about the rule. If it only applies to calls to and from PSTN gateways, and then only on the companies offering such gateway service, it has far less impact on general internet access. Of course, that's a big 'if'.
VoIP gateway providers like Level 3 (used extensively by Vonage) provide CALEA processing, and have always expected to be included under CALEA (aka "lawful intercept"). Typically it would only occur at the same point where PSTN interface occurs (since the traffic is there anyways). There are I believe two types of intercept - "trap and trace" (aka who called who, but not the traffic), and a full capture of any calls. Also, since this is going through a voice gateway, it's effectively a MITM attack as far as any encryption is concerned - if there is encryption to the gateway (and I don't think any support it currently anyways), they can record after decryption for conversion to PSTN/SS7.
This is also why they're not expanding it to IP to IP calls - yet. The VoIP providers have no easy way to intercept those calls without giving away that it's being monitored (i.e. the IP address of the destination would be different). The exception for IP to IP calls would be calls that go through a TURN server, border controller, or other provider-controlled RTP relay.
My assumption is that once IP to IP calls start to increase in number, and additional technical solutions are available, they would expand it to those as best they can. It's very tough to do if no provider/service is involved, though - direct SIP calls with no server, for example. (Of course, allowing direct SIP opens you up to SPIM (SIP spam calls) in theory). That would provide the justification to allow trapping all traffic to/from an internet user - which they can do now with things like carnivore, but not as easily as if the internet provider would provide the packet-record mechanism under CALEA. And the next step to note is that trapping the packets of an IP to IP call won't help if they're encrypted, so they'd want back-doors to devices with encryption capabilities, and/or get the ISP to help them provide a MITM attack. Or outlaw encrypted calls ("when encryption is outlawed, only outlaws will have encryption" - from a button I've owned for 20 years). Or make it a crime not to provide keys on request (ala proposals in britain).
Fun.
The base problem is that the journalist needs to know their source and communicate with them, and perhaps let an editor know the source's name as well, but they need to do so without leaving a record trail that would allow someone else trying to track down the source to figure it out.
We can mostly leave the "how do you prove who it is that is leaking" up to the leaker and the reporter. The problem is the untracable after-the-fact communications channel (and preferably hard to intercept as a general case, so wiretaps aren't effective).
Communications channels:
1) Personal contact. There is the issue of how do you know to make contact in person, but that's handlable. Biggest danger here is the increasing number of random video cameras that might be reviewed afterwards to figure out who met with Reporter X. Easiest if there are other reasons they'd meet anyways.
2) snail mail. Easily destroyed after reception. Generally impossible to track after-the-fact - at most the date and rough location of the source. Vulnerable to interception if that's set up ahead of time, but generally requires real court acquiesence (modulo Patriot Act). Mail drops can be used, or sent via friends/neighbors/etc.
3) Regular/cell phone calls. Lots of records; easy to trace after-the-fact. Simplest way to avoid tracing: use public phones (becoming rare). Use a phone not likely to be suspected of being the destination (call the reporter when they're visiting a friend/neighbor/family member). May be tracable if they check records of outgoing calls from someone suspected.
4) voip, especially point-to-point SIP. Not generally tracable after-the-fact; if a sniffer has been installed it can generally be traced unless routing games are played.
5) email from/to "free" email accounts. Similar to voip - hard to trace after-the-fact, though easier than voip - records may be kept on the email supplier, and computers may indicate what ID's to check. Best done from a public-access PC (libraries); in that case it's very hard to find after-the-fact unless the general vector is exposed in some manner - and it may be. Still may be hard to trace.
6) Prepaid cell phones - but only if they can't easily be traced to either party. Even then, traffic analysis could rat you out - they get records from the cell company about all calls in a cell that includes where the reporter lives or works, and sort through them - especially if they know approximately when and where the reporter was called.
etc.
There are I'm sure lots of posts about how to in a hidden way do web/etc stuff. That's not really the point.
The big issue is that the reporter has to be cognizant that ANYTHING tracable may give away the source. Phone records and email of course, but knowing when data was transferred, knowing too much about what data was given, doing web searches based on the data received, etc. If they really want to maintain anonymity of their sources, they need to be very careful. Verbal discussion with editors of identities only. Never call them or be called. Never write down their name or anything else identifiable, or if you do destroy it (well).
Now, this level of paranoia may only be needed for "big stakes" anonymous sources. If it's over someone on city council taking a kickback, only a modicum of anonymizing may be needed (though avoiding written/electronic records is still a really good idea).
That's not an unlikely 'unless.' Exchanging public keys (or fingerprints, I should say) would be quite easy unless you are initiating a call with a complete stranger. Even if you haven't had a chance to swap details with your partner beforehand, you can always begin the conversation with "my fingerprint is ..."
Telephones are often used for calling strangers. Also, this basically devolves to the original PGPhone security model - unless you have an out-of-band secure channel for exchanging certs, you can't easily avoid MITM attacks, except by a PGPhone-like "read off some words that authenticate the session key" trick. And who will do that at the start of every call? And that assumes the certs are visible and easily read off/verified, which normally they're not.
As for SSL tunnels, as I said, it depends on trusting Verisign (or whomever) to authenticate the other side. From the Diffie-Hellman wiki page you pointed to:
As for encrypting POTS calls: take audio. digitize. Encrypt*. Translate back to audio (modem chipsets are fine). Send. At the other end, do the reverse. The issue is encryption and keys and key exchange, of course. My friends were using some fancy method to provide a pseudo-OTP and avoid having to do serious encryption in HW/SW in realtime (this was ~1983, remember). Never went anywhere, and some of them got paranoid after the "business" guy (perpetual student/MBA type) met with eastern european officials. MUCH easier to do today. Back then, even the modem chips I suggested would have been a stretch for doing full audio - 2400 baud was good back then.As for CALEA, I suspect Skype does it for SkypeOut (or will, or rather their partners do/will). Regular Skype - perhaps not, but you have to trust them...
VPN and VoIP: BAD
If it's a TCP tunnel, you add really bad delay and jitter in response to packet loss.
If it keeps UDP as a form of UDP (IPSEC might do this), you only lose the QOS flags plus any VPN-related delay (which may be non-trivial, or may be no worse than direct SRTP encryption).
As you imply, though, anonymous (no working PKI infrastructure (that you can trust)) DH will NOT protect you from MITM attacks. As others have mentioned, security agencies certainly can MITM you (hell, they can just tell Comcast or Verizon to give you DHCP pointing your DNS servers to ones they control). So can organized crime (read the post about 3rd-world hotels (Phillipines) where they will use captive DNS servers to direct you to sophisticated phishing sites). Etc.
Not to say that anonymous DH w/ SRTP isn't worlds better than in-the-clear RTP, modulo call setup time.
a) they can trivially break your VoIP security if they do a MITM attack, unless you have a functioning PKI (that you can verify), or you trust a central authority (and can you?) Yes, you exchange keys with them, but who is "them"? The original Zimmerman PGPhone used user-read english words to verify that the keys used for the session were the keys each side thought were in use, thus in theory detecting MITM attacks. That's not directly part of any modern VoIP security. Check the cert/keying stuff for SIP used to choose keys for SRTP. To do it securely at all, you need a functioning PKI or a TLS connection to the SIP server - and you need to trust that TLS connection and that SIP server.
Ditto for SSL - you accept the certificate because it's signed by Verisign and it says they are who they say they are. In theory, you can examine it and verify if out-of-band, but no one does. I'd be shocked if the NSA didn't have the ability to "sign" certs as Verisign and so institute a MITM attack on someone thinking an SSL connection is sacrosanct.
b) You can encrypt audio in POTS phone calls. The HW for it isn't trivially available, but it's certainly doable. I had friends who made virtually uncrackable digital audio telephone scramblers back in 1983ish at RPI, and tried to start a company to sell them.
c) CALEA - the VoIP provider is being required to allow tapping of calls. Currently that's targetting calls that go through their equipment aka POTS gateways.
I finally got rid of the 5 Sun-2's in my basement when I moved a couple of years ago (less basement space in the new, bigger house). These were used to develop the AmigaOS back in the mid to late 80's (before we moved all the modules to native compilation). Along with them went the PDP 11/64. I kept the SunOS tapes, though.
Moments: getting my 2MB huge Zorro-I expansion card for my Amiga 1000, and figuring out how to do all my work from (recoverable across crashes) ramdisk. Playing Faery Tale Adventure. Playing Mule on a C64 with the homeless druggie friend of a roommate in college. Running the weird hypnotic graphics demo that came on one of the Amiga 1000 disks during parties and seeing people get stuck watching it.
Playing Netrek on the 'net on a league team (the Buddies) back in circa 1990.
One measurement I found was 2.2MB over 2 hours; average about 4.8 Kbps. I've read other estimates of 1-2Kbps. Probably depends a lot on what you're doing, how over you switch areas, how much time you spend in towns (lots of people running around and talking), adventuring with humans or hirelings, etc. Running around the wilderness with hirelings might use almost no BW.
Of course, in a player party, the PC's may be communicating largely directly with each other instead of via the server (so it doesn't use _their_ bandwidth). Haven't Ethereal'd it to see yet.
Is "safe machine" by IP or cookie? Cookie I'll bet, since dialup, some DSL (and occasionally cable) IP's change often.
If it's by cookie, it's stealable, though harder to do - but how many machines are running spyware? The method for getting spyware installed could a) capture your password with a keylogger, and b) capture your cookies, and c) send them to the phisher. By IP won't work as per above. Cookies will also not stop MITM attacks - to do that, you need to verify who the other party really is.
So this is vulnerable to spyware attacks and MITM attacks.
The second password could be clicking on "your" image (or images) instead of 3 questions. Image-selection passwords have been shown to be highly memorable and resistant to dictionary attacks. However, there's still the MITM attack to phish the secondary password (and images) to worry about. That's the problem - you have to verify you're talking to the bank, not to the scammer, even if it's an SSL connection.
Ignore what I said - including at least that sort of image as a link will NOT work due to MITM attacks. However, perhaps there still is a way to leverage this somehow. It's worth thinking about.
As another poster pointed out, the Phisher can (instead of capturing your password) just initiate a MITM attack - create a spoof website that takes your info, passes it to the bank, and shows you what the bank sends you. Unless the bank overlays the apparent IP address (and the user knows if it's correct) of the source, this will work. More hassle, but lets them get all your info, then pass you off to finish your transaction, then they log in to strip your account.
There is a way to deal with this problem too, but I can't go into it at present. (Sorry)
This will work even better for emails - include this button in any emails from the company, or better yet include the actual image. (Including the image itself in the email is a security risk, though smaller and of a different type, but it could be an image in the (ugh) HTML email.)
Combined with some improvements in browsers that are being worked on, this is not bad. Though the answer 3 questions part has problems and isn't in theory any better than a password, it does get around the "I use the same password everywhere" problem.
Trace the network flows for Guild Wars - FAR less traffic goes to/from their servers (I imagine) than in a "normal" MMO game. As someone mentioned, it's closer to Diablo II model when it comes to how it works. That also why you can play it over dialup quite reasonably (especially once the initial patches are downloaded) - try that in most MMOs.
Ummm. Since when are the BTUs in electricity variable? Answer: when you include generation and transmission. 3416 is (about) 100% efficient conversion to heat (which isn't hard). That's the number you used - however, it misses out on a major component: electricity consumed (in BTU) is way less than the BTU burned to supply it.
t ml to deliver 1 KWHr (3400 BTU) to the user, including generation and transmission. So it's totally unreasonable to assume no overhead, which is what you did by using 3416 BTU/KWHr. If we use the DOE numbers, the electricity use is roughly triple what you show, or around 300,000,000,000 BTU. That doesn't change the overall result (surplus goes down to around 800,000,000,000 BTU).
Generation averages http://www.energetics.com/gridworks/grid.html around 33%. Overall system inputs are a bit over 10,000 BTU http://www.eia.doe.gov/emeu/mecs/mecs94/ei/elec.h
So, around 2.2 TBTU spent, and net result 3TBTU (positive 700 GBTU). So at best the payback is around 1.3x input.
You also have to add in fuel costs for transport to the refinery, transport to the end-use point (you can't transport it in pipelines), fuel used for planting, fertilizing, spraying, harvesting. Also energy costs for insecticides.
A good (and balanced) overview is http://www.rppi.org/ps315.pdf
The problem is that while the corn absorbs energy from sunlight,
a) Only a small fraction of the biomass generated is converted (the kernels, though they store more concentrated energy than the leaves & stalks)
b) Considerable fertilizer and pesticides are required. Producing them requires lots of energy, plus some for transport and applications.
c) harvesting and transport requires energy
d) Conversion requires energy.
e) distribution requires energy - note that fossil fuels require that too.
The numbers I saw were that burning N BTUs of ethanol required N*1.7+ or more BTUs of fossil fuels to be extracted; i.e. you'd use less fossil fuels just to use them directly. So it's more like use 17 kwh of fuel, make 10 kwh of ethanol. Rinse, repeat.
That's why subsidies are required (it's an indirect subsidy to the corn industry for votes and political donations).
Now, if you want to make a go of it, don't use a heavy-fertilizer-based crop like corn. Use micro-algae in very large vats. There was a good article about it in, I think, MIT's tech review. Basically, an area in the southwest roughly the size of a small New England state could supply enough biodiesel for all road transport in the US, at least in theory. Practice may be another thing, but fundamentally it should work much better - algae requires less processing than corn; and the residue makes good fertilizer for the next batch, so energy inputs are low. Transporting it is probably the biggest hit. The water would be recycled largely. No expensive (capital or energywise) harvesting required (just run some pumps). No soil erosion - though you will end up covering a lot of desert or other such areas, which would be an issue, though small compared to the costs of fossil fuels long-term.
This sort of compiler technology goes back to the early days of RISC (MIPS, etc). The compiler has to schedule instructions, manage speculative execution directly, etc.
If you think Itanium is complex, you should see some modern DSPs. 8 functional units/8 instructions per cycle, all sorts of dependencies on cross data paths, etc. Not to mention huge numbers of specialized instructions for working on multiple data (like "add 4 8-bit values to 4 others and saturate the results"). The compilers will not equal a good human, but they do a pretty darn good job.
An excellent early (ok, old) discussion of "hacker" english is in the Jargon File, aka The New Hacker's Dictionary. In particular, read chapter 5, "Hacker Writing Style". (And note that I follow said style, including aspects such as not pulling punctuation into quotes.)