Tag: authentic8
When LinkedIn posted LinkedIn Intro: Doing the Impossible on iOS I was intrigued. The post title was provocative (presumably as intended) and drew a lot of attention from various people in the security world. Several of these posts were deeply critical which generated another post from LinkedIn titled The Facts about LinkedIn Intro. By this point I had sent emails to several of my friends who were experts in the email / SMTP / IMAP / security ecosystem and was already getting feedback that generally trended negative. And then I saw this post titled Phishing With Linkedin’s Intro – a clever phishing attack on Intro (since fixed by LinkedIn).
All of this highlights for me my general suspicion around the word “impossible” along with the complexity that is increasing as more and more services interconnect in non-standard ways.
One of the thoughtful notes I got was from Scott Petry – one of my good friends and co-founder of Authentic8 (we are investors). Scott co-founded Postini and a bunch of email stuff at Google after Google acquired Postini in 2007. Following are his thoughts on LinkedIn Intro.
I am all for seamless integration of services. And while “man in the middle” is commonly seen as a pejorative, the MITM approach can enable integrations that weren’t readily available previously.
Postini, which started life as a spam filtering service became a huge email MITM enabling all sorts of email processing not available on the mail server itself. Seamless integration was a big part of our success – companies pointed their mx record to Postini, Postini filtered and passed the good stuff on to the company’s mail server. While controversial in 1999, DNS redirect-based services have become accepted across all ports and protocols. Companies such as Cloudflare, OpenDNS, Smartling, and more all offer in-line services that improve the web experience through DNS-level MITM-type model. Simple to configure and high leverage. They just aren’t thought of as MITM services.
Extending functionality of services by authorizing plug-ins to gain access to your data can be really useful as well. I use Yesware in Gmail to help track messages and automate responses when I send company-related marketing/sales emails. It’s a great service, enabling functionality not previously available, and you could think of this as a man in the middle as well. It is important to point out that in the case of Yesware and DNS style integrations, I need to explicitly approve the integration. The details are made available up front.
New levels of integrated services are coming online daily. And vendors are getting more and more clever with APIs or skirting them altogether in order to get their app in front of us. It’s natural to be sucked in by the value of these services and it’s easy to overlook any downside. Especially given that for many of them, the people who are paid to think about security ramifications aren’t in the loop. They can be installed and configured by end users, not IT. And most users take the security for granted … or overlook it all together.
Last week, on the LinkedIn engineering blog, details on the new LinkedIn Intro app were shared. Intro integrates dynamic LinkedIn profile information directly into the iOS email app. It didn’t get much attention when it was launched, but once the engineering team blogged about how did the impossible to integrate with the iOS email client, the story blew up.
Details on their approach here (https://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios).
LinkedIn Intro does a beautiful job of auto-discovering your environment and auto-configuring itself. A click or two by the user, and they’re up and running with active LinkedIn data in their email app.
All this clever engineering hides the fact that LinkedIn is accessing your email on your behalf. Intro uses an IMAP proxy server to fetch your mail where they modify it, then deliver it to your iPhone. Classic Man in the Middle.
If you remember setting up your mail service on your iPhone, it is a bit clunky. You need to know the host names of your service, the ports, encryption values, etc. It isn’t easy. But you don’t do any of this with Intro. Instead of going through the usual configuration screens on iOS, Intro uses Apple’s “configuration profiles” capability auto discover your accounts and insert their servers in the middle. And since it uses OAuth to log in, it doesn’t even need to ask for your credentials.
They do such a good job of hiding what they’re doing that the significance of the data issues were lost on everyone (except the security researchers who raised the brouhaha).
This weekend, LinkedIn made another blog post. In their words, they wanted to “address inaccurate assertions that have been made” and “clear up these inaccuracies and misperceptions”. The post, here (https://blog.linkedin.com/2013/10/26/the-facts-about-linkedin-intro/) followed the PR playbook to the letter.
With one small exception concerning a profile change, the post does nothing to clear up inaccuracies and misperceptions. Instead, their post lists their reassurances about how secure the service is.
Even with these assurances, the facts remain. LinkedIn Intro pipes your email through their servers. All of it. LinkedIn Intro inserts their active web content into your email data. At their discretion.
With its clever engineering, Intro became a violation of trust. And worse, potentially a massive security hole. If the research community didn’t raise the alarm, the details of Intro’s integration wouldn’t have hit the radar.
I think the lesson here is two-fold:
1) We live in a world where our data is scattered across a variety of disparate systems. It is incumbent on us to understand the risks and weigh them against the reward of the shiny new app promising to make our lives better. If something appears to be too good to be true, it probably is.
2) Vendors need to be more transparent about what they’re doing with our data. Especially if the vendor has a spotty reputation in privacy and security realms. If they’re not, the Internet community will do it for you.