Are you sure about this? Would it in fact be possible to gain access to all past stored emails by logging a future user session? Or was it only possible to gain access to future emails by recording a copy of the incoming plaintext before encrypting them with the user's public key? This is an honest question; I hadn't even heard of Lavabit until today (I would have been a customer if I had) so I only know what I've read. Even before today, the past several months have proved what we've all long suspected: a security model that requires the users to trust a commercial service provider is simply not workable. Even (especially) in the United States. Ideally, a security model shouldn't require you to trust anyone in the middle at all. If that's not possible (and for many services, it's not) it should rely on a large volunteer group, at least some of whom are honest. Something like TOR, though it has its own problems.

I think you have it basically right. As I understand Lavabit, they encrypted incoming email with a public key for which only the user had the private key. They could not provide plaintext of existing email to a government demand. So the government probably ordered them to keep plaintext copies of all future email, which would be technically possible. The only way to avoid it was to shut down the service altogether. There'd be no reason to shut down the service if the demand was only for existing data as that would not relieve them of the requirement to fork it over. At the moment their MX server is not accepting incoming SMTP connections, which lends weight to my theory. The government could still seize the domain name and set up their own inbound SMTP server, but hopefully the publicity has warned everyone away. Right now there are two MX records for lavabit.com: mx.lavabit.com and lavabit.com, both of which resolve to IPv4 address 72.249.41.52. imap.lavabit.com also resolves to the same IPv4 address. Let's see if those records change...

Did you actually determine those figures for yourself, or are you just repeating NRA propaganda or stuff everybody "just knows"?

The idea of selling EV battery energy back to the grid is silly given the high depreciation costs of current EV batteries, but a closely related idea makes a lot of sense: allowing the grid operators to control the power level of EV chargers in exchange for lower rates. Even during the day there's almost always unused generation that's much cheaper than the depreciation cost of EV batteries. Problem is, it takes time to fire up in response to an unexpected load increase. Usually the extra load is temporarily met with quickly dispatched (but more costly) spinning reserves until the more economical generators are online. Temporarily reducing EV charging powers could be an alternative to those expensive reserves, and it only needs to last until the extra generation is online. The temporary power reductions could be rotated among different EV drivers so no one user has his cranked down too often or for long.

Last night I was running Skype on a publicly routable IP address, which probably made my machine a supernode candidate. I noticed a lot of idle traffic between my Skype client and quite a few IP addresses within the Amazon EC2 compute cloud. I'd never seen that before. Usually my background traffic is to random cable and DSL addresses. My guess is that Amazon is where Skype brought up their "extra mega-supernodes". EC2 is handy for things like that.

I'm a big Mac and OSX fan. OSX is a good UNIX system that also makes a good development front end for Linux and BSD. But I have absolutely no interest in developing or even owning an iPhone. First, it doesn't work with CDMA networks like Verizon and Sprint. Second, it's not really your phone if you have to get Apple's permission to run a program on it. People really should avoid locked-down platforms like the iPhone. They're simply not worth it. Buy a small netbook instead.

You're exactly right, Zn-air batteries have been around for a long time. Larger Zn-air batteries have also been under development for some time. So it REALLY bugs me when I see a Slashdot title like this one that's just flat-out wrong. Any battery's theoretical energy/weight ratio is determined by its reactants. Not only do you want a lot of energy from each atom or molecule in the reaction, you also want a high ratio of valence number to atomic weight. The nuclei in the reactants are just dead weight to balance the charge on the electrons that do the work. The ideal reactant would be cheap, nontoxic, easy to handle and electrically conductive. Nothing fits them all so you have to compromise. Good battery fuels are easier to find than good battery oxidizers. You can't beat lithium as a fuel if you want a metal at standard temperature and pressure. The oxidizer is the big problem. In current use are MnO2, LnxCoO2, LiFePO4, AgO, PbO2, NiOOH, SO2, SOCl2, SO2Cl2, FeS, CF(n), HgO, S and lots and lots of others. They're all heavy, expensive, toxic, and/or non-conductive. So using O2 from the air as an oxidizer is a really big win if you can do it. Zinc-air batteries and automotive fuel cells already do this. (Fuel cells for space use have to carry both H2 and O2.) So it seems to me that if you can make a rechargeable battery with Li as the fuel and atmospheric O2 as the oxidizer, you'd really have something.

So this asks the obvious question: is Skype still secure?

Obviously it can be broken by planting malware in the target's computer, but what are the other ways? Last we heard, independent reviews of the crypto protocols said they were pretty good.

But I am quite sure there are exploitable weaknesses in the login server and protocol. Skype operates that server, so we can assume that it either is or soon will be compromised.

Consider the following simple observations. I can install Skype on another computer, sign in with my existing user name and password, and talk to any of my existing contacts without any of them noticing anything unusual. I transferred nothing from my old installation, so my new installation cannot have any of its existing secrets. It knows only one long term secret: my account password, and I use that only to authenticate myself to the Skype login server.

Furthermore, unlike most IM programs, I can sign in from multiple computers and switch between them during chat sessions. All will get copies of all that is said.

This seems to demonstrate quite clearly that with the cooperation of the operator of the Skype login server, you can impersonate any Skype user and conduct either a man-in-the-middle attack or a conferencing attack.

The weakness here is that you're relying on the login server to authenticate your correspondents instead of doing it yourself on an end-to-end basis. Without authentication, encryption is meaningless.

You could probably add packet-level authentication mechanisms to Skype traffic to protect against this attack, but if you're going that far you might as well use something completely different that you can fully trust.