SessionTweets generates a daily PDF for any hashtag that you enter on the site. The PDF is updated every few hours with all the new tweets using that hashtag. If you want to see an example, go to the site or download this sample PDF of all #sxsw tweets from March 8th. Our goal with SessionTweets is to give you an easy way to review the discussion around sessions whether you attended them or not.

We would appreciate any help you can provide entering hashtags to track. So if you go to a session and the hashtag is announced, please visit the site and enter it so we can begin tracking it. Better yet, if you are a speaker, enter your hashtag ahead of time so we can be sure to pull all the tweets related to your session.

Hashtags are moderated by us so that you don’t end up with a bunch of PDFs about #v!@gra. If you have ideas about how to make SessionTweets better, please email us or leave a comment.

Google is apparently offering cloud-based self-backups for its Google Apps customers, which almost sounds like an article from The Onion. (“Google announces plans to partner with Google for data security.”) Sam Diaz over at ZDNet’s Between the Lines summarizes Google’s self-backup thusly:

Google, in its continued quest to lure enterprise customers to switch to the cloud-based Google Apps suite, is upping its offering with a free feature called synchronous replication.

In its simplest form, it’s the process of backing up data within Apps to multiple data centers so that, if there’s a disruption, the amount of data lost or the amount of time without access to the data is minimized.

Basically, if you’re a paying Google Apps customer, for whom Google already promises 99.9% uptime in your service level agreement, you can opt for synchronous replication, wherein Google will backup data your data in its cloud servers to its other cloud servers.

More specifically, while your Google Apps data is never relegated to a single drive or single server, it may be (Google won’t commit on this point, but it’s a probable implication)  relegated to a single data center. Thus, a serious natural disaster could see your Google Apps data locked out or lost. Synchronous replication means that your Apps data is always in two physical data centers, so it would require two serious simultaneous infrastructure failures before you could lose access to your Apps.

I applaud the effort to remove data centers as a single point of failure in Google’s data security scheme. My only question is why isn’t this already standard for all Google user data?

The subtext of the synchronous replication announcement is the admission that even though Google has over 35 data centers worldwide — and the ability to deploy them anywhere in data center shipping containers —  a failure at any one of these locations could wipe out all your data. I’m glad that paying Google Apps users — who likely have the most mission-critical data at stake — get synchronous replication for free, but what about the rest of us schmoes with years of messages and documents to lose if an earthquake flattens a single Mountain View server farm?

Hope you’ve got a backup plan.

Related articles by Zemanta

• Google Apps Now Disaster Proof (techcrunch.com)
• Disaster Recovery By Google – Just How Good Is It Anyway? (lockergnome.com)
• How Google Keeps Your Data Safe in the Cloud (mashable.com)
• Google now covers all Apps with advanced backup (computerworld.com)
• Google: No, really, Google Apps is the best place to store your data (venturebeat.com)

1. Go to the “Settings” page and select the “Manage” link next to “Gmail.”
2. Enter your email address for Username and your Gmail password. Make sure your browser has no auto-filled this with your Backupify password.
3. Click “create.”
4. Now you should see a list of folder/tags/labels with “Inbox” checked. This means that only your Inbox is backed up, and is the default setting. We have found that so many Gmail users leave everything in their inbox, that this works for a large number of people.
5. If you want to backup other labels/tags choose those and then re-enter your information.
6. If you want to backup all of your Gmail, you only need to click the “all mail” box.

Gmail backups are stored in .eml format, which means you can import your messages into any email system. Once we launch zip/export functionality in a few weeks, you will be able to package up all of those Gmail messages and download them to your PC, or push them to the storage system of your choice.

Late last month, The Economist set off a little thought bomb modestly titled “New rules for big data”. The article laid out all the various entrenched assumptions standing in the way of thoughtful, relevant information policy in the age of ever larger and more critical data sets. Put more simply, in a world where a Library of Congress is a fungible measure of data, we have to rethink how we protect and traffic information.

Backupify doesn’t yet handle multiple Libraries of Congress’ worth of data, but we want to get there. As such, we want to be forward-looking. Thus, the provisional crowdsourcing of our privacy policy, which begins to confront some of these areas of concern.

One of the more interesting points in the article was an argument against data retention:

“Current rules on digital records state that data should never be stored for longer than necessary because they might be misused or inadvertently released. But Viktor Mayer-Schönberger of the National University of Singapore worries that the increasing power and decreasing price of computers will make it too easy to hold on to everything. In his recent book ‘Delete’ he argues in favour of technical systems that ‘forget’: digital files that have expiry dates or slowly degrade over time.

“Yet regulation is pushing in the opposite direction. There is a social and political expectation that records will be kept, says Peter Allen of CSC, a technology provider: ‘The more we know, the more we are expected to know—for ever.’ American security officials have pressed companies to keep records because they may hold clues after a terrorist incident. In future it is more likely that companies will be required to retain all digital files, and ensure their accuracy, than to delete them.”

Sci-fi author and quasi-futurist Charles Stross has written repeatedly on the danger of reliance on databases for predictive analysis, if only because databases are routinely riddled with data errors. Bruce Schneier has written on the difficulty of purging your data from cloud-based systems, largely because the cloud companies don’t want to give up on all that delicious data-mining fodder.

This would seem to make the case that retaining data is more dangerous than deleting it. But is this an argument against databases, or an argument for better databases — and better data policies? If government is going to require companies to maintain data indefinitely, shouldn’t those companies be required to maintain the accuracy and integrity of those databases. Shouldn’t the government require the same of themselves? If we’re going to maintain a no-fly list, or e-mail blast address books, shouldn’t the agencies and organizations using them being under legal remit and obligation to make those databases at least 95 percent (or, to my mind, 99.999 percent) accurate?

More to the point, if an audit of a database shows the data to be less than 95 percent accurate — your mailing list produces a delivery error on more than one out of every twenty sends — you’re obligated to either upgrade or purge, period.

That said, is such an edict enforceable? It would seem that storage capacity is expanding (or, rather, dropping in price) faster than computing power, so we’re going to be able to store more data than we’re able to parse and maintain effectively. This argues for a classic, analog data retention policy — any record that hasn’t been updated after a certain period (the IRS says seven years) should be purged.

Still more complicated; not all records are created equal. Financial records are the sort of data that might need be kept indefinitely, especially for organizations of certain size, or any outfit that’s publicly traded. The same goes for any government transactional records. There is a public accountability stake in those records.

Conversely, address records (of the physical, IP, URL or e-mail variety) that haven’t been updated in perhaps three years may not be worth keeping. Personal finances likely qualify here as well.

At Backupify, we believe you own your data, not us. We’re the bank, but the money is yours. Withdraw it whenever you like, and it’s gone from our ledgers forever. But government may have something to say about those data polices — and everyone else’s — very soon.

Suffice it to say, I would not want to be the one crafting data compliance legislation right now. I welcome your insights into this issue in the comments section.

Related articles by Zemanta

• Bill Gates Knows What You Did Last Summer (yro.slashdot.org)
• American intelligence is great at building haystacks, lousy at finding needles. (slate.com)
• Data mining at a higher level (zyxo.wordpress.com)
• MIT Experiment: Predicting Sexuality Based On Facebook Friends (huffingtonpost.com)

Last Saturday, the New York Times ran a piece on the inadequacy of modern Internet privacy practices. In short, the “opt-in to a byzantine privacy EULA” approach is universally reviled, and doesn’t begin to address the myriad levels of granular privacy control that many users expect these days, or the myriad privacy loopholes that few are aware even exist.

Backupify has a fairly brief and straightforward privacy policy, as noted in our FAQ:

We don’t do anything with your data once it is backed up. We don’t look at it, we don’t sell it, we don’t analyze it, we don’t modify it. Our privacy policy is that you own your data and you should be in control. We don’t own your data, we just provide software to give you more control over your stuff. We charge for our service, so we never have to resort to analyzing your data so that we can sell advertising against it or anything like that. You will never get email from us unless you opt-in for it.

Backupify was started on the premise that your data is yours and you should not leave it locked up in all of these online systems. We believe strongly in freedom and privacy.

Personally, I think that’s a pretty clear, comprehensible and reliable security policy.

But here’s where it gets complicated: Users have asked us for a search interface for their backups, so they can find certain items within their data archive without downloading and parsing the data themselves, very much like the Navel-Gazer Self-Search we joked about on Monday. The features in that post were snarkily named, but they all contain an element of truth in that they represent functionality somebody has asked for.

So how do we index your data archive when we promise not to look at it? How do we build the E-marketer Goggles we suggested without analyzing your data? Even something as simple as a data retention policy — in which users have asked to delete part of their data archives after a certain retention period — would require that we check the timestamps on certain data elements before purging them. This gets even more complicated when we’re backing up version histories, such that we don’t want to purge older stuff, like WordPress themes, that’s still current.

Add in that some users have asked for these features and asked that they get complete encryption control over the data archive — I’m not sure how we’re supposed to search index your data if we can’t decrypt it — and you see where even our own well intentioned, direct privacy policy starts to look inadequate.

So I’m throwing this to the community at large: How would you write Backupify’s privacy policy? What clauses should it contain? Is it all or nothing, or do you opt-in by feature? Your feedback may well alter the very future of Backupify. Seriously.

Related articles by Zemanta

• Did We Lose the Privacy War? (ask.slashdot.org)
• Search Engine Startpage.com Introduces Anonymous Web Browsing (eon.businesswire.com)
• F.T.C. Wades Into the Swamp of Online Privacy (bits.blogs.nytimes.com)

What services will Backupify offer two years from now? Hard to say. We’ve got lots of cool ideas, some crazier than others. Here’s a listing of some of the wackier concepts that may or may not have come up during brainstorming sessions. Please feel free to weigh in on your favorites, and don’t forget to relate your requests to Backupify’s core business.

Navel-Gazer Self-Search: A meta-search of all the Backupify services you back up. Find keywords or links regardless of where you posted them. So if you went on a Facebook-Twitter-and-Google-Buzz tirade about the latest Apple product rumor (the iPad 4.0 has a 3D videochat cam, and for only $1699!) you can sort through all your posts to find out exactly where you put that link to the leaked prototype pics.

“The Party’s Over Here Now” Profile Migrator: The Facebook Killer has finally arrived (Orkut? Really?) and you don’t want to drag all the photos and videos and friend lists and birthdays over to the new hotness? No worries; Backupify has a wizard that will let you pick and choose which bio — Twitter, Facebook, LinkedIn, or Google Profile — you like best, and which friends from each service you want to to slide over, along with an easy way to import all the multimedia files you’ve got jammed all over the place. And in 18 months, when the next new social network fad pops up, you can do it all over again, only easier.

The “Eternal Sunshine” Machine: Got a relationship (or a weekend) you’d like to erase from your online memory? A few keyword and profile selections, and we’ll delete every connection to your ex that’s out in public, while retaining the unpurged records in our archives (just in case he apologizes and you decide to patch it up).

Twitter Court Reporter: Give us a list of Twitter usernames and a general time window, and we’ll narrow down your tweetstream to just the conversations you had with these individuals, then output the whole confab as a searchable PDF.

E-Marketer Goggles: We’ll run a general keyword analysis over your collective social profiles and determine what products and services that marketers — who buy data from Twitter, Facebook and Google for exactly these purposes — think you’re apt to buy. This may explain some of those bizarre AdSense ads and spam messages you keep getting. Think of it as a next-generation tag cloud of your online footprint, only more useful (and creepy).

If any of these sound cool to you, or if you’ve got an even better idea, feel free to flame away about it in the comments section of this post.

Related articles by Zemanta

• Backupify is sooooo cool. (calacanis.com)
• If Google Wave Is The Future, Google Buzz Is The Present (techcrunch.com)
• Backupify Needs Your Help (socialmediaexplorer.com)
• The Mysterious Social Search Abyss Of 2010 (techcrunch.com)

Henry Ford once famously said “If I had asked people what they wanted, they would have said faster horses.” In some circles this is taken as an admonition not to listen to customer requests.  In what I would term smarter circles, this is a reminder to remember what your company is about.

Henry Ford wasn’t selling a replacement for the horse, he was selling personal transportation. It just so happened that his answer for the best possible personal transportation was a horse-replacement, the automobile.

Apple, which is perhaps best associated with the “ignore the customers, we know better than them” interpretation of Ford’s philosophy is nonetheless a great example of remembering what business you’re in. Apple wanted to sell a better portable music experience, which resulted in the iPod. But Apple isn’t in the MP3 player business. It’s in the portable music experience — or, rather, portable media experience — business, which is why the iPod has become somewhat ignored in favor of the iPhone, iTouch (which is so far removed from the original iPod people rarely call them iPod Touchs anymore) and iPad.

Which brings us to Backupify. Yes, we backup your cloud-based data, but we’re not really selling cloud data backups. That’s the mechanism, not the business.

Backupify is selling control of your cloud-based data.

Your Gmail messages are just messages you happen to store in Gmail; the service doesn’t own the data. Backupify exists to detach the data from the service, the profile data from the profile page, the medium from the message. If Gmail fails, the data is safe. If you want to analyze the data, you can download it from us and parse it however you like. If you want to migrate away from Gmail to another e-mail solution, we’ll do our best to facilitate the changeover.

The same applies to your Facebook profile or Flickr albums. Those are your videos and pictures and birthday wishes and commiserations with friends. They belong to you, not to the cloud, and not to any specific brand or application. Backupify is here to make sure of it. That’s our business. That’s what we’re selling (or, in most cases, giving away).

Backupify is in the data control business. It just so happens that backing up cloud-based data is where we’ve started. But if a better solution comes along, we’ll be ready for it.

Related articles by Zemanta

• Don’t Let Good Become the Enemy of Great (gigaom.com)
• Why GigaOm is right (and wrong) about Backupify (backupify.com)

• photos
• comments
• tags
• exif
• geo-locations

Please login and try it out. This was our first service written from the ground up using Amazon’s RDS service, so that was a lot of fun and we have moved (and are moving) many of our other services to RDS. It also uses Google’s authentication protocol, so we don’t have to store your username and password.

If you have problems, questions, or comments, send us an email. And if you have friends that use Picasa, send them this link so they can backup those photos!

Image by Oversocialized via Flickr

Google makes money by being your information middleman and serving ads along the way. The search page is the universal home page, and so long as that search page is Google’s, they’ll continue to print obscene gobs of money. So what does this have to do with the “slow motion train wreck” that is Google Buzz, the new FriendFeed clone that Google tacked onto Gmail mere days ago? It’s all in how you connect the dots.

Facebook is doing a bang-up job displacing Google as the universal home page, to the point that Facebook basically owns social page referrals, which is to say links that were recommended by friends, rather than search engines. If social referrals start to rival basic search in volume, Facebook could outflank Google. This problem will probably only get worse for Google as MS Outlook becomes the “social hub” of MS Office, drawing in LinkedIn, MySpace and Facebook data for the old fogeys who don’t use Web mail. (Moreover, Facebook is moving aggressively into mobile — the same mobile space Google wants Android to own, despite a huge rival in Apple’s iPhone — which means Google could get outflanked on two fronts by Team Zuckerberg.)

The answer? Google needed its own social referral engine, and shared links on Google Reader weren’t good enough. Enter Google Buzz, a redo of the FriendFeed service that Facebook bought not so long ago.

That’s all fine and good, except for two problems. First, Google hates user configuration; it wants to pre-optimize your experience by tuning it with what it already knows about you. This usually means using your Gmail contacts to connect you to whatever new service they roll out. For Google Buzz, this meant that millions of Gmail users were now automatically publishing their contact lists to millions of other Gmail users, which could be a big deal if you had confidential sources or clients that other people really shouldn’t (ethically, legally, or socially) know about. Reporters, lawyers, doctors and philanderers were all severely put out.

This might seem an obvious flaw that should have been caught in user testing, except for our second problem: Google rushed Buzz to market without subjecting it to standard user testing.

Google users screamed about the privacy problem, and Google had a fix rolled out in days — though not fast enough to avoid some government investigations of privacy violations. (Don’t laugh; Canada takes that stuff seriously.)

Google is fighting a pitched battle with Facebook and Apple. The stakes are getting higher, which means time-to-market for new Google, Facebook, and Apple services is going to get shorter. It also means the temptation to shoehorn a new feature into an old one — like Google did by trying to springboard Buzz by sucking in 175 million Gmail users — is going to be an ever more tempting tactic. TechCrunch lists the long and sordid history of “force-feeding” users new Web services – Facebook, AOL and Yahoo all appear on the list.

To paraphrase Battlestar Galactica, all of this has happened before, and all of this will happen again. Possibly to you.

At some point, this trend is going to result in a huge data exposure or, worse, a huge data loss for a major, brand-name Web service. Don’t be surprised when it comes down the pike, and don’t be without a backup plan.

Related articles by Zemanta

• Google Tweaks Buzz After Overblown Privacy Backlash (wired.com)
• Facebook Drives 44 Percent Of Social Sharing On The Web (techcrunch.com)
• Google Buzz from a medical blogger’s perspective (casesblog.blogspot.com)
• No escaping social email: Facebook and MySpace coming to Outlook (digital.venturebeat.com)

Image by Rocío Lara via Flickr

On Monday, Mathew Ingram over at GigaOm offered his reaction to Backupify getting VC funding. Put simply, Ingram was skeptical about the future of our company. He made some fair points. We agree with some of them. Let’s take the criticisms one by one:

“[T]he main problem for Backupify is that it suffers from all of the privacy and reliability concerns that tend to cluster around any cloud-based service — and then some. After all, some users don’t even like storing their documents online with giant players such as Google or Microsoft; why would they want to do so with a tiny startup? And if backing up your desktop data to the cloud takes a leap of faith (due to some high-profile data losses), it’s likely to take an even bigger one to back up data that’s already in the cloud with another cloud-based service.”

Ingram is spot-on; lots of users have some trepidation about putting their traditional data online. By traditional I mean documents and spreadsheets and perhaps even photos and music. But what about non-traditional data, like social profiles? The average Facebook user spends 55 minutes a day online “building” an online presence by populating it with data, and there are 100 million Facebook users in the US alone. I’m not seeing the hesitation to put data online, based on those figures. Users may not view Facebook data with the same eye as business data, but we’re betting that enough users place enough value on it that we can make money keeping it safe.

Also, in some industries, business-centered social profiles are required to back up their data by regulatory bodies. So we don’t have to convince those guys of the need; we just have to convince them we’re the right answer for that need.

So far as convincing the world that they need to put their traditional data online, Microsoft is making a pretty big bet on Office Online and SkyDrive, to say nothing of Google Docs or Zoho Office or Salesforce.com or Flickr. If those guys think online data storage is the future, we won’t apologize for making the same bet. Also, raise your hand if you’re okay with your Gmail, Yahoo Mail, or Hotmail accounts just disappearing. We’re pretty sure lots of folks want to keep their e-mail archive intact.

Yes, we’re a tiny startup. So was Google at one point. Building the credibility of our brand is a long, arduous process, but it’s the same one every startup faces. There’s just no getting around that.

Yes, the big guys have had major data losses. Frankly, we see that as an advertisement for our service, not as a mark against us. We don’t concede that size is equivalent to competence.

So far as a cloud-to-cloud backup, there is definitely a certain multiplier of trepidation going on there. This is a user-education battle we must fight, no doubt. Our bet is that as user comfort with the cloud grows — thanks to the aforementioned efforts by Google and Microsoft — this will diminish.

“Backupify also notes that for some services such as Twitter, it won’t be able to restore the data fully but will simply send you an XML data file that it admits ‘is not easily readable by human eyes’ (the company says it is working on other formats).”

With the data format issue, we made a choice early on that machine-readable data was more important than human-readable data, largely because most of our early adopters wanted data they could easily parse with a SQL query or similar software intermediary. We’re working on the more intelligible output version but, frankly, the demand hasn’t been overwhelming. Nobody is really asking for a way to print out the version history of their Facebook page as a series of screenshots, though we think it would be really cool to offer something like that someday. They just want the data if their boss or FTC/IRS/SEC come asking for it.

So far as the inability to recreate your Twitter stream, that’s a Twitter issue not a Backupify issue. Simply put, the Twitter API won’t let us backdate tweets, so we can’t restore a record to its original state. We’re working with Twitter (and services with similar issues) to find a workaround, but this is really an issue out of our control. If this upsets you, we very much encourage you to let Twitter know it.

“Backupify doesn’t host your data itself, the company points out in a FAQ. Using public APIs, the company extracts your data from various cloud-based services — Flickr, Facebook, Twitter, Google Documents, etc. — and sends it to Amazon’s S3 (Simple Storage Service). In other words, Backupify is more or less a middleman that stands between your social web services and Amazon’s cloud storage offering. While this might assuage some concerns about the reliability of the backup, however, it’s likely to raise others, since S3 has been known to have issues itself“

First, we’re in the process of setting up a backup of our backups with another cloud storage provider, so we’re not solely reliant on S3 (which actually has a pretty good record, overall). No service is perfect, as Ingram rightly points out, and we’re making sure there’s no single point of failure with our service.

Yes, Backupify is a middleman, and we see no shame in that. Trust us, dumping gigs of Gmail data to S3 isn’t easy– especially in a fashion that doesn’t prompt Google to suspend a Gmail account for “excess activity” — and we think that users are willing to pay the convenience cost if only to avoid retracing the learning curve we’ve been on for the last year. Certainly there are organizations with the engineering bandwidth to build their own in-house solutions, but that’s true of any software product. We think the service we provide is difficult enough to reproduce that a profitable number of users will pay us to do it. So far, we’ve been right.

Ingram’s article does a nice job of distilling the prevailing concerns about our business model. We have no shortage of obstacles to overcome. We don’t deny that. We simply don’t view any of those challenges as insurmountable. Time will tell whether we’re right, but we hope all of you — Ingram included — will stick around to find out.

Related articles by Zemanta

• Cloud Gazing: Backupify (geekwithkids.com)
• In Cloud We Trust: First Round invests in Backupify (thisisgoingtobebig.com)
• First Round, Betaworks, And Angels Back Up Backupify With $900K (techcrunch.com)
• Backupify Closes Seed Round to Expand Critical Cloud Data Backup Services to Burgeoning Business Market (eon.businesswire.com)
• Online privacy issues, complaints familiar (msnbc.msn.com)