campbellsoup

It's explained in their FAQ: the only information they ask from you to register is your phone number.

Very interesting idea. Where do the authToken and authType come from though? Isn't it sufficient to have the classic LinkedIn profile URI [/profile/view?id=98261032]?

"I want to add two things:

I am an experienced programmer. I've been programming computers since I was 7 years old, typing in BASICA programs by hand on my mom's COMPAQ 8088. I formatted her hard drive by accidentally going into low level format instructions using ''debug'', experimenting with assembly language, when I was about 10. I am now 25. I love computers. I just happen to recognize the limitations of where we are at right now, that's all.

Computers will be the SALVATION of this whole system I am describing right now. So if you feel offended knowing that I am dumping on them right now, know that that's not going to be the case for long. Paper is unwieldy, large, requires storage, and a host of other ills. Copying from page to page to page is just a nightmare. It is a necessary nightmare, right now, but it is a nightmare. Computers will save us from it.

Hah! I'm sneaking in a #3. (Part of my ``no-edit policy'' when spitting stuff out. Apologies.) I WILL DESCRIBE, if I DO NOT FORGET, just WHAT steps you can take NOW, IF YOU ARE INTERESTED, to ``get the ball rolling''. There are some easy programs that you can make right now that would make this system AWESOME. I just don't have the time to code them up right now. But I will describe them, and if you like, you can code them up. Hell, I'll even throw in a description of the ideal computer notebook system- assuming I have ``magic paper''- and how it will dramatically increase our intelligence, provided that we can solve the versioning problem as well. (Note: Ted Nelson and Company went pretty batty WRT the versioning problem. Did they solve it? I don't know. I have heard rumors that some of Ted's protege's work for the CIA now, though.)"

The article is dated "May 6, 2014 5:00AM ET", hardly news...

To me it seems more like the NSA wanted to make the Web giants aware of new or unmitigated threats. Here's a quote from Gen. Alexander:

“About six months ago, we began focusing on the security of mobility devices,” Alexander wrote. “A group (primarily Google, Apple and Microsoft) recently came to agreement on a set of core security principles. When we reach this point in our projects we schedule a classified briefing for the CEOs of key companies to provide them a brief on the specific threats we believe can be mitigated and to seek their commitment for their organization to move ahead … Google’s participation in refinement, engineering and deployment of the solutions will be essential.”

Solution:

Here are the two workflows I have in mind:

1. Registration

- user submits the form

- company sends something like { hash(mail), hash(hash(mail)+pass) } to our API

- API returns whether we've found at least a website where this tuple exists (no mention of the website obviously, boolean answer only)

- company can refuse registration if the tuple is not unique

- When the user finally signs up, send something like { website, hash(mail), hash(hash(mail)+pass) } to our API

2. Login

- user logs in: fills in the form as usual and submits it

- company checks our API to find out whether there have been recent unsuccessful attempts at logging in for the same tuple (mail/pass) across several websites. If so, then there's possibly an attack targeting this user, and the company can take risk mitigation actions such as requiring an sms code or freezing the account until further notice.

- if there's no known attack, company checks internally and if it finds out the login information is incorrect, then it reports the bad login to our API

Fundamental questions:

1. Obviously a major point is ensuring security and trust, that is being able to store data that:

- allows finding out whether there is an account with the same information elsewhere

- provably forbids attackers and API users from getting more than a non-exploitable answer

My opinion is that we can achieve such provable state of security by asking API clients for information hashed in a way that provably prevents us as an API provider to find out more information than needed. Then we can communicate towards companies along the lines of "see how the info you provide us inherently prevent us from getting any sensitive information about your users"

2. Well, would you take part in such an initiative?

3. Do you know of any company that would actually pay for such a service? 'cause, you know, that would be awesome :)

PS Congratulations for reading all of this. Thanks for your input.

I'm both excited and worried about it shipping as a standard WordPress plugin. What failsafes are there to guarantee that this very plugin shan't itself break after a particular update?

Could someone point out to me how filtering and selecting records over some parts of the primary key (ex {sensorID} over {deviceID}_{sensorID}_{timestamp}) is better than just having regular indexed fields (ex {sensorID}) containing those pieces of information?