4 ms·

People cry about lack of privacy, then people cry about too much privacy... I guess it gives people something to write about no matter what. And if you can plu

by DatBear 12y ago

People cry about lack of privacy, then people cry about too much privacy... I guess it gives people something to write about no matter what. And if you can plug your company as one of the Good Guys(tm) at the end I guess that gives you even more incentive to write about it.

bradmccarty 12y ago
Privacy is a line that will always move, and it's different for every person. One of the biggest challenges that we face is finding a line that works well for everyone, while allowing them to control where that line sits. As to your second point, sure, we'd love to have people use FullContact. But the post points to many more options than just our own: "If that’s iCloud, Google Contacts, Outlook.com or heck, even FullContact, great." As I said in the post, we just want people to use a safe system that makes sense to them. It's our job to make sure that FullContact is the logical choice.
- mikelinington 12y ago
  The article did a good job IMO of pointing out the absurdity of LinkedIn's position (but I didn't need any convincing; I work at Nutshell, and contributed to the blog post you linked). At this point in the pipe, it's not about privacy concerns; this is data available via the end user's use of LinkedIn. The salient question to me is, what the hell can we do with the LinkedIn API? Why even have developer.linkedin.com if your partner program is designed to exclude everyone but two companies? (A simplification that focuses on the CRM program, but I don't know what the purpose of their other Partner Programs are.)
- DatBear 12y ago
  >As I said in the post, we just want people to use a safe system that makes sense to them. So going from a platform where random developers don't have access to _all_ of my contact info to one where they do is safer, in your opinion? I get that you are trying to produce a better developer API, but I don't think users have any more control over their data with your product than they do with LinkedIn. Now they're just at the mercy of a different company's business decisions, which is how it will be in the majority of cases, as I see it.

by DatBear 12y ago

bradmccarty 12y ago

Privacy is a line that will always move, and it's different for every person. One of the biggest challenges that we face is finding a line that works well for everyone, while allowing them to control where that line sits. As to your second point, sure, we'd love to have people use FullContact. But the post points to many more options than just our own: "If that’s iCloud, Google Contacts, Outlook.com or heck, even FullContact, great." As I said in the post, we just want people to use a safe system that makes sense to them. It's our job to make sure that FullContact is the logical choice.

mikelinington 12y ago
The article did a good job IMO of pointing out the absurdity of LinkedIn's position (but I didn't need any convincing; I work at Nutshell, and contributed to the blog post you linked). At this point in the pipe, it's not about privacy concerns; this is data available via the end user's use of LinkedIn. The salient question to me is, what the hell can we do with the LinkedIn API? Why even have developer.linkedin.com if your partner program is designed to exclude everyone but two companies? (A simplification that focuses on the CRM program, but I don't know what the purpose of their other Partner Programs are.)
DatBear 12y ago
>As I said in the post, we just want people to use a safe system that makes sense to them. So going from a platform where random developers don't have access to _all_ of my contact info to one where they do is safer, in your opinion? I get that you are trying to produce a better developer API, but I don't think users have any more control over their data with your product than they do with LinkedIn. Now they're just at the mercy of a different company's business decisions, which is how it will be in the majority of cases, as I see it.