Antiantisocial Networks

Today TechCrunch reported on a paper describing a way to use Facebook for malicious means.  The paper describes a DDoS attack that can be done, leveraging the large number of users of an application to attack a victim site.

While this attack vector is legitimate, I see a number of things that make it inherently infeasibly, and don’t think it really warrants being called a “FaceBot” (implying similar power to a botnet).

In order to create an application, one obviously needs to create a Facebook account, though that can be done anonymously.  The real issue is that in order to execute such an attack, one would need to make an application that is incredibly popular.  The attacker would need to devote a large number of resources to keeping such a popular app up, which would all need to be done anonymously (though would need to be paid for in one way or another).

Let’s say an attacker has gone through all of this to make a popular application: why doesn’t he/she just use those resources for a direct attack?  One possibly answer is that the Facebook DDoS would be hard to shut down, or better in some other way in executing the attack.  This is false because as soon as someone realizes that their traffic is coming from Facebook (whether by referrers, or FB trying to pull images for its cache, or some other mechanism), it can in most instances be stopped immediately, especially considering how most Facebook calls to other sites include the application’s API keys.  Even barring that, IP addresses and Facebook’s logging can be used to determine what application a user was in when they requested the victim’s site.

Additionally, DDoSs using this attack vector are relatively easy to mitigate.  If a hacker already has all of these resources dedicated to keeping an application up, why wouldn’t they just launch a TCP SYN flood or similar lower-level attack, much more potent DoSs, even if launched from a more limited IP range.

Let’s take a different route: suppose a hacker attacks one of Slide’s applications and somehow manages to break in and add an attack iframe.  This is a completely legitimate and anonymous way of attacking a site (though it begs the question of why the hacker didn’t just break into the target site in the first place, assuming both have similar levels of security).  While this is a legitimate issue, the same holds true for all websites.  Should someone hack into Yahoo! and figure out how to deploy a new home page (somewhere between almost-impossible and no-freaking-way on the difficulty scale), almost any site on the internet could easily be taken down.  I certainly hope top app developers take security as seriously as top website owners, but this is nothing special for Facebook.

On the topic of information theft, this is why Facebook requires you to explicitly permit an application to access your information.  The concept of an API implies this potential for theft…users are trusting applications to access their information and not keep it.  There is no way to prevent this for the same reason DRM doesn’t work: if people can view things they can store things.  While this is a legitimate concern, again it is nothing new, and not much can be done about it short of user education.

f8 Keynote Goof

During Ben’s talk at the f8 keynote they came to a slide where they discussed Academics, and listed a bunch of companies who were either teaching courses on Facebook (*cough*98-096*cough*) or doing research.  I know that Carnegie Mellon is doing research on Facebook, and have yet to find anything on Central Michigan doing such research.  Looks like someone screwed up when making this slide…they image searched CMU and pulled the wrong logo…

FB Ecosystem - Without Carnegie Mellon!

Live From f8

I’m sitting here in a front-row seat for the f8 keynote.  I’ll be keeping this post updated as interesting things happen…so stay tuned!

1:29 pm: Waiting for the talk to start…great seat!  Music is good but a little loud :-P

1:35 pm: Music out, Zuck in.  That is an amazingly hi-res projector!

1:36 pm: FB has been learning how to work with developers, made some mistakes along the way.

1:39 pm: FB mission: “Give people the power to share and make the world more open and connected.”

1:42 pm: 24mil users at f8 ’07, 90mil users now.  f8 ’07 US/International ratio was 50/50, now more like 30/60

1:44 pm: Opening up translation tool for platforms, they can use FB’s users to translate apps.

1:45 pm: Over 400k developers, more than half outside the US.

1:48 pm: Top 5k bands have more fans on iLike than anywhere else (including MySpace Music).  Causes app has more users than Al Gore’s alliance campaign (the two have since merged).

1:49 pm: Over 30 different developers have been funded to develop FB apps.  Flixter got $6m and Zynga raised $29mil just this morning.

1:54 pm: Lessons learned: Need to work more closely with developers.  Need to align incentives better, reward good apps, punish bad apps.

1:56 pm: Walking us through new FB, explaining the new Wall.

2:04 pm: “We’ll do it live!”, giving us a live tour of the new feed.

2:10 pm: Talking about the decentralization of social networking, comparing the social network movement to the PC movement.  FB expects in a few years all good applications and uses will come from sources other than FB, just utilizing their platform.

2:13 pm: FB Connect: Goals: Build the same kinds of apps across the web, share info across the web, control your info across the web.  3rd party sites can use it to pull profile info, friend lists, etc.  You can also send FB hashes of your users emails and it will tell you if they are FB users.

2:15 pm: “It goes to their profile, and Christmas is ruined.”  Zuck has a sense of humor…nice!

2:18 pm: Someone from Digg is on stage to demo the Digg/FB Connect inegration, nice, clean, and simple.

2:20 pm: Six Apart is next, demoing comment authentication with FB Connect, followed by Citysearch for reviews & recommendations.

2:26 pm: Profile is being rolled out over time, FB Connect Beta is today.

2:27 pm: That’s it for Zuck.  Ben Ling takes the stage.

2:32 pm: They had a slide that lists universities researching FB Apps…they used a logo from Central Michigan University instead of Carnegie Mellon!!!

2:38 pm: Talking about what makes great apps, building trust, etc.

2:46 pm: Talking about partnerships with MS, Joyent, and AWS.  New Developer Website (about time!).  Also promising to build up a team to work more closely with the community.  Applause for initial fbFund recipients, discussing Connected Weddings as an example.

2:48 pm: New program: giving out $2mil over the next 2 months.  25 finalists get $25k, 5 finalists (voted by community) get $250k.

2:49 pm: Announcing FB Verification program: Apps that feel they are Secure, Respectful, and Transparent can apply and be verified (they get a badge).  Verified apps get more visibility on the site.

2:50 pm: Announcing FB Great Apps program: Apps that feel they are super-awesome (10 criteria + history of adherence to policies + minimum user base).  Great Apps are more integrated and more trusted, as well as getting early access to new features and feedback directly from FB.  iLike & Causes are the first 2 Great Apps, though the program is in Alpha.

2:53 pm: Talking about a more transparent and consistant process for enforcing abuse policies.

2:56 pm: FB Connect will be released for Desktop, Web , and Mobile (they have an iPhone Cocoa API).

2:58 pm: FB Connect launches full on next summer.  There’s a hackathon today running until 9pm, winners announced at 11pm.  That’s all :).

Facebook: Sea Cow of the Internet

Update: Schrep (I’m far back right, he’s in the middle…note the ripped shirt, sorry Schrep!) was kind enough to point out that, as of bug 423377 being resolved, Firefox 3 defaults to 6 simultaneous connections.  Modern browsers all use different numbers, the lowest being IE 7 with 2 (all older browsers also use 2).

One of my projects here at Mozilla (and, coincidentally, a past project at Yahoo!) was improving ySlow scores.  ySlow is a utility that measures load time and analyzes page performance, assigning you a final letter grade based on various performance metrics.  It’s a neat little Firebug plugin, and I highly suggest that any web developer install it.

Occasionally I like to play with this tool on other big sites, just to see how many of them actually care about such things.  So I went through and ran ySlow on some of the more common Facebook pages.  Here’s what I found:

With most aspects Facebook does a decent job: with the exception of advertiser scripts and some application-specific code they use etags, minify their JS, and use long expires headers.  What amazed me is the number of JS and CSS files on each page, all listed one after another in the header:

Page JS Files CSS Files CSS BG Images
Homepage (logged out) 5 5 14
home.php 23 24 32
profile.php 26 21 36
photo_search.php 11 7 23
photo.php 18 8 26
friends 15 13 34

And for those curious, here’s the count for the new facebook design (summary: significantly worse):

Page JS Files CSS Files CSS BG Images
home.php 27 24 60
profile.php 45 13 67
photo.php 25 9 46
friends 26 19 57

Really, I can’t think of any context in which 47 external files would be necessary! I understand breaking files up by purpose to make coding and revision management easier, but I wonder if someone at some point considered the speed impacts. I’m fortunate enough to almost always have a broadband connection, but the experience for their dial-up users is probably deplorable. Especially considering that they now localize the site and are pushing to expand overseas, you would think this would be a much higher priority. And don’t even get me started about the lack of spriting!

Here’s how I setup Mozilla’s JS/CSS concatenation (see the Build Process):

  1. Add a configuration setting for site state (example: a flag set to “production” on production servers, “dev” on everything else)
  2. All CSS/JS calls use these flags to decide if they go to the concatenated files or the actual development files
  3. Create a build script that generates the concatenated files (profile.js, photo.js, etc), run before pushing to production

Ironically enough I would bet Facebook already has #1 and #2 setup, since they use Akamai for production servers, and can’t use that for development.

Alternatively they could use the method YUI uses for serving JS files.  Basically call a script that will return the concatenated files.  It’s a less elegant solution, and is heavier on the server, but still better than nothing.

Note that this doesn’t only affect dial-up users.  While broadband users usually have a fast enough connection to offset the slowdown, a large file count is the biggest slowdown for broadband.  This is because of the 2-simultaneous-connection limit that most browsers obey.  From rfc2068:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD maintain AT MOST 2 connections with any server or proxy.

Facebook.com is the 8th most popular site on the web, while Mozilla.org is the 258th (note that this is all of mozilla.org, not just addons.mozilla.org).  They should be able to devote a lot more to the tail end of their users, especially considering the residual benefits for their main audience.

Just as bad is their lack of proper fallback for those with JS disabled. For example, if you were to disable JS, you can still login fine, but once you login, head back to facebook.com. That’s right, they use JS to redirect users from their homepage, with no <noscript> fallback, meaning the average joe with JS disabled can easily lock himself out of Facebook.  In addition, pretty much every new feature added since poking doesn’t have a non-JS fallback.  Status updates, “People you may know”, dropdowns, the entire “Friends” page, and so on.  All completely useless.

SuperHappyDevHouse

Well, I just spent the day at SuperHappyDevHouse 19. Some highlights of the evening:

  • Having an hour-long conversation about dropping out of college, and again finding that everyone in the near vicinity feels that I should
  • Meeting an entrepreneur in silicon valley younger than I am
  • Being (easily) convinced by Chris Smoak (who doesn’t seem to have a blog…) that I am fully capable of implementing an Everyman sleep schedule while at college, which I intend to try
    • And realizing that Carnegie Mellon students/alum have almost as many internal acronyms as Yahoo.
  • Having a few people actually have read my blog before I met them (very cool and infrequent occurrence)
  • The “Hot Tub of Philosophy”

It’s definitely a great event worth checking out if you’re in the Bay Area, I know I’ll be going whenever I’m nearby.

Oh, and I found out via a former Facebook employee that Simon, the guy who sent me my Cease & Desist, is actually from customer service, not legal. What a shame…they couldn’t even take the time to sick a high-paid corporate lawyer on me…