An interesting note came across our inboxes just now - the source of yesterday's FriendFeed spam has been revealed. If you've been using the social aggregator FriendFeed, then you may have noticed some odd-looking discussions yesterday where the same comment was repeated over and over by numerous different users. The source of this spam has now been identified, but this problem highlights a larger issue that could affect any company providing an open write API for developers to use - it only takes one developer's mistake to greatly impact a service.
If you don't know what we're talking about, then take a look at these posts on FriendFeed here and here to see the problem in action (or just check out the image below):
According to FriendFeed's Bret Taylor, the problem was caused by an malfunctioning API client. At the time, he didn't know whether the problem was accidental or intentional, so they disabled the API client and researched the IP address to determine where these messages were coming from. They then got in touch with the developer to let him know what was going on.
As it turned out, the service at fault was Gridjit, a social portal service still in alpha that uses both Twitter's and FriendFeed's APIs to allow you to view and interact with both services from Gridjit's web site.
As soon as FriendFeed got in touch with Gridjit, Gridjit's founder, Ray Grieselhuber, disabled the service's ability to post statuses, comments, and likes from within Gridjit and shut off access to the account management screens. After a day's worth of research, the problem was discovered - it wasn't a security issue, just a bug in the code. The issues is being addressed now and the affected users who had comments posted under their name were contacted via an email that read:
I'm sending this to let you know about a bug in Gridjit's code that caused a comment to be posted to FriendFeed in your name.
I spent the day reviewing the system and performing security audits to ensure that that this was not a security violation - it was not.
Rather, it was a bug in the system that caused the extra comments to be posted based on some obscure query patterns. I'm taking steps to prevent this sort of thing from happening again.
If you would like to see the comments and delete them, the FriendFeed links can be found here:
http://friendfeed.com/e/6def167a-f3d2-4711-aebd-6f8171919178/http-www-geeky-gadgets-com/
http://friendfeed.com/e/8be20617-8d57-478c-a367-98da5d02a8a0/Not-a-complete-list-of-top-diggers/
I sincerely apologize for this. The quality of your experience with Gridjit is very important to me.
Additional details and updates will be posted on the Gridjit blog (http://blog.gridjit.com).
Please let me know if you have any questions.
Best regards,
Ray Grieselhuber
While in this particular case, the issue was relatively minor and more of a strange occurrence than anything, it was only through FriendFeed's quick action that the entire service was not affected by this programming bug. Of course, it was also helpful that Gridjit is still in private alpha testing at the moment, so there aren't a lot of users currently using their service.
But what if this bug had come from another service that was heavily used? And what if it had been a web app that's far more mission-critical than FriendFeed?
The problem with providing an open API (that is, a write API) is that all it takes is one programmer to have a big impact on a service. Like in the case of Gridjit, it may be an accidental bug in their code, but it could have just as easily been someone with a more malicious intent.
TrackBack URL for this entry: http://www.readwriteweb.com/cgi-bin/mt/mt-tb.cgi/4343
Comments
Subscribe to comments for this post OR Subscribe to comments for all Read/WriteWeb posts
Whoda thunk it? Giving unknown external entities ability to write without prejudice? Spam? No......
Posted by: Aaron Brazell
|
July 2, 2008 9:01 AM
I'm gonna be more careful which sites I give my FF credentials to.
Posted by: Hao Chen
|
July 2, 2008 9:02 AM
Good for Gridjit to respond so quickly, but bad that it happened at all. At least this time it wasn't a malicious source. Who knows how long it will take for that to change? It seems like these new services start out as so much fun and then it doesn't take long for spammers and others to start taking shortcuts and it really cuts in to the value for all the rest of us.We are all in uncharted territory with Social Media and people need to be careful when choosing what sites to add to FF or other social sites.
Posted by: Brenda Young
|
July 2, 2008 9:15 AM
To be fair gridjit is in alpha so teething troubles are to be expected and I guess it was only people testing the gidjit service that were involved. Ray also followed up real quick and let everyone know personally what had happened which I'm sure was the first some people had heard of it. Does make you think about the API process though
Posted by: Jon Dillon
|
July 2, 2008 9:19 AM
Thanks, Jon. Of course, I was very upset that this happened but Gridjit is better now for it. Also, it does point to the strength of the remote key system that FriendFeed chose for their API and the professionalism of their team. I wish other services provided similar services (like OAuth, etc.) for access to their APIs.
Posted by: Ray Grieselhuber
|
July 2, 2008 9:26 AM
Hello Sarah,
Nice post. You are right about having those concerns but the problem is not only with applications that provide a write API. Given the nature of the Web, this can also happen the other way around, with aggregators that are copying content from other sites.
Suppose, for instance, that there's a bug with twitter's RSS feeds, duplicating entries across users just like the example you show on your post. What would happen to the thousands of aggregators out there that use twitter's feeds? How would you solve that problem?
I believe the solution is to implement measures that can possibly identify duplicates, false posts, suspect activity, throttling, and so on. If FriendFeed had a similar content throttler in place it could identify the behavior you're describing, automatically disable the API client ID and inform the API client of the ocurrence.
Posted by: Bruno Pedro | July 2, 2008 9:34 AM
There may well come a time when it is necessary to lock down the API and require developers to be issued unique unlock keys, so that any spamming or other malicious activity can be tracked and shut down promptly.
Posted by: Slippy Lane
|
July 2, 2008 9:43 AM
@SlippyLane many services do require a unique key already. FriendFeed just happens to not be one of them. The worst part is that if you have a logic bug when using the API (probably the issue with Gridjit) it can do things like multiple repeated posts. Hopefully, people give them a chance.
Posted by: Rob Diana
|
July 2, 2008 9:50 AM
Speaking of Friendfeed... nice integration into comments...!
Posted by: Aaron Brazell | July 2, 2008 12:22 PM
Interesting note, plurk also had a problem related to their unofficial API release. A user was messing around with the API and unknowningly friended most of the people on plurk, skipping the approval step, basically adding themself as a friend with out people knowing.
Posted by: Boredcollegekid | July 2, 2008 7:52 PM