Burton Group Identity Blog

Beyond Privacy Mirror

Blogger: Ian Glazer

Over the last two weeks, I have been using my homegrown Facebook application, Privacy Mirror, as a means of experimenting with Facebook’s privacy settings. Although Facebook provides a nice interface to view your profile through your friends’ eyes, it does not do the same for applications. I built Privacy Mirror with the hopes of learning what 3rd party application developers can see of my profile by way of my friends’ use of applications. I have yet to speak with representatives of Facebook to confirm my findings, but I am confident in the following findings.

Imagine that Alice and Bob are friends in Facebook. Alice decides to add a new application, called App X, to her profile in Facebook. (For clarity's sake, by "add", I mean that she authorizes the application to see her profile. Examples of Facebook applications include Polls, Friend Wheel, Movies, etc.) At this point, App X can see information in Alice’s profile. App X can also see that Alice is friends with Bob; in fact, App X can see information in Bob’s profile. Bob can limit how much information about him is available to applications that his friends add to their profiles through the Application Privacy settings. In this case, let's imaging that Bob has only allowed 3rd party applications to see his profile picture and profile status.

After a while, Alice tells Bob about App X. He thinks it sounds cool and adds it to his profile. At this point if App X, via Alice’s profile, looks at Bob’s profile it will see not only his profile picture and status but also his education history, hometown info, activities and movies. That is significantly more than what he authorized in his Application privacy settings. What is going here?

It appears what's going on is that if Alice and Bob both have authorized the same application, that application no longer respects either user's Application Privacy settings. Instead, it respects the Profile Privacy settings of each person. In essence, App X acts (from a privacy settings point of view) as if it were a friend of Alice and Bob and not a third-party application.

Putting my privacy commissioner hat for a moment, I’d want to analyze this situation from a consent and disclosure perspective. When Bob confirms his friendship with Alice he is, in a sense, opting in to a relationship with her. This opt-in indicates that he is willing to disclose certain information to Alice. Bob can control what information is disclosed to Alice through his Profile Privacy settings and this allows him to mitigate privacy concerns he has in terms of his relationship with Alice.

What Bob isn’t consenting to (and is not opting in to) is a relationship with Alice’s applications. Bob is completely unaware of which applications Alice currently has or will have in the future. This is an asymmetry of relationship. It is entirely possible that Alice and Bob will have applications in common and once they do the amount of profile information disclosed (by both of them) to an application can radically change and change without notice to either Alice or Bob. Furthermore, it is unclear which Facebook privacy settings Bob needs to manipulate to control what Alice’s applications can learn about him.

This lack of clarity is harmful. It shouldn’t take a few hundred lines of PHP, three debuggers, and an engineering degree to figure out how privacy controls work. This lack of clarity robs Facebook users of the opportunity to make meaningful and informed choices about their privacy.

This experiment started after I read the Canadian Privacy Commissioner’s report of findings on privacy complaints brought against Facebook. This report raised significant concerns about third-party applications and their access to profile information.

As of the beginning of Catalyst (today!), Facebook has about 15 days remaining to respond to the Canadian Privacy Commissioner’s office, I hope that this issue about third party applications and privacy controls is meaningfully addressed in Facebook's response.

Rounding out the privacy agenda at Catalyst: US-VISIT

Blogger: Gerry Gebel

We are very pleased to have Bob Mocny, director of DHS’s US-VISIT program speaking during the privacy track next Friday, July 31. Bob’s abstract, listed below, fills out an incredible privacy agenda and ensures that you will be handsomely rewarded if you stay for the full Catalyst conference. Privacy debates abound in many circles and you’ll hear several next week as speakers from Covisint, Future Identity, UCLA, Georgetown University, and Google share their issues, concerns, and opinions of privacy.

Mr’s Mocny’s session info:
A Dual Mission: Identity Management and Privacy Protection in the Federal Government

Advances in identity management technology are providing significant security benefits to the U.S. government. At the same time, federal privacy statutes require the protection of personally identifiable information collected, stored and accessed by government officials. Learn how one federal program is successfully integrating the use of biometric technology and privacy protection requirements to enhance the nation’s security. Robert Mocny, director of the U.S. Department of Homeland Security’s USVISIT program—one of the world’s largest biometric identity management systems—will discuss how the program’s privacy strategies earn public trust and contribute to the overall success of the program. The practices employed by USVISIT are applicable in both public and private sectors and important for everyone involved in developing and implementing identity management systems.

Laplace’s Demon, Santa Claus and TSA’s Secure Flight

Blogger: Ian Glazer

No doubt you frequent fliers out there have received emails from your airline of choice talking about TSA’s Secure Flight. As you make air travel reservations in the future, your airline will communicate with TSA to get, essentially, a fly/no-fly decision from the Secure Flight system. As the TSA explains in the “How it works” section of their website dedicated to Secure Flight:

Secure Flight matches the name, date of birth and gender information for each passenger against government watch lists to:

• Identify known and suspected terrorists

•  Prevent individuals on the No Fly List from boarding an aircraft

• Identify individuals on the Selectee List for enhanced screening

• Facilitate passenger air travel

• Protect individuals' privacy

After matching passenger information against government watch lists, Secure Flight transmits the matching results back to aircraft operators.

Did you notice the extreme use of irony there? Secure Flight is used to “facilitate passenger air travel” and yet Secure Flight’s sole purpose is to keep people off of planes. (I think someone at the TSA doesn’t know what facilitate means.) Irony aside, Secure Flight is ignorant of (or at least tone-deaf to) the US’ strong social and legal tradition of freedom of movement.  Secure Flight can act as a preemptive refusal of air travel in the absence of due process, which contravenes citizens’ freedom of movement.

Let’s talk about Pierre-Simon Laplace for a second. The French mathematician and astronomer described “an intellect” so vast that it knew the location and momentum of every atom in the universe. With this knowledge, this intellect (latter dubbed Laplace’s Demon by biographers) could know the future. As he wrote:

We may regard the present state of the universe as the effect of its past and the cause of its future. An intellect which at a certain moment would know all forces that set nature in motion, and all positions of all items of which nature is composed, if this intellect were also vast enough to submit these data to analysis, it would embrace in a single formula the movements of the greatest bodies of the universe and those of the tiniest atom; for such an intellect nothing would be uncertain and the future just like the past would be present before its eyes.

So with two attributes, location and momentum, Laplace’s Demon can know the future. With gender and birthday (along with name), Secure Flight can know bad guys from good guys and keep them off a plane.

The problem is that neither work. Laplace’s Demon has been slain multiple times. Secure Flight and the No-Fly List have and will continue to suffer the same fate.

Nations (UK, Israel, the US) and Agencies (DHS), like malevolent Santa Clauses, are building multiple mother-of-all naughty-and-nice lists. Their slavish devotion to Laplace’s Demon fuels their hopes that by knowing everyone’s name (and other attributes) they somehow can predict (and in some cases, prevent) the future. Hubris and ignorance are the twin attributes of such plans and neither ought to have a place in the programs of civil societies.

Silver Bullet Podcast Interviews Bob Blakley

Blogger: Bob Blakley

Gary McGraw, Cigital CTO and software security guru, interviewed me last week in the 40th installment of his Silver Bullet podcast.  We covered a wide variety of topics, from the failure of information security, to privacy, to why it's a tragedy that rhetoric is no longer taught in the schools.  I'll warn you in advance that clicking the link may be hazardous to your productivity; I listened to 7 or 8 of the other podcast episodes last night - it's a great series.

Twitter: A Tragedy of Errors

Blogger: Mark Diodati

The number of Twitter data breaches seems to be increasing. I’d like to focus on several of them, described here and here. Both breaches were exploits based upon social engineering.

In both cases, a hacker compromised the Yahoo mail accounts associated with Twitter employees (a product manager and an administrator) by guessing the answer to each employee’s secret question. The secret question is an example of static knowledge-based authentication (KBA), the insufficiency of which Burton Group has discussed (Can We Finally Commit to the End of Knowledge-Based Authentication? and Static KBA: Lipstick on the Weak-Authentication Pig). The latter blog entry discusses the same exploit on Sarah Palin’s Yahoo mail account. Both Google and Yahoo support a better identity proofing mechanism – Short Message Service (SMS) delivery via mobile phone. Burton Group calls this mechanism out-of-band identity proofing, and it is a big step up from static KBA. I recommend that register your mobile phones for these services ASAP.

The hacker associated with the first breach claims to have located the product manager’s Twitter password in the Yahoo emails. This seems unlikely. However, Twitter enables a password reset by other means. First the user must provide Twitter with the pre-registered phone number in the “forgotten password” web form. Twitter asks for the phone number solely as an answer to static KBA question, and does not use the phone in the identity proofing process. The hacker does not need physical access of the phone, only knowledge of the correct phone number. After providing the correct phone number, Twitter sends an email with a link to the password reset screen. If the hacker has compromised the email account and knows the phone number, he now has access to the Twitter account.

If Twitter’s password reset process applies to its administrative applications, Twitter’s risk exposure is “sky high”. Burton Group believes that stronger authentication mechanisms are a requirement for administrators who access confidential user data via the Internet. There are plenty of cost-effective, portable stronger authentication solutions. Examples include delivery of a one-time password (OTP) via SMS (as described above) and software OTP on a mobile device. These solutions would eliminate these exploits because the compromise of the email account does not give the hacker access to the authenticator.

In the first breach, the hacker claims that once he had access to the Twitter administrative application, he was able to access confidential information about Twitter users. If this is the case, it presents one final question: why does a product manager have access to a production system with confidential user data? If this is the case, it seems like an issue of excessive privileges.

Personal Privacy Impact Assessments for Facebook

Blogger: Ian Glazer

I’m reading Canada’s Assistant Privacy Commissioner Elizabeth Denham’s recently released findings into complaints levied against Facebook. (Report of Findings into the Complaint Filed by the Canadian Internet Policy and Public Interest Clinic (CIPPIC)against Facebook Inc. Under the Personal Information Protection and Electronic Documents Act.) My first reaction to this is, frankly, one of jealousy. I wish we had a similar commissioner/czar/wonk here in the US. I suppose elements of the FTC work in this regard but without the same charter, which is too bad.

Section 4 of the report is, for me, where the action is at. Section 4 is concerned with 3rd party application in Facebook and use of personal data by those applications. As the Facebook platform grows with new additions like Facebook Connect, issues of third-party access to user information will continue to be a concern to those who pay attention to such things. There’s a challenge here as the ways in which 3rd party applications use user information is hard to decipher, as it is, from an end-user perspective, a fairly black-box operation.

I wonder if Facebook could build a personal privacy impact assessment (PPIA) app. The PPIA would analyze the action you are about to take on Facebook, your privacy settings, the 3rd party apps you’ve allows access to your profile, and the privacy settings you have set for those apps. The PPIA could give you a quick read on which applications would be privy to the action you are about to do. It could indicate which groups of friends (based on your privacy settings) would see what you are about to do. Essentially, it would let you see across how much of your social graph a certain action (like posting a link or photo) will travel.

We all have PPIAs built in - one that is cultivated through social interactions schooled by social norms. When it comes to dealing with large systems, like Facebook, big business, or the government for that matter, we all can use a little help.  I wonder if someone can get a PPIA prototype up ahead of Catalyst to at least give me a warning about potentially embarrassing photos being posted somewhere…

Cloud SSO Interop Demonstration

Blogger: Gerry Gebel

If it's time for Catalyst, then it must be time for another interoperability demonstration! This year we are focusing on standards-based single sign-on to off-premise or cloud hosted applications. Of course cloud computing is all the rage this year and many enterprises are pursuing the benefits of utilizing SaaS applications plus directly accessing with more of their partner's applications. Such application scenarios can create additional usability and administrative burdens - and the purpose of this demonstration is to highlight how federation standards address the usability concerns.

Federation standards, such as SAML, WS-Federation and even OpenID and information cards can and are being used for authentication of users to off-premise applications. This demo focuses the attention to SaaS or cloud hosted applications and attempts to meet several goals, including:

- Show that federation standards are mature technologies, usable in many scenarios
- Illustrate that SaaS application vendors are already using federation standards
- Emphasize that enterprises should require SaaS support standards for SSO

In the past, interoperability demonstrations typically utilize a sample application during testing. This year, the demo includes real commercial applications - thanks to participants such as Cisco WebEx, Exostar (hosted SharePoint), eXpresso Corp, Google Apps, PivotLink, SalesForce, and even Burton Group's client web site. Other participants contributing from the federation software side include Arcot, CA, Cloud Identity, FuGen Solutions, IBM, Microsoft, Novell, OpenIAM, Ping Identity, RSA, Siemens, Sun Microsystems, Symplified, and TriCipher. FuGen Solutions and JanRain have also been developing some advanced scenarios to demonstrate how higher levels of assurance can be achieved in a federated authentication. Other organizations that have also participated include Azigo, Information Card Foundation, Microsoft Live ID, MySpace, Plaxo, and Yahoo!. Many thanks to all the participants who have been working over the last few months to bring this interop together!

A special shout also goes to Ping Identity, TriCipher, Symplified, and CA for their sponsorship to help cover interop expenses! Other sponsorships still available...

So, the interop demonstration is another reason to join us in San Diego for Catalyst - hope to see you there! Catalyst takes place July 27-31 and the demonstration will occur on the evening of July 29.