Distrust in the Cloud Part #2: Facebook Blocks J.mp Links and Takes Down Lots of Status Updates in the Process
I previously blogged about my problems with Scribd, the document hosting service, when they put up a paywall on user-uploaded documents. Scribd tried to soft-pedal the change by giving users an opt-out, but they never fully acknowledged how they changed their basic business proposition or how their move basically pitted Scribd against its users.
In my blog post, I solicited alternatives to Scribd. The reality is that only one solution–hosting at my own domain–gives me full control over my own fate. Any other solution puts me at risk that something will go wrong with the vendor: they will go out of business, make a goofy business choice like Scribd, or otherwise disrupt my expectations. Self-hosting has its own downsides, though. I have to bear the hosting costs (which in aggregate could start to add up), and publishing via Scribd is substantially quicker than self-hosting (an important consideration when I am publishing lots of files).
Recently, I’ve had two other moments where cloud service providers have disrupted my expectations as well. I’ll blog about my Gmail experiences in the near future. Today, I’m blogging about a conflict between two of my vendors, Facebook and Bit.ly.
I have been using a link shortener for a couple years now (ever since I ramped up my Twitter activity). Link shorteners are a necessary evil now. It’s really not possible to use Twitter without some link shortener. The reality is that if I want complete control over my fate, I should run my own link shortener at a domain I control. Without doing that, I am at the mercy of the link shortener vendor. This point was hammered home when my initial preferred link shortening vendor, bit.ly, pulled the plug on links at the request of the Libyan government. I don’t think I link to the kind of URLs that would interest the Libyan government, but its capricious exercise of influence over a US company was enough to send me looking for alternatives.
It was easy enough to switch to j.mp, another shortener run by bit.ly but with a TLD under the United States aegis. (After the Wikileaks debacle, our government’s censorial impulses remain highly questionable, but I’ll take the US government’s abuses over the Libyan government’s). Because it was part of the bit.ly family, the web interface was identical and my previous bit.ly links showed up in my j.mp account.
Late at night last Wednesday (i.e., right before the Christmas break), Facebook blocked all j.mp links and all status updates containing j.mp links, showing its all-too-familiar disclosure:
“This message contains blocked content that has previously been flagged as abusive or spammy. Let us know if you think this is an error.”
I hate the passive voice of this disclosure, which makes the disclosure false more often than not. I let Facebook know via the specified feedback mechanism and, as usual, heard nothing back. I did, however, get responses from my other channels.
Facebook’s position is that over 70% of j.mp links were spam or for malware. Taking Facebook at face value, apparently I was one of the relatively rare folks who used j.mp for legitimate activity. For those few of us, Facebook’s remedy was troubling: Facebook took down all status reports containing j.mp links, irrespective of the links’ legitimacy. Because I automatically repost my Twitter posts as my Facebook status updates–most of which are links to other stuff using a link shortener–Facebook’s categorical takedown of j.mp links basically gutted the last 3 months of my status updates. Not only that, but many of my posts have comments from my Facebook friends, and all those comments disappeared.
The story reached a reasonably happy conclusion (for now). Within 24 hours, Facebook and bit.ly apparently reached an accommodation, and my previously deleted status updates were restored.
Even so, I have unanswered questions about this incident. Most importantly, how hard did Facebook work to resolve problems with bit.ly before Facebook wiped away user updates and the attached comments? From my perspective, because j.mp was a major link shortener, Facebook should tread really cautiously and give bit.ly lots of notice and opportunity to fix the problem before pulling the plug on j.mp. Then again, Facebook is uncomfortably free with its anti-spam block, as I noted in my post about Facebook’s block of any post containing the word “power.com” (even when the phrase is not an active hyperlink), despite a pending (at the time) Power.com antitrust lawsuit against Facebook. Don’t underestimate Facebook’s willingness to impose ill-advised “anti-spam” blocks.
Without knowing what Facebook did to resolve the problem before blocking j.mp, I’m not sure how to allocate blame for this incident. If bit.ly got clear advance notice of Facebook’s impending block and didn’t find a way to avoid it, then shame on bit.ly for not combating spam and malware better. If Facebook didn’t give adequate warning to bit.ly before ripping down thousands (millions?) of legitimate status updates with legitimate j.mp links, then shame on Facebook for so cavalierly interrupting legitimate conversations between its users.
Either way, at least one of my cloud service providers isn’t trustworthy; most likely, both are untrustworthy. I’m not sure what to do about finding an alternative link shortening service to j.mp/bit.ly. I’m still thinking about that. Regarding Facebook, this incident reinforces why I rely mostly on my Twitter account. Even though Twitter’s uptime is shaky, they have never pulled any stunt like Facebook’s mass content takedown. I urge anyone who reads my posts in Facebook to follow me at Twitter instead. I post the same content in both places, but Twitter has a higher likelihood of actually showing up.