One of the world’s greater mysteries, as far as I’m concerned. Also, what’s up with caffeine-free diet Mountain Dew? Might as well just drink antifreeze. The color’s right, and it probably tastes better...

You’d be surprised how low-cal turds are... Mostly indigestible (at least to us) fiber, metabolic wastes, and deceased intestinal fauna.

The human body is shockingly good at absorbing every possible calorie it can from food. I’ve seen 90% efficiency thrown around online, but alas I can’t find any sources worth citing.

Your body absorbs and uses what it has until it has what it needs, and it converts the rest to glycogen and/or fat to use when it needs it later. Problem is “later” never comes when you have a constant supply of food and eat more than your immediate needs on a regular basis.

Your stated relationship is true, but there are indeed other factors involved. The ‘kcal out’ term is influenced by the makeup of the ‘kcal in’ term, so it’s not quite that simple. Your BMR will change based on what you eat, not just how much you eat.

Keep carb intake low enough to stay in ketosis, and your BMR increases 700-ish kcal/day. Drop protein intake too low, and your body starts shutting down non-essential processes to conserve protein & energy causing BMR to decrease.

Both of those effects can result in the inequality between ‘kcal in’ & ‘kcal out' shifting, even as 'kcal in' and activity are constant.

Explain how living across the street from tract housing increases property value versus living across the street from a corn field? It most certainly doesn’t according to my wallet.

I’ll take farm land over McMansions any day, thanks.

You just get out of the corner with that goat. And pull yer pants back up, dammit!

This is essentially what Lavabit implemented. The NSA’s response was to compel Lavabit to hand over their SSL private keys so that all traffic to & from their web server could be intercepted. The key material that protects the private key must at some point pass over the wire, and if you can decrypt all traffic in & out, you can compromise the system.

Lavabit chose to go out of business rather than comply.

Land of the Free indeed...

You’re thinking Web of Trust type public key architecture like PGP/GPG tend to use. That’s a good model among people who know each other well and trust each other (as well as trust each other’s ability to verify keys properly), but it doesn’t scale all that well. It also requires users to do much more work to distribute and verify keys.

iMessage uses a certificate authority model. You delegate all trust to the third party authority (Apple in this case) who you trust to do the work of verifying that keys belong to whom they claim to. Instead of restricting your keys to a list of trusted friends you’ve manually verified, you trust that any key which Apple has signed and provided to you (and hasn’t revoked) was originally provided to Apple by someone who had the user’s iCloud password. It’s a big step up in terms of usability since you don’t need to do the key exchange dance with every person you want to iMessage, but there are significant trade-offs in terms of security.

On the whole (and LEO meddling notwithstanding), Apple’s system does a reasonable job in its role as a CA. You need a user’s iCloud password to provide new keys to the system. As an unfortunate number of famous people recently discovered, relying on password authentication has some limitations, but it’s the best option widely available right now. In any case, the security is reasonably in the user’s hands (again, ignoring LEO for the moment) — you can choose to use long, complex passwords, and Apple will do the RightThing(tm) with them.

The vulnerability in relying on a certificate authority is that they are much more susceptible to coercion by other parties (IE law enforcement). In a Web of Trust model, someone would need to directly compel someone you trust to either turn over their private keys or furnish you with compromised keys that they claim to be safe to use. That must be done on a per-user basis, so requires much more work for LEO to surveil any large number of users. On the other hand, Web of Trust is more susceptible to non-LEO blackmail scenarios. To coin a movie plot, “Here’s a photo of your daughter’s school. Provide this key to all of your trusted confidantes if you want her to get home safe.”

With a certificate authority system, the CA likely has less skin in the game in terms of the security *your* particular messages, and also has significant legal exposure in terms of assets and criminal sanctions. There’s also no possible claim of 5th Amendment protection. The CA can be compelled to produce vulnerable certificates that will appear to come from the surveillance target. They can (technically) do this for a single user or provide the root signing keys allowing LEO to directly produce such certificates without additional involvement from Apple. They can also be legally gagged to prevent them from disclosing this has happened.

The strength in the iMessage implementation is that each iMessage client should be furnished with a complete list of the recipient’s keys and that Apple can’t decrypt messages with the key material it should normally have. That falls apart when Apple is compelled to generate MitM keys for LEO, but there are technical avenues available for detecting that in most cases (unanticipated key change). Those checks essentially degrade back to a Web of Trust model where users must manually authenticate keys with the owner. Most users aren’t savvy enough to perform these checks, and the iMessage infrastructure on iOS devices makes it impossible to do this in-situ without jailbreaking the device. It should be possible to write something that would impersonate an iMessage client and perform the check, but of course if Apple detected the impersonated client, they could provide a different set of certs to that client, defeating the ability to check them.

All told, iMessage is much better than other options available. By design, Apple cannot decrypt messages at rest on their servers. They can be compelled legally to take steps to enable that decryption for new messages, but there is no mechanism for them to decrypt messages already transmitted nor to perform wide-scale interception in an undetectable fashion. The encryption is enabled for ALL users by default, which makes dragnet blanket surveillance impossible for iMessage. That’s a BIG win to me. By contrast, email or SMS are both almost certainly captured 100% by NSA at this point and mined for anything interesting.

Now, that’s not to say that Apple hasn’t been compelled to MitM the thing from the start. The one protection here is that you can compare the keys that Apple sends to you with those stored on the sender’s iDevice. The post I linked to above has taken steps to implement that. Unless iOS is actively backdoored to send off the iMessage private keys (possible, but not seen in the wild at this point), then any attempt to read iMessages in transit would require an MitM’d key that would be verifiably different than the public key on the sender’s device.

There isn’t anything we’ve previously seen that NSA/FBI could use to legally (as opposed to spookily) compel Tim Cook to LIE in asserting that Apple can’t decrypt messages at this time. They could compel him not to admit that Apple *could* decrypt them, but not force him to say that they can’t. It’s a subtle distinction, but there’s normal-legal precedent for gagging someone from saying something, but it would take extra-legal activity to force someone to actively say something that they didn’t want to. Courts can force you to shut up, but they can’t force you to lie for them. Honestly, I think all bets are off in the USSA right now in that regard, but if Apple were being forced to lie and say that iCloud is secure, it would be a new low for us.

iMessage is a good background-level security stance. If you really need to communicate privately with another individual, GPG & Web of Trust is still the most secure option.

I’m not sure (stationary) magnets are a large concern.

A friend of mine in high school had an on-going sibling ... disagreement? with his older brother. At one point, he took to storing a 12” speaker (just the bare speaker, no cabinet) magnetically stuck to the side of his brother’s computer case, right where the hard drive sat spinning all day long. He’d sneak in, remove the magnet before his brother got home, put it back when he was gone. That went on for months with no data loss.

Compare the rated interior temperatures of any fire safe you might buy with the maximum storage temperature of any drives, tape, discs, etc. you might plan to use.

Any decent fire safe will keep your important papers below 451F, but a quick googling of “max hard drive storage temperature” suggests that’s a good 300 degrees above “safe” for drives. I suspect tape will melt or demagnetize a good bit below where paper burns as well.

If you’ve gone to the trouble of making a second offline copy, store it someplace other than your basement. Relative or friend’s house? Locked box in your desk at work? Plenty of safer options

But what about my precious copy of the Ewoks Christmas?????

Article subject says, “email,” but TFS says, “iMessages.” Those are different things, and the security of them is handled very differently because the mechanism of access is very different.

Apple being unable to access emails is impossible since they must deliver them in plain text to plain-old IMAP clients that don’t support decryption or key storage.

Apple being unable to access iMessage contents is plausible. My understanding of the protocol is something like this:

Alice starts texting Bob’s phone number. Alice’s iDevice contacts Apple’s servers to see if Bob’s phone number is registered with iMessage. If not, Alice’s device sends a plain-old SMS. If it is, Alice’s device receives a list of public keys for each of Bob’s registered iDevices. Alice’s iDevice encrypts the message with a session key, then encrypts that session key to each of Bob’s public keys. Her device transmits the encrypted message to Apple’s servers which then transmit it to each of Bob’s devices as they become accessible. Each of Bob’s registered devices can use its private key to decrypt one of the encrypted session key blocks, then use that to decrypt the message.

The private key to decrypt session keys never leaves Bob’s device. The session key never travels in the clear outside Alice’s or Bob’s devices. Apple can retrieve sender/recipient info (ye olde metadata), but no message contents.

The one gotcha to all of that is that since Apple controls all SSL certs involved in the process, they could MitM attack the process if they so-choose (or were so-ordered). There’s no certificate pinning or checking implemented, so Alice’s iDevice has no way of knowing if the public keys it retrieved for Bob’s iDevices might also include an extra key held by Apple or LEO.

Assuming Apple is compelled to intercept messages from Alice starting at a particular date, messages sent before that date at rest on their server should remain secure (unless they’re lying and are currently MitM or escrowing keys). New messages sent while the MitM was active could be decrypted and provided to LEO. Whether or not they’re performing an MitM at present should be detectable by analyzing the traffic during new device registration or sending messages — IE if Alice checks the keys received and confirms them all with Bob manually (jailbreak most likely required). If they don’t match or there’s an extra key, something’s wrong.

There’s an in-depth protocol analysis of iMessage here: http://blog.quarkslab.com/imes...

Scroll to the bottom for the tl;dr on that analysis. That post also includes proof of concept software to check for an active MitM attack, at least on iMessage for Mac.

tl;dr: Apple is in a trusted position where they could intercept message on a per-user basis if compelled to do so, but the general case of iMessage working as intended leaves messages encrypted on their server with keys they don’t have. I’m not aware of any way that Apple could perform that attack in an undetectable fashion, though performing that detection is well beyond the ability of most users.

For cloud-based storage I care about viability. If they go out of business and take my one cloudy copy with then, I’m screwed.

For cloud-based backup, that’s a different story. If they go out of business, I only care if it happens to occur in the timeframe that my own local copy is damaged. It’s certainly in the realm of possibility that would happen, but I’m okay with those odds given the price Backblaze, Crashplan, and others are currently charging. If it should happen that they go bust, I’ll have to find another solution. In the mean time, it’s reasonably priced insurance, especially when compared to the cost of backing up to tape, buying (and admin’ing) an off-site server, etc.

If they’re profitable or not is between them and their investors. Having read how Backblaze goes about sourcing disks and constructing their storage pods, I’d definitely say they have profitability in mind. I hope they make a good run of it, but if not, there’s a decent chance that my local storage will be and remain intact long enough to find another solution, be it one of their competitors, a bunch of local disks, or, “Hey Mom? Do you mind if I stick this loud, hot, power guzzling thing in your basement?”

Perfect forever backups would be nice, but I haven’t got that kind of IT budget at home. Compromises will have to be made, and I think the cloud-based options are a pretty good bargain right now.

ZFS on Gentoo does not automatically update pool or filesystem versions after a ZFS driver update.

I suspect this is also true of the vast majority of distros, but there’s one example for you anyway.

Inability to import after a damaged/missing ZIL is an old problem of ZoL (and ZFS in general) that’s (long) since been fixed. ZFS on-disk version 19 and newer support removal of a faulted / missing secondary log device. ZFSv19 was released in OpenSolaris b125 (sometime in 2009 - can’t pin down an exact date). I can’t find an easy reference of ZoL versions versus their supported ZFS versions, but the earliest release on the zfsonlinux.org home page (0.6.1 released 27-MAR-2013) supports SLOG removal.

It takes some debugging steps, but it’s doable without loss of a pool where missing ZIL was the only problem. Additional problems may of course prevent import, but if the ZIL is your only issue, it’s recoverable with current ZoL. Likewise for missing L2ARC devices.

As you mentioned you run the risk of losing data that was “guaranteed” written but only in the ZIL at the time the system lost power or crashed. If the pool was exported cleanly, there would be no uncommitted data in the ZIL, so this would only be a possibility after power loss or system crash.

ZFS on BSD, then Linux (same hardware, new OS) since about 2008. 19TB raw, about 14TB w/ RAID taken into account. Not using ECC since day one.

Nothing catastrophic has happened, and any issues with repairs made during ZFS scrubs have eventually proven to be failing drives, flaky cables, or cheap/lousy SATA backplanes. IE replacement of offending hardware caused rare intermittent CRC errors to cease completely (until the next non-RAM thing started acting up). Even with those errors, zero dataloss over the time frame.

ECC’s a nice feap, but your data won’t catch fire without it.