NBC News' Fear-mongering Regarding Leaked Apple Device UDIDs

in , , ,

I always enjoy when non-tech reporters write about tech stories and get just enough of the details wrong to make it seem to the average user that the story is true while the story actually perpetuates falsehoods. Keyy Sanders and Bob Sullivan, at NBC News:

The UDID -- which stands for Unique Device Identifier -- is present on Apple iPads, iPods and iPhones, and is similar to a serial number. During the past year, researchers have found that many app developers have used the UDID to help keep track of their users, storing the data in various databases and often associating it with other personal information. When matched with other information, the UDID can be used to track users' app usage, social media usage or location. It could also be used to "push" potentially dangerous applications onto users' Apple gadgets. The way this paragraph is written, it would lead the average reader to believe that any of the leaked 12 million UDIDs could be used to push malware onto the respective iOS devices they belong to. This is a blatant lie. In order for something like this to happen, the culprit would have to register 120,000 Apple Developer accounts, paying $99 each for them which would cost a total of $11,880,000. Then someone would have to manually enter each UDID into Apple's Developer portal. Then and only then would someone have to make some sort of iOS app (that Apple could kill easily by deactivating the offending developer account) and add that app to each of the 120,000 developer accounts they've made in order to be able to generate a link or share a file that users would have to drag into their iTunes or use a service like Testflight to receive over the air (most if not all Testflight users are developers themselves.) As you can see, this is a near-impossible scenario. Yet if you read the quoted paragraph, NBC would like the reader to believe that they are possibly in grave danger of having malware "pushed" to their devices. ::eyeroll:: The question is - did these two reporters not understand how this works or did they intentionally attempt to mislead their readers to make the story juicier?

How To Build An iPad Competitor

in , , , , , ,

Jason Kottke, at Kottke.org:

Set aside for now that Surface does look genuinely interesting, that the price hasn't been set, and the thing isn't even out yet. For a piece of portable networking technology like a smartphone or tablet to be successful on the scale at which Apple operates, you need to have an ecosystem, a network of interacting devices, software, products, and services that work together...hardware + software is not enough. Apple, Google (and partners), Amazon, and possibly Microsoft are the only companies with the expertise and pockets deep enough to build their own ecosystems. Ok, maybe Facebook in a couple years or if Nokia can dig themselves out of their current hole, but that's really about it. Jason Kottke lays out all of the things Microsoft needs to do to make the surface successful, if their goal is to directly compete with the iPad.

Hashing For Privacy In Social Apps

in

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

in

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

in , ,

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.

Gina Trapani ports Todo.txt from Android to iOS, 40% More Sales On First Day

in , , , , ,

Co-host of the TWiT network's This Week in Google podcast and highly regarded Android proponent, Gina Tapani, has ported her Todo.txt Android app to iOS:

I announced the app went on sale yesterday morning on Twitter, Facebook, and Google+, then Lifehacker ran a post on it. It got no other press coverage. I announced the Android app release in exactly the same way on January 24th of last year (minus Google+, which didn't exist then). If my Googling skills serve me right, Lifehacker did not run a post the day the Android app went on sale, though they did the week before when I was beta-testing it. The first day of iOS app sales was solid: just around 365 apps sold, compared to the 215 I sold on the first day of Todo.txt Touch's availability in the Android Market. That means the iOS app sold 40% more units under somewhat similar conditions as the Android app on release day. Her whole post is worth the read as she discusses how the project came together (it's open source) and some of her thoughts on working on an iOS app in comparison to an Android app.

iOS Developer Woes: Cleaning...

in , ,

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.