
The Facts about LinkedIn Intro - rahulvohra
http://blog.linkedin.com/2013/10/26/the-facts-about-linkedin-intro/
======
tptacek
Cory Scott was a director at Matasano, ran our west coast office, and is as
trustworthy an appsec person as I know.

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.

(And, full disclosure: iSEC is one of Matasano's sister companies; take this
for whatever its worth, but their reputation is excellent).

I would tend to believe anything he says about this or any other LinkedIn
system he's worked on.

That said, I would still under no circumstances give LinkedIn access to my
mail spool, _or any other third party_.

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.

~~~
gfodor
Your last point nails it. I can't help but think there are a good number of
people now angling to build similar hacks in a much less rigorous fashion and
then build entire companies around this hack. The next year is already, from
my vantage point, lining up to be a year full of "give us OAuth access to your
GMail account" products. This adds another vector for this type of product. In
any case, users are not going to care about security and just tap "OK", so
it's kind of scary that this train is really moving now. Imagine if Facebook
(or the Next Facebook) required e-mail access and this was normalized.

I think it may have been a bit short-sighted for LinkedIn to post a developer-
focused, "hey look at what we did" kind of post around Intro, regardless of
how properly they implemented it behind the scenes.

~~~
Spearchucker
If Steve Sinofsky is to be believed, this is the natural order of things:

[http://blog.learningbyshipping.com/2013/10/25/on-the-
exploit...](http://blog.learningbyshipping.com/2013/10/25/on-the-exploitation-
of-apis/)

------
wellboy
Why do the billion dollar companies just not get that people can see through
double speak now.

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

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

2\. REDUCED exposure to third-party monitoring services and tracking/PREVENT
exposure to third-party monitoring services and tracking

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

4\. make sure identified vulnerabilities WERE ADDRESSED/ make sure there are
NO vulnerabilities

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.

6\. MINIMIZE exposure/REMOVE exposure

7\. We WORKED TO HELP ENSURE/ We ENSURE

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.

Somebody should fire the person that think sthis kind of "clarification" gets
back their user's trust.

~~~
mansam
Your proposed change to 4. is a statement that no one could ever honestly
make.

~~~
wellboy
Correct, which makes "Intro" and all other third party apps, which reroute
entire communication channels, untenable ones.

------
mbesto
> _This blog post is intended to provide more information and address
> inaccurate assertions_

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.

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. _However_ , 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 _never_ can get hacked.
Which I would respond - not true.

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

>"We performed hardening of the externally and internally-facing services and
reduced exposure to third-party monitoring services and tracking."

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.

------
offbyone
That article misses the key point; a MITM proxy for mail is the actual
problem, no matter how well implemented it is.

~~~
mrmch
Isn't this the exact same approach taken by Mailboxapp, proxying your IMAP
server?

~~~
PeterisP
Does this reduce the problem in any way?

~~~
mrmch
The idea that this is a "problem" is subjective; if the value prop is
compelling and there is sufficient trust established, someone should be free
to use Mailboxapp OR Intro.

~~~
PeterisP
The problem doesn't ever go away - if you're using Mailboxapp, you're forever
going to be vulnerable; you're free to use them and accept that risk, of
course, but it's still a security problem with that service.

There is no such thing as 'sufficient trust estabilished' \- trusting
Mailboxapp right now doesn't in any way imply that it will be trustworthy
enough for your needs (however large or small) after, say, a year. If you're
using software X, for example, then you can think about renewing trust only
when going to software X+1; but with such a service they can go from 'doing
only good things' to 'intentially selling you out' at any arbitrary time.

For example, look at what's happening at Buffer. By using intro or Mailboxapp,
you've just added another company whose decisions may screw you up, and that
is a problem.

------
st3fan
"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."

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."

Instead they tried to make the best of it.

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.

~~~
skybrian
Maybe they did, but they aren't going to tell us how the internal debate
played out. That's not how it works. Security teams can make recommendations
and can escalate to upper management if need be, but they don't make the final
call on new products. Ultimately it's the CEO who decides whether a risk is
worth taking.

------
jamescun
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.

------
3825
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?

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.

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.

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.

------
richbradshaw
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.

------
nostromo
After the previous discussion, I kept wondering why I didn't trust LinkedIn
with my email, but did trust Google.

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.

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.

~~~
davedx
For me there are a few reasons:

1) Google has a proven track record with email and email security (Gmail) over
many years now

2) LinkedIn has a bad reputation for security

3) Most of the people I know who use LinkedIn probably wouldn't even have
thought "how does this work". I don't like that any company can "get away
with" something like this that could put so many peoples' jobs at risk. It
feels shady and unfair.

~~~
devcpp
Exactly. I have never heard of Google sending emails on my behalf through
gmail without me knowing about it.

------
pinaceae
By now this is a complete clusterfuck.

The core idea behind this "service" of injecting LI info into any mail is
broken. No security theater around it will change that.

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).

But injecting crap into the normal iOS mail app? What a strange approach.

------
colinbartlett
Is linking to their privacy policy supposed to be comforting in some way?

"We promise that the only thing we do with your data is what we said we do
inside this huge legal document."

~~~
philjackson
To be fair the document is well presented and much easier to read than most
other privacy statements I've seen. The pledge of privacy is succinct too:
[https://intro.linkedin.com/micro/privacy](https://intro.linkedin.com/micro/privacy)

------
alex_young
What worries me here is not trusting a third party with mail - we all already
do that, this is the nature of SMTP.

The issue is that LinkedIn wants to provide mail services without saying it's
your mail provider.

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.

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.

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.

This smacks of shortcut taking. Don't trust them.

------
10char
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.

------
ceocoder
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.

------
fooshero85
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.

~~~
intslack
Their blog post said as much; that LinkedIn gave very little background about
what's going on behind the scenes. This post doesn't actually address much.

Why was your account created 30 minutes ago just to post two comments on this
story?

------
philjackson
I think this is the most interesting documentation considering the debates
I've seen here on HN:
[https://intro.linkedin.com/micro/privacy](https://intro.linkedin.com/micro/privacy)

------
aheilbut
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.

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.

------
pbreit
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.

------
quink
Why not talk to Apple or Google and make this a reality in some other way?

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?

It might take longer and be a bit more complicated but it must be a better way
to go about this than MITM.

~~~
gojomo
Why should Apple/Google be gatekeepers (and potential sources of arbitrarily
long delay, complication or strategic-veto)? What about the N other IMAP
providers?

Talking about a more generalized hook-in API is a good idea, but not in strict
preference to proxying-tricks. Rather, it makes sense as a parallel or
subsequent followup, after the value has been prototyped and proven.

~~~
blibble
call me cynical, but I bet it was discussed, and overruled on the point that
this system allows them get access to all your juicy email under the pretence
that "we can't do it any other way"

------
msh
Well considering their password incompetence i would not trust them with any
sensitive information for a long long time.

------
alkonaut
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)?

------
wai1234
Perhaps next we will hear from a bank robber that he will take very good care
of our money.

------
dmak
Unsalted passwords.

------
eball
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?

From the excellent Old New Thing blog:
[http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/42629...](http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/426294.aspx)

~~~
gfodor
Reminiscent of the insane 100-layered iframe issue with ad networks all
jousting each other for the coveted impression when the page loads.

~~~
dylz
Sounds interestering, any more info about this

~~~
gfodor
I'm exaggerating of course but if you go onto most popular websites and really
dig into their ads you'll see that you basically hop through a large number of
layers of various ad exchanges before you get to the actual server that serves
the ad. Usually via a series of nested iframes.

------
fooshero85
[http://www.bishopfox.com/](http://www.bishopfox.com/)

"Error establishing a database connection"

Can't even keep a website up and running, what a very tech savvy company.

