Or, you know, just disable roaming. Every phone I've owned in the last four years, and probably the ones before it, had that option...

1) You can raise that cap, or eliminate it.
2) Sure, if you had some kind of magical analog modem capable of ~200Kbps (EDGE speeds).

How is their unlimited data not unlimited? I've broken 10GB/month on it without any problems. Maybe if you try really hard to abuse it they care, but for anything anywhere near normal usage they don't. Mind you, I pay a little extra each month ($20) to have the throttling soft-cap removed entirely, and also to get the tethering cap bumped up (is that what you were referring to?)

Free, though you're throttled. You can get the throttling removed for a rate similar to what other carriers charge for international data packages, and you can add or remove it at need. I spent a month in Europe earlier this year though, and found the free data to be quite sufficient. It was fast enough for Skype (completely avoiding the $0.20/min call rates) and even for most app updates and for music screaming. I also sent/received over 1000 messages, a mix of SMS and even MMS, without being charged anything extra.

T-Mobile US is a great deal.

Or, you know, use a not-shit phone that supports disabling roaming without entering airplane mode. Jeez, what piece of crap doesn't do *that* anymore?

... as opposed to a civilian artillery cannon? :-)

Neat story, though. Some of the places I've traveled (and occasionally written snippets of code in) were hot+humid enough that "dripping with sweat" is accurate, but it was never official working conditions! That sucks, man...

I've done a bit of coding on a slightly larger yacht (45', in the Caribbean and crossing the Pacific) but I think the actually weirdest one was something I hacked together at around 3970m (13000') in the Khumbu (Everest region) of Nepal, specifically in the village of Khumjung. Nepal has a weird timezone and only some of our digital cameras supported it, so some of our photos were being created with EXIF data that was off by a bit from the others. So I pulled out my seriously-underpowered-and-lightweight-for-the-time laptop and hacked together something to fix the affected photos so they would line up correctly with the rest.

These days there are tools that I could have used to script this, but they either didn't exist or I'd never heard of them back then. It's not like we had Internet access in the guest house (excruciatingly slow satellite links could be used to get email, for way too much money, in a place across the village from where we stayed). In fact, we were lucky to have electricity.

And all of it updates automatically and silently from Google on a regular basis. It's OK though, I'm sure they'd never silently ship a backdoored version to a specific target in compliance with a NSL...

I don't know if a subpoena has enough teeth to compel this level of cooperation, why use one of those anyhow? I'm quite certain the NSA could require that Google silently update your copy of the E2E extension to include a backdoor that steals your secret key, at which point they can decrypt all messages sent to you and put your signature on any outgoing message they want to.

Chrome extensions are tied to your Google account, and Google has pretty much complete control over them. Chrome, as a browser, does not need to be tied to a Google account (although it will suggest that you do so) and its automatic updating can be disabled.

More to the point, though, I can securely send messages even though a compromised browser, if I encrypt the messages externally. As soon as you put your PGP private key into this extension, though, it can read all your mail (even if it's encrypted) and add your signature to anything it wants (where "it" means Google operating under compulsion of an NSL).

The concern isn't so much "The NSA will compromise all Chrome installations and use them as a Trojan to find and compromise secure messages!". It's more like "OK, the NSA says we need to tap MtHuurne@gmail.com; next time his E2E extension checks for updates make sure he gets the backdoored version and let me know when we have his private key, and by the way keep silent about this or your family will never know what happened to you."

As harsh conditions (for non-living things) go, Space isn't bad. There's no corrosion, no erosion, no wind or rain or waves (or windblown debris or acid rain or ocean salt). Temperature stresses are a problem, but all spacecraft, including the shuttle, are designed to accommodate them. Radiation is a problem, especially for the computers, but that's why spacecraft use redundant and hardened electronics. Micrometeorites are a valid concern; you need to make sure that they can either be resisted or their damage can be absorbed safely.

We've had space probes and artificial satellites that remained operational for decades. An unmanned Soyuz capsule is capable of manned re-entry after 6 months (unmanned) in space; why do you think that the same wouldn't be true of the SS?

Hadn't been updated much... but there's a big ongoing audit of the code that already turned up some findings. Nothing major, certainly not enough that I'd say it warrants the kind of warnings currently all over the site, but enough that there really *should* be a newer version to patch them.

Flaws will continue to be discovered, including after the audit. They don't even have to be flaws in TC itself, properly speaking; if somebody finds a major break in some cryptographic primitive (cipher, hash function, etc.) that TC uses, then TC needs to stop using that primitive even if it implemented it correctly (or consider something like DES, which was secure 30 years ago but today can be brute-forced quickly and inexpensively, though none of the current primitives we use should be *that* weak anymore). In any case, if flaws do not get patched as they are discovered, they will accumulate, and sooner or later there will be one that's either too big to accept or some combination of them that makes attacks on the software or its data practical.

The initial report of the audit includes the SHA1 hash of the source archive (for 7.1a) that they built from. That should help...

You know, the last part of your question is actually a pretty good one. With the exception of the "Elephant" diffuser, every part of BitLocker is pretty standard and well documented and/or easy to figure out with a little analysis (doesn't even need disassembly, I suspect). There's no good reason (patents may be *a* reason, but not a good one) why it couldn't be implemented in a FOSS system. In fact, I know Elephant was externally reviewed, so even if it's not patented there's probably people who know how it works too (pretty sure it's optional in any case, though I believe it's enabled by default).

Getting Linux to boot off of a BLed volume would be hard, but just being able to access and mount removable or shared data volumes shouldn't be too hard. You'd need to not be using the TPM key, most likely, but I know that's optional in BL.

7-Zip is FOSS and supports file (well, archive) encryption. It's not a replacement for volume-level encryption, but it's a thing.

GPG still works fine for file encryption too... but again, not for volumes.