Instapaper Blog

Instapaper 4.2 now available in the App Store

This is a significant update with many fixes and new features, including a new iBooks-Style Pagination option:

New iBooks-Style Pagination option. The old animation is available in Fast Pagination mode.

Other features:

All-new Fast Pagination mode, a complete rewrite from the old pagination code that greatly improves accuracy and page-turn speed
New draggable dot bar to replace the scroll bar in pagination mode
New two-finger-swipe gesture to close an article
Full-screen now has “Auto” mode to switch to full screen after a few seconds
The subtle Twilight Sepia color tint can now be selected at any time
Added sharing to Drafts and the upcoming Quotebook 2.0
Many bugfixes and performance improvements

This update is free for all customers. Update today!

New bookmarklet with multi-page article saving

The Instapaper “Read Later” bookmarklet is now redesigned as a faster, more compatible full-page overlay that’s easier to see.

The previous little “Saved!” frame had a great run, but its time has passed. Readers are now saving more pages than ever on tablets and phones, and the old bookmarklet wasn’t visible enough there. Instapaper’s customers would often complain that they didn’t even see the old bookmarklet working.

So the bookmarklet now sports a completely new design that’s highly visible at every screen size, and works in more browsers, too:

The new bookmarklet now also supports automatic saving of every page in multi-page articles.

Like the previous bookmarklet, it works for sites that require logins or payment, too: if you can view a page, you can save it to your Instapaper account. You don’t need to give Instapaper your passwords (I don’t want them) or require publishers to change their business models. If you can see it, you can save it.

You don’t need to reinstall your Read Later bookmarklet to get this update. It applies automatically to the one you already have.

For feedback, bug reports, or requests to improve the handling of particular sites, please email. Thank you.

A (hopefully) final update on the FBI raid

I’ve had a chance to correspond with DigitalOne over the last few days to clarify what happened with the server raid last week in which the FBI (seemingly accidentally) took one of Instapaper’s database servers and numerous other unrelated servers when attempting to seize another server allegedly used for malware distribution.

I initially assumed and published that when the FBI took my server, they had possession of the hard disks and therefore a copy of the Instapaper database and source code.

DigitalOne’s CEO, Sergei Arsentiev, informed me in an email last night that the FBI agents only took one enclosure containing 16 HP C7000 blade servers (including the one I was leasing), but that my server’s two hard drives were in a separate HP MDS600 enclosure that was not taken, and the drives were never removed from it.

If this is accurate, the FBI did not take my server’s hard drives from the datacenter or their enclosure — they only took the C7000 module that contained my server’s processor, RAM, and other non-storage components.

I don’t know enough about the physical workings to say for sure, and I wasn’t present to observe the agents’ actions, but this makes it very unlikely that they read or copied any of Instapaper’s data or code.

I’m relieved to learn this, and I’m considering the matter closed for now. Thank you, everyone, for your support during this ordeal.

Server update

About 40 minutes ago, at 11:45 PM EST on June 23, the server that I believe the FBI took during the DigitalOne raid came back online for the first time.

The logs indicate that it was not booted into its OS during the time it was missing.

DigitalOne has still said nothing about the raid to me, but my best guess is that the FBI did have physical possession of the server for this period. If so, they could have copied the data from the drives without booting from them and without leaving evidence of the copy.

Since it was returned so quickly, it’s likely that they determined that it wasn’t part of their target group and wanted to avoid any problems that could have resulted from its continued seizure. While they could have copied the data for future analysis, I believe it’s unlikely that they would have reason to do so. Regardless, I have no way to know what they did (or didn’t do) with it.

For whatever it’s worth, I have deleted the code, data, and keys from the server and asked DigitalOne to cancel my account immediately. I’m not convinced that they did everything they could to prevent the seizure of non-targeted servers, and their lack of proactive communication with the affected customers is beneath the level of service I expect from a host.

Many commenters and emailers have taught me that bcrypt and scrypt are better than salted SHA-1 hashes for password storage, so I’m researching them and will begin load-testing with them next week. If all goes well, I’ll deploy one of them and migrate all subsequent logins and password changes away from salted SHA-1 hashes.

I appreciate the outreach from people wanting to help me fight the FBI or DigitalOne somehow, but that’s honestly the last thing I’d want to do. Even if money were no object, I can’t afford the time or the stress, I’m not looking for any sort of reimbursement, and nothing they say would absolutely assure me (or even the slightest skeptics) that they had zero copies of the data.

I have a great product to maintain, expand, and improve, and there’s nothing I’d rather do than get back to work doing what I love.

The FBI stole an Instapaper server in an unrelated raid

UPDATE: The server has been returned. Please read.

One of Instapaper’s five leased servers was hosted at DigitalOne, a Swiss hosting company leasing blade servers from a Virginia datacenter. Early Tuesday morning, the FBI raided the datacenter to seize servers used by another DigitalOne customer for fraudulent “scareware” distribution, according to the FBI’s press release, but they seemingly took a lot more servers that happened to be physically near the server(s) they were looking for.

There’s very little information on this, but The New York Times has the most complete coverage in Tuesday’s Bits post:

The F.B.I. seized Web servers in a raid on a data center early Tuesday, causing several Web sites, including those run by the New York publisher Curbed Network, to go offline. …

In an e-mail to one of its clients on Tuesday afternoon, DigitalOne’s chief executive, Sergej Ostroumow, said: “This problem is caused by the F.B.I., not our company. In the night F.B.I. has taken 3 enclosures with equipment plugged into them, possibly including your server — we cannot check it.”

Mr. Ostroumow said that the F.B.I. was only interested in one of the company’s clients but had taken servers used by “tens of clients.”

The LA Times also has good coverage:

“FBI was interested in one of our clients and in his servers, but they took besides target servers tens of not related servers of other customers,” [Ostroumow] said.

As far as I know, my single DigitalOne server was among those taken by the FBI (which I’m now calling “stolen” since I assume it was not included in the warrant). I’m assuming this because it became unreachable and stopped sending updates to my internal monitoring system at approximately the time that the FBI raided the datacenter, and has not come online again since then.

The server was used as a MySQL replication slave, handling read-only queries to speed up the site. Instapaper suffered no downtime as a result of its theft and no data has been lost, but site performance has been slower without it.

Instapaper’s main host, SoftLayer, responded quickly to an order I placed to replace this server there. It’s almost completely set up, and the site’s performance should be fully restored by tonight.

What the FBI stole from Instapaper

I didn’t own the hardware — I was leasing it from DigitalOne. So the FBI has only stolen my time and a partial month of hosting fees, not any physical property of mine. (The hardware was pretty expensive to DigitalOne, though: each of these servers probably costs $5,000–8,000.)

Possibly most importantly, though, the FBI is now presumably in possession of a complete copy of the Instapaper database as it stood on Tuesday morning, including the complete list of users and any non-deleted bookmarks. (“Archived” bookmarks are not deleted. “Deleted” bookmarks are hard-deleted out of the database immediately.)

Instapaper stores only salted SHA-1 hashes of passwords, so those are relatively safe. But email addresses are stored in the clear, as is the saved content of each bookmark saved by the bookmarklet.

The server also contained a complete copy of the Instapaper website codebase, but not the codebase of the iOS app.

Linked Facebook, Twitter, or Tumblr accounts only store their respective OAuth keys. Linked Evernote accounts only store the Evernote email-in address. Linked Pinboard accounts, however, store plaintext usernames and encrypted passwords, and the encryption keys are present in the website source code on the server.

So the FBI now has illegal possession of nearly all of Instapaper’s data and a moderate portion of its codebase, and as far as I know, this is completely out of my control.

Due to the police culture in the United States, especially at the federal level, I don’t expect to ever get an explanation for this, have the server or its data returned, or be reimbursed for the damage they have illegally caused.

UPDATE: Fortunately, I was wrong about one of those: The server has been returned. Please read.

I’m really not sure what to do about this. I’m speaking to my lawyer about it shortly, but as far as I know, there’s nothing I can reasonably do without spending more money, time, and stress than I can afford on a path that would likely lead nowhere productive.

DigitalOne’s response

DigitalOne hasn’t handled this well. Nobody from the company has contacted me at all since this began. The company’s website is still down, suggesting that they might not have any backups (or at least don’t care enough) to set up a temporary page elsewhere. I have no idea whether I’ll ever see the server again, whether I’ll be reimbursed for the remainder of the month that I’m not receiving the service I paid for, or whether I’ll be billed on July 1 for the next month of nonexisting service.

It’s also possible that miscommunication or a lack of communication from DigitalOne caused the FBI to be so imprecise in what they took. Nobody really knows except DigitalOne and the FBI, and neither are being particularly helpful.

Regardless, I’m not hosting any servers at DigitalOne in the future, and I’m not renewing this one (if that ever becomes possible).

UPDATE: The server has been returned. Please read.

Mini-FAQ on iOS updates, Reading List, iCloud

A lot of people have asked these questions on Twitter or via email since the WWDC keynote last week, so I’ve consolidated my answers here:

Will Safari’s Reading List feature “kill” Instapaper?

I highly doubt it.

But I’m not standing still. I’m preparing some great updates for the coming months.

Can Instapaper integrate with Reading List somehow?

No. As far as I know, there’s no API to access Reading List’s contents or add pages to it.

Does Instapaper still support iOS 3.1.3?

Today: Yes. In the near future: No.

There are a number of great features that I want to use in iOS 4 and 5, and compatibility with iOS 3.1.3 is starting to become an expensive burden. My code is quickly filling with special cases and duplicate implementations, and this will hinder Instapaper’s feature development, maintenance, and stability until I can eliminate 3.1.3 compatibility. My quality assurance would also improve since my testing-device count would be greatly reduced.

So in one of the next releases, I’m raising the minimum to iOS 4.0. This will drop compatibility for the original iPhone and first-generation iPod Touch, all of which are now at least three years old and represent only 0.48% of Instapaper’s customers.

And in the not-too-distant future, possibly as soon as next spring, I intend to raise the minimum to iOS 5 because it has tons of great UIKit improvements and opportunities for me to delete lots of hacky legacy code. iOS 5 excludes the iPhone 3G and second-generation iPod Touch as well, which represent 3.4% of customers today, but that number is falling quickly.

Can Instapaper use Newsstand to get automatic background downloading?

Probably not. The specifics are under the WWDC-attendee NDA, but I think I’m safe to say that only Newsstand apps get access to background downloads, and there would be a number of downsides to making Instapaper a Newsstand app.

It’s also unclear whether this sort of use would be rejected. And since it might be right on the edge of permissable, it’s also a high risk that it might be approved and then later pulled from sale, which would potentially be very expensive.

I want to wait and see how other non-publication apps, such as feed readers, handle Newsstand before I’ll consider it. But it’s probably smarter to wait for Apple to possibly give more apps automatic-background-download abilities in the future.

Can Instapaper use iCloud to simulate automatic background downloading?

Not really. The idea would be to have an always-running Mac app on each customer’s computer to push newly saved documents through iCloud and onto the devices. But Apple doesn’t want developers storing this type of data in iCloud (the specifics of which are, again, probably under the WWDC NDA), and I don’t want to risk rejection.

Can Instapaper move its service to iCloud and get rid of its servers?

No. This could only work if Instapaper was just the isolated iOS app. But there’s an entire web service backing it that gives it benefits that iCloud can’t, such as support for all web browsers, non-Apple devices (most notably including the Kindle), a dynamic page-transformation engine, and API additions from hundreds of other services and apps.

Can Instapaper use the built-in iOS 5 dictionary and drop its current one from the download?

Possibly. Instapaper’s built-in dictionary has some useful features that Apple’s dictionary doesn’t offer, including words that link to their own definitions and support for other installed dictionary apps such as Terminology and foreign-language dictionaries.

So I might be able to use Apple’s exclusively in the future if it gets some improvements, but for now, I’ll probably just make it an option and continue to bundle my own, which only requires about 16 MB of space on the device.

Can Instapaper switch to the new iOS 5 Twitter integration?

Not without losing significant functionality, such as offline queuing of tweets. For now, I don’t plan to switch to it, although I may offer it as an alternative.

Can Instapaper use the new hardware-brightness control in iOS 5?

Yes! Can’t wait.

Can Instapaper use the iBooks-like page-turning mechanics in iOS 5?

Probably. I’d like to, but it would require a restructuring of my pagination code, and I’m not sure it’s reasonably possible for Instapaper’s content and considerations. I’ll be experimenting with this a lot in the next few months to see if I can get it working without significant drawbacks.

Instapaper 3.0.3 update

This is mostly a bugfix update:

Fixed bugs with pagination, tilt-scrolling, AirPrint, and other minor issues.
Consolidated search bar to always search all titles and content.
Added support for more dictionary apps in the Define window. The full list is now:
Each app is only displayed if you have it installed.

Get it now, and of course, it’s free to all existing customers.