April 2010 Archives

[cross-post from Veriplace Blog]

I ran across an interesting study the other day out of the U.C. Berkeley School of Information. The study considered the privacy provisions laid out in the W3C Geolocation API, and recommendations for its improvement. The Geolocation API is a part of the HTML5 specification, and as such will play an important role in location-based mobile web applications as mobile devices continue the rapid adoption of HTML5.

While the conclusions of the study were certainly excellent, I found most interesting the list of privacy-related criteria that were derived after considering a range of existing frameworks and standards. These are reprinted here:

1. Appropriateness: Is the collection of location information appropriate given the context of the service or application?
2. Minimization: Is the minimum necessary granularity of location information distributed or collected?
3. User Control: How much ongoing control does the user have over location information? Is the user a passive receiver of notices or an active transmitter of policies? Are there defaults? Do they privilege privacy or information flow?
4. Notice: Can requesters transmit information about their identity and practices? What information is required to be provided to the user by the requesting entity? What rules can individuals establish attach to their location information and transmit? Is there a standard language for such rules?
5. Consent: Is the user in control of decisions to disclose location information? Is control provided on a per use, per recipient or some other basis? Is it operationalized as an opt-in, opt-out or opt model?
6. Secondary Use: Is user consent required for secondary use (a use beyond the one for which the information was supplied by the user)? Do mechanisms facilitate setting of limits or asking permission for secondary uses?
7. Distribution: Is distribution of location information limited to the entity with whom the individual believes they are interacting or is information re-transmitted to others?
8. Retention: Are timestamps for limiting retention attached to location information? How can policy statements about retention be made?
9. Transparency and Feedback: Are flows of information transparent to the individual? Does the specification facilitate individual access and related rights? Are there mechanisms to log location information requests and is it easy for individuals to access such logs?
10. Aggregation: Does the standard facilitate aggregation of location information on specific users or users generally? Does the specification create persistent unique identifiers?

When designing Veriplace, we considered these very same questions. In some cases (such as appropriateness and minimization) the application developer is largely in control of managing these issues. Veriplace addresses these cases by working with the developer, ensuring that guidelines such as these are followed. In other cases (such as user control, consent and transparency) Veriplace is more actively involved, building these requirements and safeguards directly into the platform architecture.

Taken together, this is a great list, and expands in important ways on existing guidelines, such as the CTIA Best Practices and Guidelines for LBS. Although perhaps an implementation detail, I might add one item: Uniform Privacy Management Interface. As LBS services proliferate, it will become more difficult for the end user to effectively manage location privacy. Providing a unified, consistent interface for managing access to location across services will be critical to ensuring the simplicity and transparency necessary to safeguard user privacy.

Apples latest change to their iPhone Developer Agreement is anti-competitive, plain and simple.

Apple wants to take steps to ensure that the level of quality among the apps offered remains high. That makes sense. But to argue that banning the use of cross-compilers or other 3rd party developer tools is necessary to make this happen makes no sense at all.

OK, OK, I get it. That's not really it. We admit it, yes, it's really flash apps we don't want. We said no flash, and we meant it. By any means necessary. It appears that there is no length to which Steve Jobs will not go to kill flash. Flash is not perfect, and there's no doubt that some hideous things have been done with it. Yes, it can be slow on a Mac, and can grind Safari to a halt. Fine, send a message to Adobe, we will not pre-install flash support on the iPhone/iPad, etc. and here is why. Lay out the ground rules, that seems fair. But to actively take steps to make it impossible for end users to install it on their own, or worse to write it into the terms-of-service and developer agreements? Really?

Never mind, I see, it's not really flash per se, but rather a question of control. A world in which developers, God forbid, write to a single framework and cross-compile to the constantly growing list of mobile devices and application environments, is not in Apple's interest. We want developers to take advantage of our differentiating features, UI, etc. No, not want, demand. We demand that developers... Really?

Even if it is a matter of control, Apple should lay out the ground rules. Here is what we require in an application. Period. How you get there? That's up to you. This is the environment that lends itself to a level playing field and to innovation. That's really how we all win, isn't it?