Hashing For Privacy In Social Apps

Matt Gemmell, on the subject of social apps uploading raw user data instead of hashing the data:

From talking to many developers about this privacy intrusion during the past week, it quickly became disturbingly clear to me that many aren’t familiar with hashing at all. This is also predictably (and entirely forgivably) true for the many journalists who have covered the story, unintentionally distorting the issue due to lack of education in the field. This article, therefore, aims to introduce the concept of hashing in a clear, straightforward, and no-degree-required way, suitable for journalists and casual readers as well as programmers and software engineers. I’ll also explain why it’s suitable for preserving the privacy of contact information whilst still allowing for social functionality, and I’ll touch on whether or not you really need to store that contact information (hashed or not) in the first place. He goes on to outline the things he touched on in the paragraph above. This is a must-read article for any web or app developer.

Developing on a Mac vs a PC

Marco Arment: "It's like a first-world/third-world kinda computer today."

Dan Benjamin: "Right! No, exactly!"

Marco Arment: "It's like if your instructions to someone, are like, 'Uh, how do I hook up this water filter?' Ok well first, you hook this up to your sink. And like, 'Well, I don't have a sink.'

Merlin Mann chuckling in the background.

Dan Benjamin: "Here's how to get this...right.."

Merlin Mann: "Let me get you a different pamphlet."

Dan Benjamin: "And you know Marco, that's an excellent point. It is a very very different world on the other side."

The best description I've heard, in years, about the differences and difficulties in developing open standards oriented web applications on a Macintosh vs a PC platform. You need to listen to the 5by5 Special #4: Kindacritial which aired yesterday.

iOS Address Book Access Should Prompt The User For Permission

Marco Arment has chimed in, from a developers perspective, on the subject of Path's using Address Book data without asking the user permission first:

When implementing these features, I felt like iOS had given me far too much access to Address Book without forcing a user prompt. It felt a bit dirty. Even though I was only accessing the data when a customer explicitly asked me to, I wanted to look at only what I needed to and get out of there as quickly as possible. I never even considered storing the data server-side or looking at more than I needed to. This, apparently, is not a common implementation courtesy.

iPhone Address Book Privacy

Jason Kottke:

13 out of 15! Zuckerberg's cell phone number! Maybe I'm being old-fashioned here, but this seems unequivocally wrong. Any app, from Angry Birds to Fart App 3000, can just grab the information in your address book without asking? Hell. No. And Curtis is right in calling Apple out about this...apps should not have access to address book information without explicitly asking. But now that the horse is out of the barn, this "quiet understanding" needs to be met with some noisy investigation. What happened to Path needs to happen to all the other apps that are storing our data. There's an opportunity here for some enterprising data journalist to follow Thampi's lead: investigate what other apps are grabbing address book data and then ask the responsible developers the same questions that were put to Path. Well put.

iOS Developer Woes: Cleaning...

While Apple usually gets everything right, they occasionally drop the ball. Here is an instance of them dropping the ball: Marco Arment writes:

Instapaper has stored its downloaded articles in Caches for years, since I didn’t want to slow down iTunes syncing for my customers or enlarge their backups unnecessarily, and full restores don’t happen often enough for it to be a problem for most people. This new policy now locks me into using Caches: I no longer have a choice. But in iOS 5, there’s an important change: Caches and tmp — the only two directories that aren’t backed up — are “cleaned” out when the device is low on space. … A common scenario: an Instapaper customer is stocking up an iPad for a long flight. She syncs a bunch of movies and podcasts, downloads some magazines, and buys a few new games, leaving very little free space. Right before boarding, she remembers to download the newest issue of The Economist. (I think highly of my customers.) This causes free space to fall below the threshold that triggers the cleaner, which — in the background, unbeknownst to her — deletes everything that was saved in Instapaper. Later in the flight, with no internet connectivity, she goes to launch Instapaper and finds it completely empty. … When customers save an article with Instapaper, get a book in iBooks, or download a podcast with Instacast, they expect it to be there next time they launch the app. Even though it’s technically redownloadable, customers see that as their data — they put it there, and it’s theirs to remove if and when they see fit. When the cleaner wipes it out, it appears that the app has failed and deleted their data. And customers won’t know that it’s an iOS 5 behavior — they’ll understandably blame the app developers. Even though it’s not our fault, it’s certainly going to become our problem. There needs to be a file storage location that behaves the way Caches did before iOS 5: it’s not backed up to iTunes or iCloud, it’s not synced, but it’s also never deleted unless the app is deleted. I posted large excerpts of Marco's article because I want to help get the word out on this issue. This is generally more than I would like to repost from someone else's site, but considering the circumstances, I would think Marco would be fine with it.



Tweetmarks is a web service for setting and getting the "last read" tweet for a given Twitter user. It can be used to "sync" the reading position between multiple Twitter clients and platforms. It was created by Riverfold Software. Also see this blog post introducing the service. All Twitter client application developers: PLEASE integrate this into your clients. As for why Twitter hasn't already implemented this themselves, Marco Arment writes: Unfortunately, I doubt that Twitter’s official Mac and iOS apps will. Twitter has decided, for whatever reason, not to do this to date. I heard a while back that this was because they want people to just read what’s there now, like a river of news, not to try to “keep up” with a potentially insurmountable timeline. They didn’t want to encourage features like this that would allow someone to know how far “behind” they are, because that could cause guilt and feelings of information overload, which could discourage usage. I believe they are wrong in this line of thinking. Moving from Tweetbot on my iPhone to Twitteriffic on my iPad to the Twitter app on my Mac feels like a broken experience. Having to re-read supposed "new" updated over again to figure out my place depending on where I am just feels wrong. Twitter is arrogant in trying to dictate how users should use their service rather than trying to accommodate the reality of how their users currently use Twitter. To quote Marco again: And as long as Twitter doesn’t have an API for it, widespread Tweetmarks support in apps is badly needed for anyone who uses multiple Twitter clients. So if you make a Twitter client, please add Tweetmarks support. Yes, please.

A Programmer Explains Why Android Apps Are Ugly

Christopher Mims, at technology review writes about developing for Android devices:

Developing for such a wide array of device screen sizes and aspect rations means that not only is it impossible to create pixel-perfect designs for Android interfaces, there isn’t even any guarantee that a given interface can be scaled to fit a particular screen. And in case you missed it, you should read this article that made the rounds a few days ago as well.