21–30 of 63 posts
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...
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.
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.
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…
To the average user, LinkedIn made no attempt what so ever to explain that by doing this, you were putting approximately the same level of trust in them as you do in Google/some other mail provider. This is particularly troubling if most people, as I do, don't have an existing trust relationship with LinkedIn simply because everything we have on their is public.
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 bo…
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.
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 excel…
>"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.
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.