Interesting People mailing list archives
Client/Server and the BAD IDEA OF THE WEEK
From: David Farber <dave () farber net>
Date: Sun, 24 Apr 2005 15:42:28 -0400
------ Forwarded Message From: Brad Templeton <btm () templetons com> Organization: http://www.templetons.com/brad Date: Sun, 24 Apr 2005 12:34:10 -0700 To: David Farber <dave () farber net> Cc: <whitney () absono us>, <lauren () vortex com> Subject: Client/Server and the BAD IDEA OF THE WEEK
With Google only storing history if you log in, as well as offering a "pause" functionality to allow users to keep certain searches out of their history, this strikes me as a pretty reasonable implementation (though I'll admit that I've only played with it a very little bit).
A frequent computer engineering debate occurs over whether it is best to do applications on the client or on a central server. There are various reasons to go in each direction. Server apps can benefit from economies of scale, and central maintenance. Client apps can provide faster response and better UIs at the endpoint, and those familiar with the end to end principle will have read other convincing arguments. When it comes to searching the internet, the case for a server is overwhelming. But there is another, non-engineering question which plays a role in the client/server decision, namely privacy. There is some data that just makes sense to be on your personal endpoint. Or, if that's not easy to do from an engineering standpoint, data which should be encrypted in the server and accessible only using keys kept on the endpoint or on the person (or in the brain) of the user. So the question may not necessarily be whether engines should do a search history. (Though my own search history is indeed frightening. I recall one point where, to see what Google would sell ads on and what they wouldn't, I deliberatley searched for kiddie porn and all manner of other unpleasant things.) The question should be, "How can we put the private information into the client?" Your own search history might serve you well -- stored by your browswer or a plug-in to it. This assures that you retain control, and that attempts by others to access it have to go through you. Storing such things (and search history is only one example of a class of items) on the client sometimes is more work, and gives up some advantages of server computing. But in this case it's worth going that extra distance, and possibly sacrificing a feature here or there. Another good example are all these "unified identity" projects such as Passport, Liberty Alliance etc. Why have a central server store my personal data. Here the win for server apps (namely roamability and ease of software maintenance) is pretty minor compared to the risk. The effort to just build tools to manage your identity on the client makes much more sense. ------ End of Forwarded Message ------------------------------------- You are subscribed as lists-ip () insecure org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/
Current thread:
- Client/Server and the BAD IDEA OF THE WEEK David Farber (Apr 24)