Interalia

The Case for God by Karen Armstrong
My rating: 4 of 5 stars

Armstrong makes a compelling argument against what has been called the "new atheism". Debunking the use of a literal interpretation of the Bible as something wholly modern and something that would be completely surprising and foreign to followers of the Christian faith up until at least the Enlightenment, she argues that instead religion is not an intellectual concept or dogma, but rather it is something you do. That without an active involvement, religion loses its essential value.

I find this to be a striking counter-attack to the rather tired arguments made by the new atheists, and one I'm not entirely clear how to address. From a second perspective the argument may be made this way: the act of devoting oneself actively to the pursuit of a particular religious faith, through things like prayer, meditation, and the willful act of separating oneself from a purely rational approach to understanding this world we find ourselves in may in fact have the potential of exposing us (in a mental sense) to something that we could not otherwise approach through purely rational thought. In my mind this is an argument not easily reckoned with or pushed aside.

View all my reviews

It's fashionable these days to say that "privacy is dead". Take, for example, these comments from Mark Zuckerberg, CEO of Facebook. I can't decide if this is political on his part, or truly disingenuous. In either case, I could not disagree more.

The counter-example I like to give is very simple. It is the dinner conversation. Consider:

You've made it through a hard day at work. You make it home and sit across from the dinner table with your wife, discussing your day. You talk about what happened, share your feelings, etc. This is a healthy, rejuvenating experience.

Now imagine the same scenario, but instead of you speaking privately with your wife, the entire conversation is recorded. It MAY be viewable by your boss or your co-workers, your friends, your government, maybe even the entire world. Does this change things? Do you now have to be on guard, more careful? Is the experience potentially less healthy? Less rejuvenating?

It seems pretty clear to me. I'd consider just such an example as proof that privacy is not dead (yet).

Creating something new is hard. Yes, this is not news, but a few things hit home today for me that brought this into perspective. My company is trying to do something truly new in telecom and public safety, I should have known this would not be easy. I've identified the following sources of friction:
We'll get there.

[cross-post]

On Monday Location Labs announced the initial release of our Geofence Library for the iPhone platform in private beta. In many ways we believe this solution will set the standard both for how geofencing services are provided on the iPhone and other smartphone platforms, and more generally how location data streams will be derived from the mobile device.

Wikipedia defines a geofence as a "virtual perimeter for a real-world geographic area". In the mobile context, when a mobile device enters or exits the geographic area, the relevant caller (typically a mobile-resident or network-based application) is notified. Sounds simple enough, but of course the devil is in the details.

There are two key factors that complicate the implementation of a geofence solution in a mobile context. The first is location technology. Deriving location from a mobile device is not a new problem, dating back at least to the FCC E911 mandate, and as it turns out there is no single one-size-fits-all solution to this problem. As with many important engineering problems, there are trade-offs. The second, and related factor is battery consumption. For example, GPS, an important enabling technology for mobile location, is a battery hog, typically drawing 300-350 mA on a modern smartphone device (as reference, typical smartphone batteries have a capacity in the 1,200-1,500 mA hour range.)

On Monday, Apple released its latest version of the iPhone operating system, iOS4. One of the important advances Apple provided as part of this release is the ability to support background processes. This rectified an important deficiency in the iPhone platform, as other modern competing platforms have supported this for some time (Android, RIM/Blackberry, Symbian, etc.) It is also essential for supporting a geofencing capability.

The iPhone provides two separate capabilities relevant to the problem of background location access and geofencing. The first option, available in all versions of the iPhone operating system, is the standard location service. This is a callback-based API that will notify the caller when location changes based on configurable accuracy and distance change filters. The particular location technology used by the underlying OS is determined by Apple, and may involve GPS, WiFi triangulation or cell/sector triangulation. The second option is the newly introduced "significant change location service", which is a low-battery consumption option that presumably updates only on cell/cell-sector change, and will report even if the application has been suspended.

As it turns out, the iPhone significant change location service is simply not adequate for geofencing applications. In in-house testing on 3G and 3Gs devices, we see notification delays of up to multiple hours. It appears that Apple is too conservative here in terms of battery consumption.

A second, extreme approach would be to run GPS continuously (this can be accomplished using the standard location service with optimal accuracy settings.) Of course, if GPS runs continuously, you can trigger notifications very promptly when a geographic boundary is crossed. Along with this extremely low trigger latency behavior comes dramatic battery consumption which renders the battery drained within less than six hours, depending on the health of the battery and other service use.

Location Labs has taken a significantly more sophisticated approach. With the iPhone, we employ a combination of techniques and heuristics involving both the standard and significant change location services, intelligent interaction with the iPhone backgrounding and suspending logic as well as local awareness of proximity to the geofence boundaries. Together these allow us to offer a high quality firing latency guarantee (measured in minutes) while keeping impact on battery life to a minimum.

The release of our Geofence Library for iPhone is available in private beta, follow this link for details on participating.

- @sahotes

I recently came across this interesting juxtaposition of J.D. Salinger and Jack Kerouac in the New York Review of Books. I especially liked:

In a recent blog post Jason Calacanis suggested five ways Facebook could improve its position with regard to customer privacy. Although it is not clear from the post how serious these suggestions are, in this post I will take a closer look at the first suggestion, namely "add an export key".

To understand this, we need to consider what Calacanis means by this suggestion, and further, what it would mean for FB to allow this kind of export. Fundamentally, the value of a social network is contained in two things:

What Calacanis is suggesting is that users be given the ability to "export" these things externally so that they may be used to participate in other social services that would make use of them. Before addressing the likelihood of such a feature, let's first consider why the social graph is so important.

Social networks are about sharing information. Regarding the content I create, I don't always want to share everything with everyone. Some things, such as family photos, I may only want to share with family and friends. In the language of Twitter, these are the folks that are following me. Regarding content I consume, of all the content created, there's only a very small percentage I actually care about. This is typically content created by friends, family, colleagues, etc. These are the folks that I am following. Together, these make up the social graph. In other words, the social graph is a realization of folks and things I care about, and folks I am comfortable sharing my content with.

Any time a user logs into FB for the purposes of either sharing content or managing their social connections (or social graph), FB wins. From the user's perspective, they are building (at least part of) their social community around the FB ecosystem, and becoming more and more "locked in" to this network. This is in fact the primary goal (at least for now) of FB, namely, getting users to invest time and energy into building this relationship.

Based on all of this, it may seem counter-intuitive for FB to share this kind of information with outside parties, but that is exactly what they are doing with Facebook Connect. Facebook Connect allows external services to access profile and social graph information for consenting FB users. Of course they expose this not for the purposes of "exporting" the data for use in other social networks, but rather so that other services can build on top of this existing "social infrastructure", further strengthening their position in terms of having the end user "locked in" to their FB profile and social graph.

What Calacanis is suggesting is something very different. He is questioning the concept of ownership and the underlying closed nature of FB. He is suggesting in fact that FB support a more open environment where users are free to "pack up" their profile and social graph information and take it to another (potentially competing) social network.

In short, FB will not do this. And the bad news (at least for proponents of an open web) is that it doesn't really matter whether they do or not. Even if such an "export key" existed, there's no really compelling reason for anyone to use it. For this to be compelling to consumers, two things are needed: 1. Something about FB that makes them want to move out, and 2. An alternative place for them to move to. Or, as Mickey Roarke said in Rumble Fish: If you're going to lead people, you have to have somewhere to go.

Alternatives are possible, such as Diaspora, but it's still too early to tell whether or not such "open" efforts can overcome the network effect FB has so obviously achieved.

Recently, the question of using location derived from cellular networks for the purposes of law enforcement has come up in the courts. The DOJ under President Obama has appealed to a Philadelphia court an earlier decision that access to location requires a search warrant based on probable cause. In particular, the brief put up by the Obama DOJ states that as part of using a cell phone, the user assumes the risk that location will be accessible by the government.

The argument the government is making is essentially this: it is reasonable to believe that the user of cellular services understands that the service provider must have some knowledge of the whereabouts of the user in order to provide the service, and thus by participating in this service, they are in effect providing information about their whereabouts to the service provider, and in turn to the government.

OK, there are a number of obvious concerns I have with this line of argument. Here is my shortlist:


In short, I believe that instead of continuing to fight for these draconian measures initiated by the Bush administration, the Obama administration would be well served to move in favor of the Fourth Ammendment here and drop this appeal. It would not be a stretch to consider this issue in the context of Obama's promise while running for office to eliminate warrantless wiretaps.

A few weeks ago, Apple unveiled plans for it's upcoming release of the iPhone operating system. As part of these announcements there were some positive steps relating to location privacy. In particular, see this review in the NY Times.

Scott Forstall, Apple Sr. VP of iPhone Software, referred to "fine-grained settings" such as managing the list of applications with access to location and end-user notification settings.

This is an important step forward from the current smartphone and mobile web model where each application (or mobile web site) is silo'd with it's own permission settings.

There is no doubt that this is a complex issue. Although many arguments have been made as to why the FCC should not reclassify broadband under Title II, it now appears that this may be the only truly viable option. Laurance Lessig lays out the details in this recent presentation:

[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:

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.