Interview: Andrew Fitz Gibbon

Discussion

Key: Keep the users' data on their sides.

Scenario 1: Direct verification of SSN

1. A customer reserves a room in a hotel.
2. The hotel requests for the their SSN.
3. The hotel sends the SSN to the government for verification.

Problem: Risky to give out SSN

Untrusted	Trusted	Untrusted
Hacker	Customers <-> government	Merchant

• Sensative data stored by the merchants may be abused or hacked.
• Since customers do not trust merchants, the real SSN should be directly verified rather than handed over by the merchants.

Analogy: Credit card / mobile pay

• Key Generate tokens

• Problem: The merchants hold the credit card information, which is risky (similar to the aforementioned reasons for user data)

• Solution: Mobile payment e.g. Apple Pay: Somehow trusted
  

  Solution applied on the SSN case

Conclusion

Keep all data and purchase history on users' sides.
Third-party recommendation system (or run it locally) to process those.

Questions raised

No motivation for the merchants (pay for service; can't hold the data as they do now) & customers (satisfied with current services; prefer convenience over security)

Resources

• No expert's export :(
• Password management company /open sources projects
• Data security
  • RSA (company)
  • Journal/conference: InfoSec, DevCon