Browsers vs. Application Environments and how that may affect privacy

I don't know if this blog is still being read or not, but here is my culminating post which results from a conversation I was having tonight...

Browers are obviously in a transitional phase between "browsers" and "application environments". Web-enabled applications (like email clients and so on) despite their more responsive interfaces seem to me to be declining in favor of the sheer convenience of web applications running in the browser. I'm one of the only undergrads I know who still uses an email client for my personal email, but even I am starting to use my gmail in a browser.

Another shift is the relevance of privacy. Many of these new applications rely on detailed usage data for functionality and monetization.

Web browsers are not designed to be application environments, and as such their responsiveness, usability, and power suffer, while development remains difficult.
It seems likely that one day web browsers will be more explicitly designed as application environments, although the questions of what will change will be extraordinarily difficult ones. Many of the benefits of current web applications could disappear if the application shift were poorly managed... total portability, no need to install, isolated in a "sandbox" from the computer, and more.

However, assuming that these problems were solved satisfactorily, having a more powerful system to build web applications could present an interesting compromise for privacy. Facebook's newsfeed relies intensely on both explicit and implicit behavioral data (as well as explicit preference settings, but those are less interesting) to filter the gargantuan feed into something manageable. Since most data is explicitly opted in to facebook - contact information, photos, etc. - this "underhanded" information gathering presents somewhat more of a privacy concern, especially concerns that this information will not be used only for usability but monetization. In a more powerful application environment however, this behavioral data could be collected and stored clientside, and the feed could be filtered on the client side as well. All facebook would need to do would be to push the continually updating algorithms and data-collection rules to the client.

Defining the walls between client and server would be tricky of course... Facebook could say they store that data on the client, but in a powerful application environment, it would surely have the ability to siphon off that data if it ever wanted to be sneaky. Practically speaking, this idea may be impossible to implement, but it's an interesting idea.

More generally... I can't wait until browsers get more app-friendly. I'm tired of my old-ish computer stalling for a second after I open the umpteenth google map and it loads all of that heavy javascript.

Client-side google

As the Open Past Midnight presentation mentions, it's hard to get google data into the database because all of the functions in the API are client side. We had been intending to implement a similar solution to what they did, but luckily discovered that google exposes its geocoding function through an HTTP request, which we can make from PHP.

Unpredictable Use Cases - An Exercise in Ambiguity

One of the trickier parts of developing an application is dealing appropriately with input and interaction that doesn't follow the exact model that you envision. In particular, we have to deal with "location" strings that may not map precisely to a location in google maps. Google maps does return an accuracy value to HTTP geocoding requests, but even when accuracy is low or the input is ambiguous, google will only return a single response. It would be great if we could present a "did you mean THIS, THIS, or THIS?" and show a map marker for each one, but we don't know if that's possible. So the best we can do is decide on an accuracy threshold that we will accept - we chose 4, which means that google can find the city, on the assumption that a person choosing to set their location will at least decide to specify their city. Ambiguity is still a major problem though - searching for "UCSD" is very ambiguous, and the top result that google currently returns is actually a location off campus. Currently we are just planning to reject such <4 inputs and request users to rephrase them or override the rejection, but if I get time before our presentation we will hopefully allow unknown locations to be added to our database (as mentioned in an earlier entry).

Object Oriented Un-Fun:why we dropped it

While our brief attempt to keep the interfaces between parts of the code straightforward using objects was a good idea, we ultimately dropped it for a couple of reasons. It was really slow - the nature of initiating and populating objects singly meant that when somebody had more than a few friends on the application it went realllly slowly, both for facebook's function calls (which are designed to operate on arrays of users to prevent this) and surprisingly our own mysql database... while the hosting is transparent to us, I guess the database may be hosted on a different server or even a different database from the server running our php code. The other reason is that making a globally-useful "friend" object just wasn't working out for us - the nature of developing a project with inexperienced users on the fast and on the cheap meant that we didn't know exactly what we needed/wanted and we were always changing things. When multiple functions are using the same object, it gets complicated. It turned out to be easier (on THIS scale - probably not on a larger or longer project) to just pass arrays between functions, because then we only had to manage the relationship between the functions that interacted.