This chapter is from the book
This chapter is from the book
This chapter is from the book
Step 6: Security and Privacy Plan
Now we come to the security and privacy plan. At first glance, this app has very little security or privacy need. All of the data on the schedule side is public. You do not need to authenticate if you want to know when the next train is arriving. There’s not a whole lot to be concerned with.
Certainly someone who steals the phone can see which train line the user has been looking at, and it’s a pretty good bet that’s the one she’s been riding all along. A user has far worse things to worry about if her phone gets stolen, like the content of her text messages. A user will secure almost anything else, even her Kindle reading list, before she cares about locking up her train schedule. If a user does worry about her commuter rail profile becoming public, she’ll get a phone that encrypts its entire contents and locks it all up with a fingerprint reader.
The only piece that needs to be secure is the credit card number used for purchasing tickets. It’s important to store it in a way that the user doesn’t have to take out her credit card and type it in every time. A user doesn’t want pickpockets or purse snatchers in a rush hour station to get a look at her wallet. The choices are to store the number on the phone itself, perhaps encrypted, or store it on a central server, like Amazon does, and fetch it when she wants to purchase a ticket.
Which will users prefer? It might depend on when we ask them. If there had been a data breach in the last few weeks, like the one that hit Target in 2013, they’ll want it stored on the handset. They’ll figure a bad guy will focus on hitting big targets where he can steal millions at a time, not one at a time by stealing phones. There’s not a whole lot you can do to prevent that. On the other hand, if Claire wants her monthly pass to automatically renew, she has to give the T some sort of ongoing financial authority, whether it’s credit card or automatic checking account withdrawal. And once it’s there, we might as well keep it all there.
With privacy, our biggest problem will be the tracking of user movements and locations. In theory, this information becomes a problem only when it is personally identifiable. We could give each user a unique identifier, a random number assigned when the app is installed. We would know that anonymous user 24168302 went into town on the 6:00 a.m. train and came home on the 4:30 p.m. train. We wouldn’t know that particular user was Mary Smith, but we’d know somebody did it. We could then work out individual profiles, which could be of great use to data miners.
The problem is that if we collect this information, it’s liable to get abused somewhere. We could, or someone could, correlate user movements with ticket purchases and work out who each user was.
Suppose the news leaked out that the T was collecting the movements of individual riders. “To serve you better,” they’d doubtless say. “We’re only doing good stuff with it.” What do you suppose the local Fox News affiliate would do with that story? How long would it take for customers to ditch our app? That’s like the dentist saying, “This won’t hurt.” No, it won’t hurt him a bit, will it? Suppose one of the programmers got caught stalking an ex-girlfriend?
As riders, we don’t have an intimate relationship with the T. We don’t have any reason for them to be tracking us as individuals. I’d suggest that this app should not collect data on specific users, even if it’s anonymized. If we’re not recording it, we can’t possibly leak it. Project managers will sleep a whole lot more soundly at night that way.