What Does Privacy Mean in the Information Age?

I have long respected Bob Blakley‘s opinions on security and privacy issues (I don’t actually remember when we first met, but it would have been roughly in the mid-1990s I think).  He often defines privacy as “the ability to lie about yourself and get away with it” (see here for example, but he was saying it years before that too).  Note that his point isn’t that people should necessarily have a right to lie about themselves, but that thinking about whether they can or not is a useful way of measuring the otherwise abstract concept of privacy.

I often ponder whether we (that is, developers of mobile device software) are doing enough to help users look after their privacy.  It’s often stated that end users aren’t interested in privacy, or don’t value it appropriately.  Professor Ed Felten has written an interesting counterpoint to that view, and I think it is important that we provide users with easy-to-understand choices, so they can make rational and informed decisions about sharing their personal information.  I like to use Flickr as an example; their privacy controls are simple, understandable and widely used.  You might use Facebook as a counter-example; they have many different privacy controls and it’s not obvious (even for security professionals!) how to configure them sensibly.

An interesting case study for mobile is Google Latitude (now available in the Google Maps native client for S60 3rd Edition).  Many of my Symbian and Nokia colleagues have signed up recently, and I’ve been wondering how Bob’s definition of privacy might apply to it.   My inclination, as a security professional, is not to sign up; once you do, the fact that you may then choose not to share your location at a particular time, or with a particular person, is itself information about you.  I wonder how much privacy you might lose by implicitly sharing that information.  Think of it as a statement: “Craig is doing something that he doesn’t want you to know about” 🙂

So, this leads me to a question – can I use Google Latitude to lie about my location? It seems there is a manual “set my location” option, which is promising, but then I wonder how easy it will be for Latitude friends to tell the difference between that and GPS or cell ID-derived location. I also wonder if there’s an API I can use to update my Latitude location programmatically (I doubt anyone would ever bother with that, but it would surely be privacy-friendly to have the option).  Maybe I will sign up and have a play with it (or maybe I won’t, so you won’t be surprised if you get no response to a Latitude friend request ;-)).

What other privacy issues might there be on mobile devices (either in the OS or in applications) which we should worry about?

Security and Going Open Source

Over on the main Symbian Foundation blog, Tyson Key asks:

Out of interest, how would you deal with releasing the source code to “sensitive” parts of the combined Symbian OS/S60/UIQ/MOAP(S) codebase? Components involved with handling storing keys for DRM, certain hardware drivers, baseband/physical layer access code, and GSM, GPRS and UMTS radio stacks come to mind.

This is a very good question!  We’re clear on our goal, which is that devices using the Symbian Foundation platform won’t rely on any “security by obscurity”.  Although that can work (for a while) and can be a rational business decision in some circumstances, it’s not a long-term foundation for a good security architecture (especially not for one that’s going open source!).  We’ve been clear on this from the outset in designing the Symbian OS Platform Security architecture, and security is not going to be an acceptable reason for blocking the publication of any of the source code.

That said, of course real life isn’t that clear cut!  Many of the things you mention (DRM key storage, radio stack, etc.) need to work with the particular hardware platform in the device, and they aren’t (yet) standardised parts of the Symbian Foundation platform.  There are some things that need to be protected more strongly than you can do in software alone (the IMEI for example) and today phone manufacturers typically write custom code to talk to their hardware when is then embedded in the boot code, radio stack, DRM agent and so on.

The architecturally pure way to fix that is to define hardware adaptation interfaces (HAIs) which abstract the common features of these hardware security services (but at the lowest possible level of abstraction) and then generic platform components can be provided which call those HAIs, and device integrators can provide simple adaptations for the hardware platform they choose.

Today we are probably missing some of those necessary HAIs, but we hope that we will, step by step, identify which are missing, agree the definition of the HAI, and thus be able to provide a functionally complete set of generic open source components which anyone can take and build a working, secure device with a minimal amount of hardware adaptation.

That’s a quick run through of some of the issues I’ve been thinking about recently, but what do you think?