Intro to trouble: LinkedIn and trusting the cloud (part I)

It has been a tough start for LinkedIn’s Intro feature, designed to add contact information from the social networking site to email messages. The project was announced on the company engineering blog with much fanfare, chronicling the challenges faced in implementing the concept on iOS. Whatever the technical complexity and virtuosity involved in pulling this together, the main reaction was one of skepticism and outright hostility from the security research community. In particular Bishop Fox eviscerated the concept in a detailed point-by-point critique and LinkedIn responded with another blog addressing technicalities while dancing around the fundamental question of trust.


Before discussing the problem with Intro, let’s dispense with one non-reason that appears to be dredged up in every article covering the feature. LinkedIn suffered a massive password breach in 2012, netting the company a Pwnie award nomination for Most Epic Fail. Incidents or lack thereof is not a good metric for evaluating the security of a service. While a data breach usually implies the existence of weaknesses and defects in the defenses, whether or not someone gets around to exploiting an existing weakness is influenced as much by sheer luck. Granted there were disturbing signs in this episode indicating that suboptimal design played a significant role in amplifying the damage: the way LinkedIn stored passwords violated industry best practices. There was no salt applied to diversify passwords before hashing. Just 1 iteration of the hash function was used instead of iterating thousands of times to slow down guessing.

That was not an isolated instance when it comes to questionable decisions on the security front. As noted earlier the service continues to use the password anti-pattern, phishing users for their passwords on other sites instead of adopting the industry standard Oauth protocol for constrained access to user data at those sites.

Still, there is a statute of limitations for incidents. It is not rational risk-management to reject every new offering from a company on the basis of one incident or for that matter, failure to follow optimal security design in one feature to color judgments about every other one. This post will give LinkedIn a free pass for such transgressions and evaluate Intro on its own terms.

Fundamental problem with Intro

Key observation about Intro is that the functionality is not implemented locally. In order for this email rewriting to take place, the message is sent out to LinkedIn servers, modified there in the cloud and then returned to the user. This means that LinkedIn servers get access to every single message sent to that particular email account. The difference is best explained by contrasting it with two other common systems that operate on email messages.

Gmail keyword advertising

Since 2004, GMail has been controversial for offering targeted advertising based on keywords in email. Strictly speaking GMail does not tamper with messages unlike LInkedIn Intro. Sponsored advertising appears off to the side, in a clearly demarcated area. Still the experience of the user– something Microsoft repeatedly capitalized on in the Scroogled series of TV commercials– is that their messages are being “read.” Why is Gmail keyword scanning not a security risk? (Even though it may well be construed a significant privacy infringement.) Because Google servers already have access to the email message. There is no new user data being made available to Google in order for their servers to decide which advertisements will be displayed alongside the message. This stands in sharp contrast with LinkedIn situation: before using Intro, LinkedIn did not have access to emails sent/received. It is the act of installing Intro that causes otherwise private messages to start flowing through LinkedIn servers.


Another example of software which does in fact modify email messages are PGP and S/MIME extensions for email. Both are standards for adding encryption and digital signatures to messages. Sometimes the functionality is built into an email client: MSFT Outlook has S/MIME. In other cases it is a third-party extension that integrates with an existing email application. For example GPGtools hooks into the standard Apple mail client on OS X.

So what is the difference between installing Intro on iOS versus installing a GPG client for OS X integrates with the built-in mail application? GPG clients operate locally. No data is ever shipped to a third-party in the cloud. (Incidentally the reason LinkedIn implemented Intro as a remote service is that iOS mail application lacks the necessary extensibility mechanism for other local applications to hook into the email processing pipeline.)

Local vs cloud

Having a local application does not completely eliminate the trust question. Users still have to trust the author of the software. After all that code could secretly leak a copy of every message to a server in China or rootkit the machine. But such properties can be verified locally. A complete copy of the implementation is available for direct observation. It can be debugged, audited, reverse-engineered if necessary– many versions are open-source so they can be audited directly. It can be tweaked to run with reduced privileges in a sandboxed environment. More importantly for the purpose of future-proofing trust decision, there are strong assurances in place that these properties will not change magically. Users retain visibility and control over changes to the application going forward. If the software publisher decides to go rogue or is compelled by law enforcement to start installing spyware on user machines, they will be going through a public process of pushing out malicious updates. This is conceivable but much harder to hide compared to making equivalent changes behind closed doors inside a datacenter.

Leaps of faith

By definition, critical parts of the Intro implementation belong in the cloud inside LinkedIn data centers. Regardless of how much LinkedIn swears up and down that this environment has necessary safeguard (the blog cites an iSEC audit but it is telling that iSEC Partners itself has not come forward to defend the design) that aspect remains a blackbox for anyone who is not directly affiliated with the company. A significant leap of faith is required to accept that all is well inside that blackbox not just in the present moment, but indefinitely into the future.

Granted such leaps of faith are made all the time when adopting cloud computing. Gmail users have made a decision (perhaps implicitly and without spelling out the full consequences) that it is acceptable level of risk for Google to have access to their written communications. Ascertaining whether the same risk can be justified for Intro calls for stepping back to examine the broader question of how trust decisions are made.



Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s