This is not the fault of the currency. It is a fault of the exchange provider and the users of the currency really need to be careful in who they put their trust.
I'm sorry but noone without a great deal of development experience should be writing a Bitcoin exchange or any other type of financial exchange exposed to the internet. The attackers got hold of the unencrypted wallet? Why would an exchange wallet ever be unencrypted? Why is there a single wallet in the first place? Why not have seperate wallets per user account encrypted with their own passphrase such that the site operator doesn't even have access? Maybe a master password override to decrypt but never stored online etc.
Why is the wallet stored on the webserver in the first place? Why aren't funds transfered to offline storage on a regular basis? I could go on.

I am not sure how it works in the US, but here in Canada when a celco changes its terms, it allows the end user to cancel his contract without an ECF. That is, unless the celco agrees to honour the terms of the original contract as signed for its duration. So assuming the 2 year contract also says something to the effect of user agrees with the privacy policy, I would argue that makes the privacy policy part of the contract and is thus grounds for cancelation. Thoughts?

I use the Netgear WNDR3700 which works quite well with OpenWRT. Having said that, really slashdot? Slow day?

Bitcoin currently has no passwords. If you get their wallet.dat, it's all over.

With the recent MTGox compromise, I've been looking at a better password system. It looks like one way to go is to use a program like password safe or keesafe to generate unique passwords per website. However, I'm curious as to how resistant these master files are to GPU attacks. GPUs basically sliced through the MTGox MD5 hashes like butter. How long would it take a higher-end distributed cluster to break a Password Safe master file? It's blowfish encrypted I believe.

I realize this article is coming from a corporate perspective but from a home user's perspective, I am really getting quite a lot from IPV6. I once had to poke holes in my firewall to get at internal machines on nonstandard ports when away from home. Now that they are IPV6 enabled,, I can address them directly. I can also access my Samba shares (ISP port blocking) and the SIP protocol works much better now that NAT is not involved.

The tunneling does add latency though so here's hoping the ISPs get native connectivity soon now.

Actually, DKIM can be used to guarantee a sender. We're using DKIM here with ADSP. That is:
_adsp._domainkey TXT "DKIM=ALL"
tells a receiver that all emails from our domains should be signed. Since the keys themselves are published in our DNS, a machine not under our control should not be able to send an email purporting to be from our domain.

I'm not sure but I would think that mechanism would make SPF irrelavent. Assuming antispam software actually checked the adsp dkim records.

That's the thing I don't understand about the whole Symbian open sourcing and the excitement around it. Unless I am off-base, it's not like a programmer will be able to pick up the Symbian codebase, make a modification, compile a new kernel and flash it into his phone. If that's the level of open-sourcing we're talking about here, disabling 'Symbian Signed' will be trivial. Is this geared more toward device manufacturers? IE. end-users and developers need not care?