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.

Object-oriented fun

Kristine and I designed and are building a Friend class in our application framework that hopefully will make it much easier for other members of our group to contribute to the coding. We were concerned that the different learning curve shapes meant some members were getting left behind and not learning a lot. This class abstracts out the facebook backend plus our mysql backend, so all you need to do is create a

$person = new Friend(userId)

and then all of the things that are relevant about that person are available within php programmatically.

$person->getStatusMessage() will pull their current status message from facebook, while
$person->latitude() and person->longitude() will pull their locations from our mySQL database.

I suspect this will reduce performance - when we trying to display information for 10 friends at once, we will be hitting the facebook database/our database 10 times sequentially, rather than using their preferred array calls which get info for many users all at once (I did make it so all of the values get pulled from facebook at once, to at least somewhat limit the quantity of hits: if the desired member value is not yet set, it will call a member function to set all facebook values at once, and then if it is set, it will just display that value without talking to facebook again). However, performance is not what we're optimizing right now, right now we're just trying to make it a little easier to work inside our application framework.

Once again I'm learning practical uses of things I only had an academic appreciation for before... I've always "known" object-oriented programming, in that I created an object once in MAE 9, and knew that objects were containers for functions and variables. However, I've never really used it for a purpose, and now I'm excited at how useful objects are, how easy they make things.

Accessing GMaps javascript inside PHP

The integration hurdle I'm currently working on is accessing Google Maps javascript functions inside PHP. The reason Phoogle and the other wrappers I was able to find didn't cut it is they basically output javascript/html to the browser, they don't actually let php call the functions. They are very nice in accelerating the development of simple applications, but they don't truly re-create the GMaps API in PHP. What we'd like to be able to do is use getLatLng for the location the user enters and store that in the database, or let them choose a location if getLatLng isn't able to find anything for what they've entered.

The solution that I've come up with is to use AJAX - the page we're making the call from sends the user-entered location to another PHP page, which generates the appropriate javascript to make the call and output the collected information as XML, which then can be read by the calling page.

For now, I'm not really sure if I can implement that. Given the unpredicted constraints in learning curves and availability I've had to largely take over development of the GMaps portion of our application, and it may simply be easier to send the raw strings entered by the users over to GMaps, and if it can find a latitude and longitude for them, great, if not, oh well. Data validation is great, but we work with what we can.

Using MapLink / draggable markers

I was able to talk today with Beth Surrell from Tritonlink, who is putting me in contact with the programmer who created MapLink. Interestingly, MapLink was built by a student who just recently got hired on to work full time for Tritonlink. I'm still waiting for the communications to filter through, but hopefully we can begin working on that part of it soon.

In class on tuesday the Google Maps presentation gave me a lot of new ideas about the ways we can use Google Maps in our interface. The draggable marker could easily be used for a person to set their location graphically, making data validation much easier. We can be relatively confident that the latitude and longitude of a GMarker is valid; with text input we need to run the geocoding function and check to see if we get lat/long values back. Potentially this could also be used for community geocoding: users type in something textually, and if we/google don't recognize the location, we can say "okay, find it on a map for us". Then they will drag the marker to the correct place on the map, and we can store that data in a separate table for the next time that user, or indeed any user wants to use that location.