Privacy and iPhone/iPad/iPod touch Unique Device Identifiers (UDIDs)

Here’s an analysis I wrote on iOS UDIDs for the excellent PRIVACY Forum mailing list, which I’ve posted here for reference:

Last year we started building WasteNot, our free environmental iOS app, and we needed a way to uniquely identify our customers so they could access their accounts.  We spent a lot of time discussing the privacy implications and determined there were two options: use the UDID, or create our own identification system.

As a long-time privacy advocate (I co-founded a privacy infomediary in ’99), I foresaw a potential privacy backlash against the UDID.  It’s incredibly simple to access the UDID and transmit back to the server, but incredibly privacy invasive, easily linkable across different applications, and as it turns out, useless for actually tracking customer preferences across multiple iOS devices.

We’ve written a privacy chapter in our upcoming iPhone business development book discussing our key learning in detail, but I thought you might like some quick highlights of what we’ve learned:

  • A UDID is unique to each device, but only Apple can link it back to an actual customer unless the customer provides more information, or another piece of data is sent along (e.g. telephone number, GPS location for google maps, etc..). Many duplicitous companies collect and transmit this secondary information. Rarely do they do use opt-in, nor does the Apple device warn the user of the majority of the data collection and transmission.
  • A UDID identifies the *device*, not the customer — if a customer has a iPhone and an iPad, there are two different UDIDs.  If a customer loses their iPhone, their replacement iPhone has a different UDID.  If a family shares a single iPad, they all have the same UDID.
  • A customer cannot change their device’s UDID, nor can they stop the collection and transmission of the UDID (like they can block the GPS location for which there is an Apple alert).  IMHO, Apple should require a pop-up notification for “this app is trying to collect and use your UDID: OK / Cancel”, but Apple is very against additional pop-ups as they detract from the customer experience.  I doubt this will ever become a feature, nor do I believe this would really do much other than annoy the customer with yet another alert they don’t read or think about before clicking “OK”.
  • If you don’t use the UDID and want to uniquely identify customers (in our case to store preferences and content submissions so they are accessible from any device running WasteNot), your options are similar to the web-based world. In our case, we chose to use a fully opt-in model, where customers first had to sign up with an account using any email address they prefer.  In retrospect, there are several problems with this approach:

    1. Customers have generally used their real email addresses when they sign up for a WasteNot account.  From a privacy perspective, we don’t really want this information, since if our servers are hacked, their email addresses are at risk.  UDID’s are much less useful to a hacker since you can’t send spam to a UDID. Arguably, email address collection for account identification is much more privacy invasive than if we had just used the UDID.
    2. A significant percentage of people who download WasteNot do not ever sign up for an account because of the account creation hassle.  This limits the functionality.  I’m sure this has resulted in several of our less-than-5-star ratings, although we use an opt-in system and we do *no* behavioural tracking, so I have no way to verify this.  My guess is that had we used a UDID approach, we would have had significantly higher ratings, significantly more customers, and significantly better press as a result.
    3. People forget their passwords, so we needed to build a password retrieval system, too.  All told, it was more than 250 additional hours of work to build and test the system to handle user account generation, login, logout, password retrieval, email address verification, and other things that wouldn’t have been as necessary if we had just used a username and the UDID.
    4. On the flip-side, had we used the UDID we wouldn’t have been able to let our customers access their WasteNot account from any device.  This means that the UDID, which arguably was put in to allow for easy customer identification, is really only useful for behavioral tracking on a single device.  You still need a login system if you want your customers to be able to use their account from multiple devices.

Key Takeaways:
My takeaways from the last 22 months of development and watching our WasteNot app in the wild are:

  • You need a customer account creation and login system if you want to have customer accounts.  UDID’s don’t fix the account problem, so they don’t really provide much value to privacy-conscious developers like us.
  • Developing an account creation system is a LOT of work, and thus the majority of developers who don’t need multi-device accounts choose to use the UDID instead to save time and money.  (In other words, Apple incentivizes developers to use the UDID by not providing them with a similarly useful privacy-enhanced customer identification tool.)
  • UDIDs are only useful for tracking the behaviour on the device.  This makes it incredibly useful to track behaviour within an app, and I’ve seen several advertising and behavioural tracking systems that use the UDID, without the customer’s knowledge or consent.  (One sales pitch I saw bragged about their ability to report on every action a user took within an app: every button click, every page viewed, every table cell viewed, and the time a person took between each action, all sent back to the server without any notification or customer access to that information.)
  • Thus, UDIDs are most useful to people who want to track and collect user behavioral data without user notification or permission (ad networks and behavioural monitors).  And since the UDID is the same for every app on a device, this is a boon to advertisers and other data aggregators.  (Think of how happy the DoubleClick/Google’s of the mobile advertising world are that they no longer have to place a cookie to track a user across sites/apps, there’s already a permanent cookie that the user cannot turn off.  Eric Smith’s paper was insightful comparing this to the Pentium 3’s Processor Serial Number (PSN).)
  • UDIDs are _initially_ only linkable back to an individual by Apple, unless the individual provides more information (e.g. GPS location, email address, telephone number, etc.).  Unfortunately it’s very easy to do this, either directly or indirectly.  Hopefully Apple is checking for this when they review apps before approving them on the App Store — I doubt it but I still hold hope — but if a developer who wanted to do this was smart, they would have the app query the server on load and have the server return a “don’t collect or transmit data” response during app review, and then once the app was approved, switch that to “start collecting data now that Apple isn’t reviewing this app anymore”.
  • Once a network has linked a UDID to personally identifiable information (PII), they can then link that UDID to all of the apps that use that network. Once a customer uses the same app on two devices, the network can link all information between all apps across both devices. For example, say two apps both use the same advertising network. If app_A asks for an email address on a device (e.g. iPhone), and then provides that to the ad network along with the UDID, the ad network now has a link between the UDID and the email address and can use or sell that information to all the other apps in their network. If app_B collects geo-location data, and delivers that to the ad network along with the UDID, now the ad network can link the email address (from app_A) with the geo-location data (from app_B) and build out their database of PII for each UDID. Once a customer uses app_A on a different device (e.g. their iPad), the ad network can immediately link the two UDIDs together and now knows the geo-location data and email address for the user on the iPad, even if they never open app_B.

My take on the ideal iOS privacy solution:

  • Apple forces opt-in for data collection and transmission for each app, including notification of what is being collected, why, and how it will be used (along with a link to the privacy policy governing the collection and usage).
  • UDID’s are generated for each app on the device in a way that two apps on the same device can’t link their data.
  • Apple develops a simple SDK to provide a privacy-enabled, blinded user account system, with ID’s unique per user per app (not per-device) so that it is as easy for developers to use that privacy-enhanced system as it is to use the UDID (removing the cost-savings argument for using a UDID).

I won’t hold my breath.

How we built a powerful, world-changing, polished iPhone app and company for under $70K

Starting a successful company is incredibly complex and expensive.

There are basically two ways to accomplish this: find outside investment funds, or fund it yourself (aka “bootstrap”).  We decided to prioritize the good we can do for the world above maximizing our potential income. This goes against most investors’ goals of maximizing the return on their investment, so we needed to figure out creative ways to bootstrap our company with the limited funds we had available to us.

Bootstrapping has been wicked hard. Appropriately rewarding people for the time they work for a company is usually the largest expense, so the hardest part was figuring out how to get people to work passionately and effectively on a startup-schedule for as little actual cash as possible.  We found seven key motivators that work best when used proactively and frequently in combination:

  1. Define a positive, fulfilling mission, and make it a daily priority.
    From the start, we chose to prioritize maximizing the good we could do for the world over maximizing profit.  Our Corporate Principles were one of the first things we put on our new website, and we make sure people agree to them before we even begin discussing bringing them onto the team.  Not only has this inspired people to work with us, it has set the expectation that our successes are defined in much more positive ways than just cash.
  2. Find like-minded people to work with. Look for shared ideals, goals, and motivations.
    It helped us to work with people we already knew and had strong relationships with.
  3. Give everyone something that they want to do.
    Challenge them to do something they’ve never done before, but something that they are clearly capable of.
  4. Figure out how each person wins, no matter what – we call this “FailSoft”.
    This includes resume building, actively extending social networks, and even allowing maximum freedom of schedule. Anyone can work for us for as much or as little as they want; They choose the hours, they can leave at anytime with no animosity, and they (mostly) help choose the deliverables and the deadlines, with the expectation that they will complete those things they commit to.  Encourage them to check job postings regularly to see how much their new skills are worth. Challenge them to look for places that will give them a better opportunity for the next 3-6 months, not as an “ultimatum”, but instead as a feedback loop on how much value and personal growth they are getting by working with you.  Encourage them to take an opportunity if they find one that’s better for them. This not only makes people happy, but also serves as a repeat reminder of how much you value them, how significant they are to your company, and how much you care about their personal growth.  By freeing them from the contractual shackles of a traditional work obligation, they’re  more likely to want to stick around to help you through the tough times.
  5. Create a system where everyone wins together.
    We chose to do this through a system of Profit Sharing that treats everyone equally:  A portion of all sales and company income is distributed equally among all consultants, including the Founder and CEO, regardless of the product or the team that made it happen. Shares are determined by (number of hours worked) * (the market rate for the skills used).  We basically create one big pool of “time invested,” recorded as the cash we would have paid out in consulting fees.  We then distribute profits to everyone.  Each person’s share of the profits is equal to their share of “time invested”.  This kind of system is especially motivating for people during the 18+ hour work days that are common in a startup — the more they work, the larger their share of the rewards.
  6. Make sure everyone has the tools they need to do their job, and give them shiny new “toys” to play with to keep them interested.
    Ideally you can combine the two — purchasing a cool new laptop to work on can be worth more in startup happiness than double or triple its value in cash.
  7. Acknowledge participation from the very start.
    We did this by making our “Credits and Thank You” page auto-update every time our app starts.  Whenever someone new comes on board for the project, we add their name to the Credits page. We also make sure they see their name in the app before they leave their first work session.  People who had worked for big software companies were BLOWN AWAY; Getting their name in the credits for those big projects was a many-month bureaucratic process of requests and approvals, if they ever got their name added at all.  We asked them what name they wanted in the credits before they even started doing any work. Instant recognition goes a long way.

Combine these tips with being frugal about all other expenses.
For instance we worked hard to find creative solutions for office space (offered in exchange for participation in the profit sharing pool), non-cash payments (drinks and home baked cookies for the beta testers instead of cash), and bartering for goods, services, and press.

Using these techniques, we were able to build a world-changing iPhone app and company over 14 months with 30+ people involved for less than $70K.  We hope these ideas can help you too.

Imagine what we’ll be able to do with our next $70K!  We’d love your support.  Email us to learn how you can help.

We look forward to your ideas, in the comments, on how we could do even more for less!

HOWTO: 9 steps to build an iPhone demo video with impact

Key Takeaways

Demo videos are amazingly useful to show people what your product does.  Most people don’t want to read, and are pressed for time.  Demo videos need to be short (< 2 minutes), fast-moving (to keep attention), and clearly describe the core motivations and functionality that makes your product useful and unique.  Building a good demo is a process that can go quickly if you know the right steps.  One person can do this — I did the work myself in less than 30 hours.

This is a brief summary of how I made our demo for WasteNot, our world-changing environmental app for the iPhone/iPod touch/iPad.  We’ve gotten tons of views and great feedback.

Goal

Build a quick, informative demo that:

  • Teaches what the product does and briefly how to use it.
  • Gives the inspiration and motivation for why people should care and go use the product.
  • Explain the problem you are trying to solve and how you uniquely solve it with your product.

Here’s the video we created:

Step 1:  Do Research & Figure Out the Length

Key Materials/Technologies that we used: YouTube.com

Go watch a bunch of demonstration videos on YouTube.  Take notes on what you liked, what worked, and what didn’t work.

Choose a length: 2 minutes (120 seconds) was the most we could expect people to sit and watch our iPhone app demo video.  Your product or service might require less/more time.

Step 2:  Brainstorm and Storyboard

Key Materials/Technologies that we used: Pen and re-used scrap paper.

About 2-months before your product launches, start thinking about what the key problems are that your ideas are solving, and why you have a unique solution that people should care about enough to spend their time watching your demo.

We chose to split our demo into two parts:

  1. Motivation: why we built our app, and why viewer should care.
  2. Demonstration: how we uniquely solved the problem, and how to use the app (key functionality).

Over the course of a couple weeks, sketch out the story you want to tell with pen and paper (on the backside of junk faxes/old printouts — WasteNot!), and put together a story to tell.  Figure out the basic timing of how your ideas and visuals will flow from one to the next.

Step 3:  Get Feedback

Key Materials/Technologies that we used: in-person chat, phone calls, Skype.

Show your sketches to other members of your team, your friends, or family. Ask for honest feedback on how to make it better.  Integrate their feedback, and then show them your updates to see if you sufficiently addressed their suggestions.

Step 4:  Make Some Initial Keyframes

Key Materials/Technologies that we used: PowerPoint, Gimp

Create some key graphics that you can put into sequence to see how it will look and to start planning the flow.

I wanted to do the first part in a presentation-style demo that people would be familiar with, and then transition seamlessly into the real-time app demo.  I wanted to use OpenOffice, but kept having problems with it crashing.

I ended up using PowerPoint to create the graphics.  (It also crashed, but less frequently.)  I built slides for each keyframe.  I then split apart each section of each slide and put them onto separate slides so I could save them as individual images.  This way I could animate any graphic independent of the rest.

NOTE: this includes the title and any text — they each got their own slide.  This is because you can always animate two different images the same way, but it’s much harder to animate two different parts of a single image differently.

I made the background of the slides a single color, and then saved them as lossless .TIF images.  I opened the images in Gimp, selected the background color using the magic wand-looking selection tool, and deleted it, making the background transparent.  This let me layer my images in any order I wanted.

Step 5: Initial Video (no voice)

Key Materials/Technologies: Final Cut Express

I had a licensed copy of Final Cut Express (FCE), so I taught myself how to use it.  I’ve used Sony’s “Vegas” software and liked that too.  Any movie making software with motion controls should work.

I put all the images from Step 3 into FCE, and layered them appropriately.  I briefly played with the timing of transitioning the images to make sure it felt like it was moving fast enough, but not too fast.

Don’t waste too much time on this step.  You’ll be changing all the timings and animations after you record your voice-over.

Step 6: Voice-over

Key Materials/Technologies: Audacity

I wrote a script for what I wanted to say, and then had my team help me edit until it was right.

I then read it aloud and recorded it using Audacity on my MacBook Pro laptop using its built-in microphone.

I made about 40 recordings.  I selected the 10 I liked best.  I then narrowed it to 3.  I listened to each 3 times, and then chose my favorite.

I reasoned that a single recorded session would sound better (and take less time) than trying to piece together several different recorded sessions.

Step 7: Screen Capture of the App using the iPhone Simulator

Key Materials/Technologies: iPhone Simulator, PhoneFinger, ScreenFlow

I played back the chosen recording from step 5 and figured out the timings for when the app needed transitions in the simulator.

I found the amazing donation-ware application PhoneFinger that turned my mouse pointer into a finger, size and style of my choosing.  (Thanks Dan, PhoneFinger rocks!!!)

I then used ScreenFlow to record the screen capture of me using the simulator in time with the audio recording.  I made sure I had a solid color screen background.  ScreenFlow let me crop the video down to just the simulator, and then saved it as a lossless .mov for me.

Step 8: Timing and Exporting the Final Video

Key Materials/Technologies: Final Cut Express (FCE), iPhone (for watching playback)

I imported the audio from step 5 and the movie from step 6 into FCE.

I spent a lot of time making sure the animations and transitions happened the way I wanted, at the times I wanted.

I exported the video.  Current best format specifications (resolution, codec, etc) were found on the YouTube site.

I made two versions:  a 640×480 movie for uploading to YouTube, and a iPhone (.m4v) version to distribute via our website.

I watched both on my laptop, and on my iPhone, and made sure both movies looked good on both platforms.

Step 9: Publishing

Key Materials/Technologies: YouTube.com, HTML

I uploaded the video to YouTube, and then used their privacy-enhanced embedding code to include the video on our main WasteNot page.

Hope this helps you build your demo video better and faster.

Hello world!

Welcome to Kismet World Wide Ideas!

This is our blog where we drop the corporate veil, and talk to you straight about what we’re up to, what we’re thinking about, why we’re doing what we’re doing, why we believe it will help the world, and discuss your feedback.

We’ll also be posting some of the unique thinking that’s gone into building our iPhone Apps, our book, and our company.  And we’ll be sharing news and updates about our products: WasteNot, TaxiFlasher, and our forthcoming book.

We hope these posts are start of informative conversations around some of the biggest ideas that we’re thinking about and working on.

We love to have you participate, and to hear your feedback, so please comment and help expand the conversations.  Don’t hesitate to let us know if there are any subjects you’d like us to write about!  You can post here, or email us direct:

Ideas@KismetWorldWide.com

Thank you!

- The Kismet World Wide team

Posted in: Kismet World Wide Ideas by Kismet World Wide No Comments