Cory Scott was a director at Matasano, ran our west coast office, and is as trustworthy an appsec person as I know.<p>Cory also postdates LinkedIn's security drama; he was brought in after the credential leak, which was a good call on LinkedIn's part and sort of a brave move on Cory's part.<p>(And, full disclosure: iSEC is one of Matasano's sister companies; take this for whatever its worth, but their reputation is excellent).<p>I would tend to believe anything he says about this or any other LinkedIn system he's worked on.<p>That said, I would still under no circumstances give LinkedIn access to my mail spool, <i>or any other third party</i>.<p>I'm also a little queasy about the idea of "norming" these kinds of systems. Look at how much work LinkedIn put into securing Intro, and ask whether any startup will have the means to do the same. I doubt it.
Why do the billion dollar companies just not get that people can see through double speak now.<p>Let´s look at the double speak here, which intends to give a statement weight even though it has zero weight. On the left side original statement with zero weight, after the slash how the statement would have weight<p>1. We isolated Intro in a separate network segment and implemented a tight security perimeter across trust boundaries./ Doesn't say anything at all again<p>2. REDUCED exposure to third-party monitoring services and tracking/PREVENT exposure to third-party monitoring services and tracking<p>3. We also had iSEC Partners, a well-respected security consultancy, perform a line-by-line code review of the credential handling and mail parsing/insertion code./ That statement isn't saying anything at all<p>4. make sure identified vulnerabilities WERE ADDRESSED/ make sure there are NO vulnerabilities<p>5. we make sure we NEVER persist the mail contents to our systems in an unencrypted form. And once the user has retrieved the mail, the encrypted content is DELETED from our systems./ These two words have weight.<p>6. MINIMIZE exposure/REMOVE exposure<p>7. We WORKED TO HELP ENSURE/ We ENSURE<p>Overall, Linked avoids using terminology that is actually a commitment except for 5. Fortunately, people picked up on double speak and Linkedin has managed to corrupt trust with its users further.<p>Somebody should fire the person that think sthis kind of "clarification" gets back their user's trust.
> <i>This blog post is intended to provide more information and address inaccurate assertions </i><p>I don't like this part of the full statement. It doesn't specifically address what assertions are incorrect and which are correct. Systems are and never will be 100% secure. No matter how much technology you throw at something, there is always going to be a balance between accessibility and security.<p>I do believe LinkedIn has a done a massive amount of due diligence (much more so than many other organizations would care to do) which is great and I'm glad they took the time to respond. <i>However</i>, correct me if I'm wrong, but there is an underlying assumption from the general populace that if a security expert says something is secure than this means this <i>never</i> can get hacked. Which I would respond - not true.
>"We isolated Intro in a separate network segment and implemented a tight security perimeter across trust boundaries."<p>>"We performed hardening of the externally and internally-facing services and reduced exposure to third-party monitoring services and tracking."<p>What do those points even mean? They're written like the marketing department wrote them and fluffed them to the max. "Performed hardening"....really? It just sounds like they don't know what they're talking about. "Oh yeah we totally isolated and secured the perimeter, the app is good now". If my dad heard that he'd think "Oh like in those war movies where they secure the perimeter? Awesome!". A lot of the other points they listed are like this too, I just picked out the first couple.
"When the LinkedIn Security team was presented with the core design of Intro, we made sure we built the most secure implementation we believed possible."<p>I think that is the problem. The security team should have said: "Stop. This is an insanely stupid idea. No matter how we implement it, let's just not do this."<p>Instead they tried to make the best of it.<p>I feel sorry for those folks. I bet in their heart they all know it is an utterly stupidly designed product that should never have seen the light of day.
The issue wasn't with their implementation, it was with sending all our emails through a single company, and a company whose policies border on spam at that.
Let's take a step back at what value LinkedIn Intro is supposed to give to me. What would be a better way to deliver this value?<p>I'd argue the best way to deliver this would be by working with mail providers not by subverting them. LinkedIn could open itself up and allow people to query names and profile information (probably would have to be opt-in) given an email address. A client would just send information an email address, and LinkedIn would hand back name and (public) profile information. If the client chooses to send their own email address, LinkedIn could send back a richer set of information including connections. The email client would then display the information in a way that it knows best.<p>The whole idea is so simple and straightforward that I cannot help but think LinkedIn's ultimate goal is not to just know who is sending emails to whom but also what they are saying. Cory Scott may know that the implementation is solid but I doubt he knows the motivations of his corporate overlords.<p>Perhaps LinkedIn should put a badge on all profiles of members who have opted in to the Intro service so I can cut all ties with them.
I don't think much of this was the issue – the issue was "do you trust LinkedIn with something so vital to your identity". I think it was assumed that the feature would be implemented technically competently.
After the previous discussion, I kept wondering why I didn't trust LinkedIn with my email, but did trust Google.<p>Google is actually much more terrifying in that they have more information about me than any other entity (Search, Gmail, Google Analytics, Chrome, GChat, etc.) Yet, I tend not to give it much thought.<p>Some people are upset about LinkedIn spam - but that's never been a problem for me. I haven't figured out a good answer to this yet.
By now this is a complete clusterfuck.<p>The core idea behind this "service" of injecting LI info into any mail is broken. No security theater around it will change that.<p>LI should have worked with Apple to come up with a way to embed this kind of info natively into the mail app. And if that is not possible, add an email inbox to their LI app, so that the email header would be post-processed within the app. Make people use LI as their mail client (who knows, maybe someone would have liked this).<p>But injecting crap into the normal iOS mail app? What a strange approach.
Is linking to their privacy policy supposed to be comforting in some way?<p>"We promise that the only thing we do with your data is what we said we do inside this huge legal document."
What worries me here is not trusting a third party with mail - we all already do that, this is the nature of SMTP.<p>The issue is that LinkedIn wants to provide mail services without saying it's your mail provider.<p>If you want to be a mail host, be a mail host. Don't half ass it by pretending you're offering a value added service to someone else's MX.<p>Convince me there's a reason to use your mail service. Show me there's a reason to trust you. I evaluate it and decide if I want to switch. This process works. It's proven. We expect things out of MXs.<p>No one knows how to evaluate an MX proxy on a consumer basis. There's no reason to change this. I don't care if you're LinkedIn or anyone else.<p>This smacks of shortcut taking. Don't trust them.
An advantageous move for LinkedIn might be to just launch it's own email service and compete with Gmail. So many add-ons and hacks exist to add LinkedIn capabilities to existing email, it might be worth it on their part to do it the Right Way.
After reading original announcement and this follow up post, and comments here. I find my self looking at it in a binary scenario - do they think they did a better job securing intro after the account breach - possibly, is the risk of letting one MORE entity (in addition to gmail with recent developments in mind) read thru your mails for marginal - at least for me - gain worth it? A solid NO.
Bishop Fox is a glorified gossip queen of a security company. What type of engineers, or so called hackers just make stupidly false claims without actually knowing what is going on behind the scenes. This is the software industry, not the Kim Kardashian, Honey Boo boo entertainment industry folks... Get the facts straight, or get a new job.
I think this is the most interesting documentation considering the debates I've seen here on HN: <a href="https://intro.linkedin.com/micro/privacy" rel="nofollow">https://intro.linkedin.com/micro/privacy</a>
I'd feel better if LinkedIn would be more transparent about the data they have collected on my network and how they make predictions, and would allow me to delete such information if I wish, because I find some of their "People you may know" recommendations to be decidedly creepy.<p>Even assuming that they are technically able to do this securely, it's the opacity about how they will use the data and how long they'll keep it that bothers me.
I hate the way LinkedIn handles criticism. Most of the discussion I've seen has centered on the concept, not the implementation. Instead of trying to allay concerns about the concept, LinkedIn spends the whole, defensive post chiding commentators for "inaccuracies and misperceptions" and proceeds to humblebrag about how thorough its security precautions were.
Why not talk to Apple or Google and make this a reality in some other way?<p>Surely it can't be hard for a company like LinkedIn, about as important as Facebook, to ask Apple or Google to provide some way of hooking into a third party application or well documented API?<p>It might take longer and be a bit more complicated but it must be a better way to go about this than MITM.
THEY host the intro proxy? Wouldn't it be better if each individual or organization had their own intro proxy that provided this? I.e. mail client-> my proxy -> (linkedIn + mailServer)?
Read a comment the other day wondering about what if two(or more) programs did this. Would you end up with a chain of proxies between you and the mail server?<p>From the excellent Old New Thing blog: <a href="http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/426294.aspx" rel="nofollow">http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/42629...</a>
<a href="http://www.bishopfox.com/" rel="nofollow">http://www.bishopfox.com/</a><p>"Error establishing a database connection"<p>Can't even keep a website up and running, what a very tech savvy company.