Maccast 2012.02.20

Written by: Adam Christianson

Categories: Podcast


Download today’s show here! podcast-mini2.gif
MC20120220.mp3 [43.6MB 01:30:27 64kbps]

A podcast about all things Macintosh. For Mac geeks, by Mac geeks. Show 385. OS X Mountain Lion. Messages on OS X. Apple TV rumors continue. Antennagate settlement. iPad 3 rumor updates. Apple’s green data center. Extracting photo from Contact app. Sandboxing coming, but broken. Path contacts controversy shouldn’t have happened. Your privacy in the Clouds. iTunes Match mismatch. Replacing Keychain syncing. Virtual Keyboard hidden keys.

Want more Maccast? Become a Maccast Member.

Special thanks to our sponsors:
Circus Ponies
Circus Ponies NoteBook – The Easy Way to Get Organized on the Mac. Try it FREE for 30 Days.

Shownotes in: HTML or OPML
Subscribe to the Podcast Feed or Get the MP3 or Enhanced AAC

There are 3 comments on Maccast 2012.02.20:

RSS Feed for these comments
  1. Donald Burr | Feb 21 2012 - 02:10

    Minor nit: The “upload your contact list” functionality is a legitimate requirement to provide the “find your friends” functionality — within reason (see below). The way that such matching is typically done is by uniquely identifiable data, such as e-mail address or phone number, and compares it with everyone else on the service. So, if I have you in my contacts list with the e-mail address “adam@maccast.com”, then a service can say “Do I have any users registered with the e-mail address “adam@maccast.com”?” If yes then it must be the same guy. Services that do this typically use email addresses and sometimes phone numbers to perform this matching.

    However I definitely agree with you that they do NOT need your entire contact list, nor do they need to send it up to their servers (and certainly don’t need to store it for X days). You don’t need a person’s home address, etc. to perform matching. Also, rather than send the data in plain text, they can actually compute a hash of it on the iPhone (hashing functions are pretty cheap CPU-wise) and send the *hash* instead of the actual data. So, instead of uploading “adam@maccast.com” and comparing against that, they hash your e-mail address on your iPhone and instead send up the hash (a1b2c3d4…) and compare those on the server. That way they never have your actual e-mail data; hashes are a one-way function. You can’t “crank the sausage machine backwards” and get the original data given only the hash.

    So yeah, this is probably a case of Developer Laziness. *raps developers hard on knuckles with ruler*

  2. Donald Burr | Feb 21 2012 - 03:10

    Silly me, I should have listened to the entire podcast before responding, since you basically said exactly what I just did. Except you called it “salting” which is technically incorrect. *raps Adam very gently on knuckles with ruler* ;-)

  3. Adam Christianson | Feb 26 2012 - 11:20

    Donald,
    Thanks for the feedback. Yeah, I should have probably better explained the “salting” thing as I wasn’t using it in the purest sense. Really I was just saying they could add a bit of known “salt” to the data they planned to match against before hashing it. This just adds an extra layer of obfuscation to the data that ends up being passed and stored on the servers. That way even if the data got hacked trying to decrypt the hash would require one more bit of info to be know to the hackers. Not a lot more secure, but just a hair more secure than just hashing the email address alone. And yes, true salting would require the salt to be different each time.