Looking at Facebook’s Strategy and Possible New Directions

Over the last few months, Facebook has rolled out several significant new features, such as Places and the updated Groups. On Monday, Facebook is holding another event to announce what many expect to be an improved messaging feature. As I’ve watched these changes, I’ve been thinking about where Facebook might be headed.

At first, I started to think Facebook was simply looking to extend its reach by acting as an invisible layer of sorts. Anil Dash once talked about Facebook melting into the larger Web, but perhaps Facebook would end up becoming part of the underlying fabric of the Internet. In past public appearances, Facebook CEO Mark Zuckerberg seemed to be the kind of person who was content to remain in the background, and the company’s strategy seemed to reflect a similar style. I’ve mentioned before the idea of Facebook becoming and identity layer on the Internet, and innovations such as their Graph API have made it easier than ever for sites to integrate with Facebook.

But Facebook’s updated Groups feature changed my perspective, since it added functionality that would drive users back to facebook.com. Of course, the upgrade did enable e-mail as a way of interacting with groups. In some ways, Facebook’s overall strategy could be compared to Google’s. Years ago, many sites focused on “stickiness,” trying to keep users hooked. By contrast, Google drove users away by providing relevant links to other sites. But to see Google as non-sticky would be an oversimplification. In fact, the company built a successful ad network that extended its reach across the web. Also, Google has created a number of other products that many people stay logged into, such as Gmail.

And now, people are expecting Facebook to announce a web-based e-mail client that will compete with Gmail. I’m predicting that Facebook will roll out a new messaging system, but it won’t be a Gmail clone or simply another client for managing traditional POP/IMAP e-mail. That’s not to say there won’t be any e-mail gateway, but I think Facebook’s plans will go much further. I’m guessing that at least part of the new system will involve somehow extending private messaging features across Facebook-integrated websites.

In any event, I think Facebook’s announcement will include at least a few surprises for those who have been discussing the possibilities. Facebook has a history of introducing features that aren’t quite what people expected – and often end up leading to practical implementations of ideas that were previously niche experiments. Personally, I think it’s a bit short-sighted to think that Facebook would simply join the market for web-based e-mail without trying to reinvent it, especially given the service’s cautiousness about past features that allowed or potentially allowed spam-like behaviors.

Facebook has also been accused many times of somehow standing in opposition to “openness.” Personally, I think the term has become a buzzword that’s often used without much specificity. And even though I’ve often been a critic of Facebook, I do think many of the accusations aren’t entirely fair. From RSS feeds to developer APIs, Facebook has opened up data in ways that many other sites can’t claim. Today’s Facebook is certainly far more “open” that years ago – in fact, I would argue that the site has at times been too open lately, such as when some user data became reclassified as “publicly available” last fall. But regardless of Facebook’s degree of openness, the company has always been careful to maintain a high degree of control over information and features on the site. This can be positive, such as quickly removing malware links, or negative, such as controversial decisions to bar users or certain content.

Either way, that control has helped the site build a powerful database of profiles that generally reflects real people and real relationships. That’s part of what fascinated me about the site’s recent spat with Google over contact information. In the past, a list of e-mail addresses was about the only semi-reliable way to identify a group of people across the Internet. Now, many sites rely on Facebook’s social graph for that function. In terms of identity, the value of e-mail addresses has declined, and I don’t think exporting them from Facebook would provide as much value as Google might think. On the other hand, Google may realize this and be so concerned about the shift that they’re trying to curb Facebook’s influence. This would especially make sense if Google intends to introduce a more comprehensive social networking product that would need e-mail addresses as a starting point. Regardless, I’m sure Google feels threatened by the prospect of Facebook providing a better alternative to traditional e-mail – a change that would only bolster the value of a Facebook profile as the primary way to identify a typical Internet user.

Social Media Security Podcast 20 – FireSheep, Privacy in the US, What NOT To Post On Facebook

This is the 20th episode of the Social Media Security Podcast recorded November 5th 2010.  This episode was hosted by Tom Eston and Scott Wright. Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes and follow us on Twitter.  Thanks for listening!

Social Media Security Podcast 19 – New Changes to Facebook, Social Media Risk Survey, LinkedIn Scams

This is the 19th episode of the Social Media Security Podcast recorded October 8, 2010.  This episode was hosted by Tom Eston and Scott Wright. Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes and follow us on Twitter.  Thanks for listening!

Thoughts on the Wall Street Journal’s Facebook Investigation

A front-page story in last Monday’s Wall Street Journal declared a “privacy breach” of Facebook information based on an investigation conducted by the paper. The Journal found that third-party applications using the Facebook Platform were leaking users’ Facebook IDs to other companies, such as advertising networks.

The report generated controversy across the Web, and some reactions were strongly negative. On TechCrunch, Michael Arrington dismissed the article as alarmist and overblown. Forbes’ Kashmir Hill surveyed other responses, including a conversation on Twitter between Jeff Jarvis and Henry Blodget, and expressed skepticism over the Journal’s tone.

I’ve been a bit surprised by the degree to which some have written off the Journal’s coverage. Some may disagree with the label of “privacy breach,” but I thought the report laid out the issues well and did not paint the problem as a conspiracy on the part of Facebook or application developers. Either way, I’m glad to see that the article has sparked renewed conversation about shortcomings of web applications and databases of information about web users. Also, many may not realize that information leakage on the Facebook Platform has historically been even worse.

Information leakage via a referrer is not a new problem and can certainly affect other websites. But that doesn’t lessen the significance of the behavior observed in the WSJ investigation. Privacy policies are nearly always careful to note that a service does not transfer personally identifiable information to third parties without consent. Online advertising networks often stress the anonymity of their tracking and data collection. The behavior of Facebook applications, even if unintentional, violated the spirit of such statements and the letter of Facebook’s own policies.

Some people downplayed the repercussions of such a scenario on the basis that it did not lead to any “private” profile information being transferred to advertisers – a point Facebook was quick to stress. Yet when did that become the bar for our concept of acceptable online privacy? Should other services stop worrying about anonymizing data or identifying users, since now we should only be concerned about “private” content instead of personally identifiable information? Furthermore, keep in mind that Facebook gets to define what’s considered private information in this situation – and that definition has changed over the last few years. At one time in the not-too-distant past, even a user’s name and picture could be classified as private.

Many reactions have noted that a Facebook user’s name and picture are already considered public information, easily accessed via Facebook’s APIs. Or as a Facebook spokesmen put it, “I don’t see from a logic standpoint how information available to anyone in the world with an Internet connection can even be ‘breached.’” But this argument fails to address the real problem with leaked IDs in the referrer. The issue was not simply what data applications were leaking, but when and how that data was leaked. The problem was not that advertisers could theoretically figure out your name given an ID number – it’s that they were given a specific ID number at the moment a user accessed a particular page. Essentially, advertisers and tracking networks were able to act as if they were part of Facebook’s instant personalization program. Ads could have theoretically greeted users by name – the provider could connect a specific visit with a specific person.

Interestingly enough, many past advertisements in Facebook applications did greet users by name. Some ads also including names and pictures of friends. Facebook took steps several times to quell controversies that arose from such tactics, but I’m not sure many people understood the technical details that enabled such ads. Rather than simply leak a user’s ID, applications were actually passing a value called the session secret to scripts for third-party ad networks.

With a session secret, such networks could (and often did) make requests to the Facebook API for private profile information of both the user and their friends, or even private content, such as photos. Typically, this information was processed client-side and used to dynamically generate advertisements. But no technical limitations prevented ad networks from modifying their code to retrieve the information. In fact, a number of advertisements did send back certain details, such as age or gender.

Change to the Facebook Platform, such as the introduction of OAuth earlier this year, have led to the deprecation of session secrets and removed this particular problem. I’m not sure how much this sort of information leakage or similar security problems motivated the changes, but problems with session secrets certainly persisted quite a while prior to them. If the WSJ had conducted their study a year ago, the results could have been even more worrying.

Still, I’m glad that the Journal’s research has led many to look more closely at the issues they raised. First, the story has drawn attention to more general problems with web applications. Remember, the Web was originally designed for accessing static pages of primarily textual information, not the sort of complex programs found in browsers today. (HTML 2.0 didn’t even have a script tag.) Data leaking via referrers or a page’s scripts all having the same scope are problems that go beyond Facebook apps and will likely lead to more difficulties in the future if not addressed.

Second, people are now investigating silos of information collected about website visitors, such as RapLeaf’s extensive database. Several responses to the Journal piece noted that many such collections of data provide far more detail on web users and are worthy of greater attention. I agree that they deserve scrutiny, and now reporters at the Journal seem to be helping in that regard as well.

We’ve entered an age where we can do things never previously possible. Such opportunities can be exciting and clearly positive, but others could bring unintended consequences. I think the availability and depth of information about people now being gathered and analyzed falls into the latter category. Perhaps we will soon live in a world where hardly any bit of data is truly private, or perhaps we will reach a more open world through increased sharing of content. But I think it well worth our time to stop and think about the ramifications of technological developments before we simply forge ahead with them.

Over the last few years, I’ve tried to bring attention to some of the issues relating to the information Facebook collects and uses. They’re certainly not the only privacy issues relevant to today’s Internet users, and they may not be the most important. But I think they do matter, and as Facebook grows, their importance may increase. Similarly, I think it wrong to dismiss the Journal’s investigation as “complete rubbish,” and I look forward to the rest of the dialogue they’ve now generated.

Two New Social Media Security White Papers Released

My employer (SecureState) has released two white papers as part of our Social Media Security Awareness Month.  You can also download some cool wallpaper for this month created by Rob our graphic designer (see the picture on the right).  :-)

First is some research several of my colleagues and I worked on.  The paper is titled: “Profiling User Passwords on Social Networks”.  The paper discusses the password problem that we all know and love as well as how you can determine passwords by what individuals post on their profiles.  We dive into tools from Robin Wood, Mark Baggett and others that can be used to pull keywords from profiles and other sources to create wordlists.  These wordlists can be used for brute force attacks on user accounts.  Next, we look at password complexity of several popular social networks with some research around brute force controls that some of the social networks have implemented, or in some cases haven’t.  Lastly, we discuss some things that users of social networks can do when choosing passwords.  You can download my paper here.

The other paper released is titled: “Security Gaps in Social Media Websites for Children Open Door to Attackers Aiming To Prey On Children” by my colleague Scott White.  In his paper he looks at the security of social media websites specifically designed for children.  This is some very detailed research and sheds some light on how predators are using these sites to target children as well as some issues that are unique to these types of social media websites.  You can download Scott’s paper here.

Speaking of social media…I’ll be presenting “Social Impact: Risks and Rewards of Social Media” at the Information Security Summit this Friday at 10am.  I’ll have the slide deck posted shortly after the conference.

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favorites

Firs - http://www.spylogic.net/2010/10/two-new-social-media-security-white-papers-released/" title="Email this" rel="nofollow">EmailRSS


Instant Personalization Program Gets New Partner, Security Issue

Facebook announced last week that movie information site Rotten Tomatoes would join Docs.com, Pandora, and Yelp as a partner in the social networking service’s “instant personalization” program. Rotten Tomatoes will now be able to automatically identify and access public information for visitors logged in to Facebook, unless those users have opted out of the program. This marks the first new partner since Facebook launched the feature earlier this year.

Soon after that initial roll-out, security researchers noted vulnerabilities on Yelp’s website that allowed an attacker to craft pages which would hijack Yelp’s credentials and gain the same level of access to user data. TechCrunch writer Jason Kincaid reported on the cross-site scripting (XSS) holes, and made this prediction: “I suspect we’ll see similar exploits on Facebook partner sites in the future.”

Kincaid’s suspicions have now been confirmed, as the latest site with instant personalization also had an exploitable XSS vulnerability, which has now been patched. I’ll quickly add that Flixster, the company behind Rotten Tomatoes, has always been very responsive when I’ve contacted them about security issues. They have assured me that they have done XSS testing and prevention, which is more than could be said for many web developers. In posting about this issue, I primarily want to illustrate a larger point about web security.

When I heard about the expansion of instant personalization, I took a look at Rotten Tomatoes to see if any XSS problems might arise. I found one report of an old hole, but it appeared to be patched. After browsing around for a bit, though, I discovered a way I could insert some text into certain pages. At first it appeared that the site properly escaped any characters which could lead to an exploit. But ironically enough, certain unfiltered characters affected a third-party script used by the site in such a way that one could then execute arbitrary scripts. Since I had not seen this hole documented anywhere, I reported it to Rotten Tomatoes, and they promptly worked to fix it.

I’ve long argued that as more sites integrate with Facebook in more ways, we’ll see this type of problem become more common. Vulnerable applications built on the Facebook Platform provided new avenues for accessing and hijacking user accounts; now external websites that connect to Facebook open more possible security issues. As Kincaid noted in May, “Given how common XSS vulnerabilities are, if Facebook expands the program we can likely expect similar exploits. It’s also worth pointing out that some large sites with many Facebook Connect users – like Farmville.com or CNN – could also be susceptible to similar security problems. In short, the system just isn’t very secure.”

Overcoming such weaknesses is not a trivial matter, though, especially given the current architecture of how scripts are handled in a web page. Currently, any included script has essentially the same level of access and control as any other script on the page, including malicious code injected via an XSS vulnerability. If a site uses instant personalization, injected scripts can access the data used by Facebook’s code to enable social features. That’s not Facebook’s fault, and it would be difficult to avoid in any single sign-on infrastructure.

Of course, all of this applies to scripts intentionally included in the page as well, such as ad networks. With the Rotten Tomatoes roll-out, Facebook made clear that “User data is never transferred to ad networks.” Also, “Partner sites follow clear product/security/privacy guidelines,” and I assume Facebook is monitoring their usage. I’m not disputing any of these claims – Facebook is quite correct that advertisers are not getting user data.

But that’s due to policy limitations, not technical restrictions. Rotten Tomatoes includes a number of scripts from external sources for displaying ads or providing various functions. Any of these scripts could theoretically access a Facebook user’s information, though it would almost certainly be removed in short order. I did find it interesting that an external link-sharing widget on the site builds an array of links on the page, including the link to a user’s Facebook profile. This happens client-side, though, and the data is never actually transferred to another server.

I bring up these aspects simply to note the technical challenges involved in this sort of federated system. I think it’s very possible that we will eventually see ad network code on a Facebook-integrated site that tries to load available user data. After all, I’ve observed that behavior in many Facebook applications over the last few years – even after Facebook issued explicit policies against such hijacking.

These dangers are part of the reason why JavaScript guru Douglas Crockford has declared security to be the number one problem with the World Wide Web today. Crockford has even advocated that we halt HTML5 development and focus on improving security in the browser first. While that won’t likely happen, I think Crockford’s concerns are justified and that many web developers have yet to realize how dangerous cross-site scripting can be. Perhaps these issues with instant personalization sites will help increase awareness and understanding of the threat.

Postscript: This morning, an XSS vulnerability on Twitter led to script-based worms (somewhat reminiscent of “samy is my hero”) and general havoc across the site. This particular incident was not related to any mashups, but once again emphasizes the real-world security ramifications of cross-site scripting in a world of mainstream web applications.

Update (Sep. 27): Today news broke that Scribd had also become part of Facebook’s Instant Personalization program. I took a look at the site and discovered within minutes that it has a quite trivial XSS vulnerability. This particular issue should have been obvious given even a basic understanding of application security. It also indicates that Facebook is not doing much to evaluate the security of new instant personalization partners. Update 2: Scribd patched the most obvious XSS issue right about the time I updated this post: entering HTML into the search box brought up a page that loaded it unfiltered. Another search issue remained, however: starting with a closing script tag would still affect code later in the results page. After about half an hour, that problem was also patched. I’m glad Scribd moved so quickly to fix these problems, but I still find it disconcerting they were there to start with. I’ve not done any further checking for other XSS issues.

Social Media Security Podcast 18 – RFID and Facebook, Hacking Facebook Places, MySpace Privacy

This is the 18th episode of the Social Media Security Podcast recorded September 3, 2010.  This episode was hosted by Tom Eston and Scott Wright and is our 1 year anniversary episode!  Thanks to everyone that has supported the podcast over the last year…we really appreciate it!  Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes and follow us on Twitter.  Thanks for listening!

Link Hygiene – the same old risks apply to newly launched services like Ping for iTunes

As each major player in today’s technology and Web-connected world makes a move to get a bigger piece of the social networking pie, they take on new risks they haven’t seen before. But if they only looked around, they’d be able to see and learn from the mistakes of others.

This week Apple launched “Ping”, a new social network that serves the iTunes community. But they don’t seem to have learned much from those that have ventured into this space before them. The Ping forums are being bombarded with spam posts containing phishing links. As blogger Chester Wisniewski, from antivirus maker Sophos points out, “Did they not see this coming?” (click HERE).

While Apple should have anticipated the problems, and tried a bit harder to protect legitimate users from this unwanted content, my advice to users is the same as for any social network: Use good link hygiene.

What is Good Link Hygiene?

Link hygiene is something we all need to practice on a daily basis, whether it’s while we’re reading Email or browsing social networks. It’s about avoiding the risks associated with malicious sites and content, as well as malicious file attachments.

There are many different ways in which hackers and scammers can trick you into giving them access to valuable information and computer resources.

Here are four of the nine items I teach people to check for when it comes to link hygiene which can reduce the risks of becoming a victim from malicious content in Email and websites:

1) Are your Email configuration options set to disable previewing of content or loading of images?

2) Is your computer’s operating system and application software (e.g. browser, Adobe Reader) up to date?

3) Do you have a reputable anti-malware product with up to date patches and virus signatures on your computer?

4) Do you know what your anti-malware product’s alerts look like, so you can recognize most fake virus alerts?

 So, Apple – as well as other social networks – should take some blame for allowing their social network to become polluted with malicious content. However, it’s almost impossible for sites to eliminate these risks entirely. It’s up to us, the users, to stay vigilant, and know how to avoid becoming a victim.


If you’re a Business Premium member of the Streetwise Security Zone, you can download the PDF version of this month’s coaching content on Link Hygiene by clicking HERE. This lesson includes a discussion of the various ways in which hackers and spammers try to trick you into going to malicious sites or entering sensitive information into fake forms.


I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…

Scott Wright

The Streetwise Security Coach

Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html

Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec

To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.

 

 

Site Meter

1 4 5 6 7 8 35