LinkedIn Intro is Unethical Software

LinkedIn Intro is a mail filtering service provided by LinkedIn that inserts LinkedIn relationship data into the user's incoming and outgoing mail. This allows, for example, LinkedIn to decorate incoming mail with a toolbar linking to the sender's LinkedIn account, and automatically injects a short “signature” of your LinkedIn profile into outgoing mail.

These are useful features, and the resulting interaction is quite smooth. However, the implementation has deep, unsolvable ethical problems.

LinkedIn Intro reconfigures the user's mobile device, replacing their mail accounts with proxy mail accounts that use LinkedIn's incoming and outgoing mail servers. All of LinkedIn's user-facing features are implemented using HTML and JavaScript injected directly into the email message.

Password Concerns

LinkedIn Intro's proxy mail server must be able to log into the user's real incoming mail server to retrieve mail, and often must log into the user's real outgoing mail server to deliver mail with correct SPF or DKIM validation. This implies that LinkedIn Intro must know the user's email credentials, which it acquires from their mobile device. Since this is a “use” of a password, not merely a “validation” of an incoming password, the password must be available to LinkedIn as plain text. There are two serious problems with this that are directly LinkedIn's responsibilty, and a third that's indirect but important. (Some email providers - notably Google - support non-password, revokable authentication mechanisms for exactly this sort of use. It's not clear whether LinkedIn Intro uses these safer mechanisms, but it doesn't materially change my point.)

LinkedIn has a somewhat unhappy security history. In 2012, they had a security breach that exposed part of their authentication database to the internet. While they have very likely tightened up safeguards in response, it's unclear whether those include a cultural change towards more secure practices. Certainly, it will take longer than the year that's passed for them to build better trust from the technical community.

Worse, the breach revealed that LinkedIn was actively disregarding known problems with password storage for authentication. Since at least the late 70's, the security community has been broadly aware of weaknesses of unsalted hash-based password obfuscation. More recently, it's become clear that CPU-optimized hash algorithms (including MD5 and both SHA-1 and SHA-2) are weak protection against massively parallel password cracking — cracking that's quite cheap using modern GPUs. Algorithms like bcrypt which address this specific weakness have been available since the late 90's. LinkedIn's leaked password database was stored using unsalted SHA-1 digests, suggesting either a lack of research or a lack of understanding of the security implications of their password system.

Rebuilding trust after this kind of public shaming should have involved a major, visible shift in the company's culture. There's easy marketing among techies — a major portion of LinkedIn's audience, even now — to be done by showing how on the ball you can be about protecting their data; none of this marketing has appeared. The impact of raising the priority of security issues throughout product development should be visible from the outside, as risky features get pushed aside to address more fundamental security issues; no such shift in priorities has been visible. It is reasonable, observing LinkedIn's behaviour in the last year, to conclude that LinkedIn, as a company, still treats data security as an easy problem to be solved with as little effort as possible. This is not a good basis on which to ask users to hand over their email passwords.

While the security community has been making real efforts to educate users to use a unique password for each service they use, the sad reality is that most users still use the same password for everything. As LinkedIn Intro must necessarily store plain text passwords, it will be a very attractive target for future break-ins, for employee malfeasance, and for United States court orders.

What Gets Seen

LinkedIn Intro is not selective. Every email that passes through an Intro-enabled email account is visible, entirely, to LinkedIn. The fact that the email occurred is fodder for their recommendation engine and for any other analysis they care to run. The contents may be retained indefinitely, outside of either the sender's or the recipients' control. LinkedIn is in a position to claim that Intro users have given it permission to be intrusive into their email in this way.

Very few people use a dedicated email account for “corporate networking” and recruiting activities. A CEO (LinkedIn's own example) recieves mail pertaining to many sensitive aspects of a corporation's running: lawsuit notices, gossip among the exec team, planning emails discussing the future of the company, financials, email related to external partnerships at the C*O level, and many, many other things. LinkedIn's real userbase, recruiters and work-seeking people, often use the same email account for LinkedIn and for unrelated private activities. LinkedIn has no business reading these emails or even knowing of their existence, but Intro provides no way to restrict what LinkedIn sees.

Users in heavily-regulated industries, such as health care or finance, may be exposing their whole organization to government interventions by using Intro, as LinkedIn is not known to be HIPAA, SOX, or PCI compliant.

The resulting “who mailed what to whom” database is hugely valuable. I expect LinkedIn to be banking on this; such a corpus of conversational data would greatly help them develop new features targetting specific groups of users, and could improve the overall effectiveness of their recommendation engine. However, it's also valuable to others; as above, this information would be a gold mine for marketers, a target for break-ins, and, worryingly, immensely useful to the United States' intelligence apparatus (who can obtain court orders preventing LinkedIn from discussing their requests, to boot).

(LinkedIn's recommendation engine also has issues; it's notorious for recommending people to their own ex-partners and to people actively suing one another. Giving it more data to work with makes this more likely, especially when the data is largely unrelated to professional concerns..)

LinkedIn Intro's injected HTML is also suspect by default. Tracking email open rates is standard practice for email marketing, but Intro allows LinkedIn to track the open rate of emails you send and of emails you recieve, regardless of whether those emails pertain to LinkedIn's primary business or not.

User Education

All of the risks outlined above are manageable. With proper information, the end user can make an informed decision as to whether

LinkedIn's own marketing materials outline absolutely none of these risks. They're designed, as most app landing materials are, to make the path to downloading and configuring Intro as smooth and unthreatening as possible: the option to install the application is presented before the page describes what the app does, and it never describes how the app works — that information is never stated outright, not even in Intro's own FAQ. Witholding the risks from users vastly increases the chances of a user making a decision they aren't comfortable with, or that increases their own risk of social or legal problems down the road.

LinkedIn's Response

Shortly after Intro's first round of public mockery, a LinkedIn employee posted a response to some of the security concerns. The post is interesting, and I recommend you read it.

The key point about the response is that it underscores how secure Intro is for LinkedIn. It does absolutely nothing to discuss how LinkedIn is curating its users' security needs. In particular:

We isolated Intro in a separate network segment and implemented a tight security perimeter across trust boundaries.

A breach in LinkedIn proper may not imply a breach in LinkedIn Intro, and vice versa, but there must be at least some data passing back and forth for Intro to operate. The nature and structure of the security mechanisms that permit the “right” kind of data are not elaborated on; it's impossible to decide how well they actually insulate Intro from LinkedIn. Furthermore, a breach in LinkedIn Intro is still incredibly damaging even if it doesn't span LinkedIn itself.

Our internal team of experienced testers also penetration-tested the final implementation, and we worked closely with the Intro team to make sure identified vulnerabilities were addressed.

This doesn't address the serious concerns with LinkedIn Intro's intended use; it also doesn't do much to help users understand how thorough the testing was or to understand who vetted the results.

The Bottom Line

If LinkedIn Intro works as built, and if their security safeguards are as effective as they claim and hope, then Intro exposes its users to much greater risk of password compromise and helps them expose themselves to surveillence, both government and private. If either of those conditions does not hold, it's worse.

The software industry is young, and immature, and wealthy. There is no ethics body to complain to; had the developers of Intro said “no,” they would very likely have been replaced by another round of developers who would help LinkedIn violate their users' privacy. That does not excuse LinkedIn; their product is vile, and must not be tolerated in the market.