Instapaper Server Update
blog.instapaper.com
blog.instapaper.com
In a threat environment this bad, you would personally be scrutinizing sign-in lists every month. You have better things to do, right? Right. Because this is really not Instapaper's threat environment. You got mildly inconvenienced as a side-effect of routine government operations. You can pick whether you want to escalate that to A Full Crisis. That seems like a bad call, which you recognize on the legal side. Do it on the security side, too.
You may think that vocal parties will disagree with "This was a non-event for us.". They might. Screw them. You're a CEO; dealing with paranoid ramblings does not generate business value like two months of normal operations does.
It'd be cool if HDD's/SSD's started compiling rough stats about numbers of reads and writes for this purpose.
He claims that there's nothing that can be done, but there are definitely legal actions one can take in this scenario. Sure, they might not ever fully compensate him, nor convince the skeptics, but it will at least reveal the details behind the seizure, and it will send a message to both the FBI and to others like DigitalOne that could prevent further "seize first and ask questions later" style operations.
a) Spend money and time on legal action against the FBI for holding onto his servers for a couple of days while in the process of an investigation, in order to hopefully try and make a larger point.
and
b) Spending his time and no money by actually improving his bottom line by enhancing the features of his software,
you expect any rational person to choose (a) ?
I totally understand someone making a rational decision in favor of other priorities. It's what most people would do. But thank god for people who take the road less traveled. It's to them we owe the rights and freedom the rest of us take for granted. There's nothing "irrational" about that.
Fighting against the federal government over this seems like picking the wrong battle. He got is server back in a couple of days. Obviously its likely that the feds have already cloned it but its not like they kept it indefinitely or wiped it clean.
Does it suck? Yes. Is this something he should be fighting over? Not in my book.
I'm curious about what happened, but ultimately I put this down to an unfortunate side effect of using blades.
One of my favorite things about Marco is that he gives me confidence that there is not a gaping wide chasm between the skills of the best engineer-entrpreneurs and me. This time, it was his frank admission that he was taught by commenters and emailers than his current password encryption was unsafe and that there were better options out there.
When you realize that someone as successful as Marco has the same learning to do that "the rest of us" do, it makes me feel great.
That being said, even with volume encryption, the key is in memory somewhere. RAM isn't wiped as quickly as you might think, and it's apparently possible to extract keys from memory after the machine has been powered down. So be warned, and be paranoid!
There was an article I read recently about a patch for the Linux kernel to store the key in CPU registers instead of memory as well...
Take one of those, and a Google-style Lead-Acid internal UPS, and you'd have an incredibly hard time getting access to keys held solely in memory.
For the extra paranoid, accelerometers or a simple mercury vibration/tilt switch would make it even harder, at the risk of losing/hanging your server every time someone worked on the rack, or drove a heavy pallet cart nearby.
I recall seeing somewhere a device designed for law enforcement, which was essentially a cart-style UPS with probes designed to be clamped onto, and penetrate, the power cable, allowing seizures without any power-loss, which I assume is for this eventuality.
There's little chance they didn't.
If the data was cloned on-site, then we wouldn't have heard about the search warrant (there'd have been a gag order).
And as this happened yesterday, there's almost no chance that the server could have been taken to the lab, imaged, and then returned to be reconnected today.
I would bet 100 dollars that the actual target server of the raid is still sitting on a dolly in the forensics cage while a tech is waiting for someone to tell him what he's supposed to be looking for.
However, field cloning is absolutely not the desired procedure to use (for a lot of reasons). You only do field cloning if you are either: 1) Under a time crunch, or 2) Don't want the target to know that the clone has occurred.
If at all possible, you just take the equipment and process it in the lab.
I've done about 2 dozen of these for the FBI. We did field-cloning maybe three times.
Assume the FBI has a copy of everything on the drives and assume that they will see every file on the drive, even though odds are they don't and they won't.
He should contact the FBI and continue to beat on Digital One and determine if it was seized or not. It very well may have simply been turned off, is that not a valid possibility?
I can't speak to the level of service you did or did not receive but I seriously doubt DigitalOne could have done more to prevent "non-targeted" servers from being seized. If it was in the same rack as the "targeted" server I'm sure that 100% of the time LE would take it and find out whether it was related later. It's their job to take every step necessary to preserve evidence first and foremost when executing a search warrant like this.
I agree with you that the data was almost certainly not compromised and I think it's great that you're so proactive about protecting your customers by moving to bcrypt.
I wonder if this would be enough to give each server it's own legal "separate space" insomuch as to prevent a whole rack from being seized due to warrants like this.
Pro: after a powerdown, seizure/theft/cloning of the volume won' reveal user data
Con: need a secure way to supply decryption passphrase on each reboot
Again, thank you for the services you offer.