A brief history of library technology in the South Pacific

Lately, I have been thinking about library technology in the South Pacific region. This is mainly due to the fact that I was supposed to have submitted a paper on the subject to the new CODE4LIB journal about a week ago (don't worry editors, I'm still writing!). I though it might help to think aloud and to give anyone out there a chance to correct my facts or put me onto new ones. Feedback is appreciated - please leave a comment below.

While the details are lost to history, libraries arrived to stay in the South Pacific along with the first missionaries. These early libraries in the region existed solely to support mission activities, especially education in mission schools. In 1909, the Carnegie Foundation built what is now the Suva City Library (no website, sigh), marking the first permanent presence of public libraries in the region. Towards the end of the colonial period larger libraries were established to support the work of large academic institutions such as the University of Papua New Guinea (found in 1965) and the University of the South Pacific (USP) (founded in 1968). More recently, international development funds have invested in the establishment of national libraries in the South Pacific such as the Cook Islands National Library (founded in 1993) and older national libraries in countries such as the Solomon Islands, Tuvalu, and Kiribati. It is worth noting that in some South Pacific countries, one large institution may serve as the de facto national library - for example, the Nelson Memorial Public Library in Samoa or the USP Library in Fiji.

But what of library technology? The few academic libraries in the region that predate the digital era certainly had the experience of card catalogues and all of the related trappings (In fact, many of the automated libraries in the region maintain these venerable artifacts after years of success with their system) and most small libraries in the region rely on the card or other manual instruments as the key tool for library operations. Computers came to the larger South Pacific libraries quite early - USP library went live with their first system in 1988. This was a VAX based Urika system similar to many employed throughout the developed world. Library automation eventually reached a substantial proportion of small and medium libraries in the region through UNESCO's promotion of the free CDS/ISIS library management system in the 1990s.

Around the turn of the millennium a very successful sales and marketing drive took advantage of the frustration with CDS/ISIS in the region - many countries lacked the required expertise to keep it operating - and replaced many CDS/ISIS installs with the commercial DB/TextWorks system running on Windows PCs. However, this approach also soon began to show weaknesses. While DB/TextWorks is reliable and easy to use, most South Pacific libraries lack the funding to purchase support and upgrades for the system. In addition, most libraries in the region purchased versions of DB/TextWorks that do not provide what are now seen as fundamental library system features such as the ability to import/export MARC, Z39.50/SRU support, and provision of web search (a.k.a. web OPAC). This has lead UNESCO to begin seeding the free open source Koha library system into major regional libraries in 2006. I have been fortunate to be involved in the two UNESCO funded Koha installations to date.

Of course, the world of library technology now extends far beyond the main systems that run our libraries, variously called library management systems (LMSs) or integrated library systems (ILSs). Library technology now gets into everything from remote database and Internet access, printing and photocopying, security technologies, self-checkout, online reference services (synchronous or asynchronous), meta-searching, link resolution, and too many more to name. It is safe to generalize that in the South Pacific, only the largest libraries utilize significant technologies beyond cards and an LMS; and even the largest libraries in the region are significantly behind comparable institutions in Australia and New Zealand when it comes to library technology beyond the core system.

Photo by: libraryman

Trust and DE

[Note to readers: Robert Martin and I have been having a blog2blog discussion about what he terms digital existence. You can see the start of the conversation here.]

You raised one point in your last post that fascinates me - audited Internet services. Before I get to that let me dispense with a couple other discussion points in no particular order.

Regarding Hushmail you wrote,

Since I am paranoid about my personal information, a better solution for my web mail might be something like Hushmail, which both Chris and I have used in the past. I stopped using Hushmail because you did, Chris, so maybe you can explain why you stopped using it.
[Crypto and DE, The Life and Times of Robert W. Martin. October 2, 2007]

This question really takes me down memory lane. Not only does it remind me of many years as a Hushmail user, but it also reminds me of what remains to this day my two most popular blog posts ever. This pair of posts on security and AJAX in March of 2005 still garner a few hits daily according to my vanity web monitoring. These posts have even been sighted, somewhat unflatteringly, in an IEEE conference address by Michael Sonntag, and in the O'Reilly book Ajax Design Patterns in connection with the Host-Proof-Hosting pattern. It is kind of cool as it is the only time in my life that my name is going to appear inside of an O'Reilly book other than when I scribble my name inside my own copies. In these posts, I discuss a general solution to using AJAX to provide cryptographic services, including digital signatures and cryptographic timestamps, to web applications. I also dissect the Java applet-based architecture of Hushmail as an illustration.

Anyway, why did I stop using Hushmail? Two reasons. First, the Java applet-based version of Hushmail that was available in those days (now they have a version that does not require Java) did not work through most corporate firewalls, which was a serious inconvenience to me. Second, from a pure usability stand point, other less secure email services such as gmail, yahoo mail and hotmail all left Hushmail behind in the dust. Still, it is fascinating that with the Java applet version of Hushmail, even the lead Hushmail sys admin could not decrypt my email. I have to claim ignorance on how the non-Java version of Hushmail operates.

You also wrote,

Your differential risk analysis did a good job pointing out that the two areas of concern are the mail client and the mail server. I agree that a well-chosen mail client and a well-chosen browser are arguably equivalent from a security point of view. The issue that comes to mind though is that your DE access point of choice might not offer a well-chosen browser.
[Crypto and DE, The Life and Times of Robert W. Martin. October 2, 2007]

Upon reflection, I missed a jarringly crucial point because my analysis factored out threats that are common to both scenarios under discussion: forget the mail server, can you trust your access point? From keystroke loggers to corrupt Java virtual machines, the permutations of potential threats to your privacy and security at the access point are countless. Cryptography has great potential to protect your messages across untrusted networks, and even on untrusted mail/data servers, but the access point is your encryptor/decryptor! How can you rely on cryptography when your encryptor/decrypto cannot be trusted?

Perhaps you have already suggested the answer in your previous post, "Someone like Gmail could help assuage my fears and increase my level of trust with them if they offered an audit service." If we take this notion one step further, you could also have audited Internet cafes or even audited shared workstations at the office. This workstation audit could provide some assurance that the workstation is free of malware, has no hardware keystroke loggers installed, and that the browser(s) and OS seem to be standard and unmodified at a certain patch level.

Similarly, your idea of audited webmail servers, and by extension other servers as well, is brilliant. One can imagine webmail and remote storage firms providing audited personal information access logs, and submitting periodic security audits and operational audits which would be published by trustworthy auditors in the public domain for all to scrutinize. (Note: I have always felt that credit bureaus ought to operate this way as well, but that is another topic.)

How would this be done? Who would the auditors be? Is there enough market pressure to compel webmail firms to submit to these invasive audits?

Photo by: michele pedrolli

Internet safety in Islands Business magazine

The October issue of Islands Business carries a very good cover story on Internet safety in the Pacific. There are some excellent comments from Rajnesh Singh, president of PICISOC:

"What is required in the Pacific is a structured user-education and awareness programme," said Rajnesh Singh, parent, IT specialist and chairman of the Pacific Islands Chapter of the Internet Society (PICISOC), a network of individuals interested in the development of the Internet in the Pacific islands. "At the PICISOC annual conference, PacINET, we have run Internet safety sessions in the past and these continue to be a common theme in recent conferences."

"Many (non-Pacific) countries have set up rather successful Internet safety groups which have done much to educate users on the dangers that exist and actions that can be followed to counter them. With the continuing proliferation of the Internet in the Pacific, we perhaps need to do the same, not as governmental 'control' but as a multi-stakeholder group initiative supported by governments."

Singh further suggested the review of computer/ICT curriculum in schools in the early stages so Internet safety issues can be covered.
[Cover story: the net and children, Islands Business, October, 2007]

There are also a few quotes from my recent Internet safety post such as the steps to creating an Internet safe home:

On dfiji.blogspot.com, the blogger Hammond-Thrasher offered a simple programme for Pacific parents to follow to help them supervise their children’s online activities—

• Step One: Choose a location for the family computer where you spend a lot of time, such as the kitchen or the TV room. Face the computer screen so that you can keep an eye on what is going on.
• Step Two: Spend time online with your child. Find a few minutes every day to sit down with your children and surf a sports website, see what’s new on Hi5, type a letter to a relative, organise family photographs online, or update the family blog.
• Step Three: Talk to your children about their online activities. Talk about the dangers they need to watch out for—use foreign news reports of online crimes involving children.

Credit to Dionisia Tabureguci and Islands Business for dragging this important issue into the light. Now I ask this question, how can we create a long-lasting Internet safety program in Fiji?
Photo by: djringer

Shed a tear for WFC

Big news in the Fiji blogoshere, notorious anti-government blog Why Fiji's Crying is offline. The Wordpress notice claims that the site was taken down by the authors. According to the metablog site technorati, the last post on WFC was approximately 48 days ago. There are no signs that this is an act of Internet censorship, although conspiracy theories abound.

If you are feeling nostalgic or just wondering what exactly RFC was, there are a few pages captured on the Internet Archive Way Back Machine. I have also written critically about WFC on at least one occasion.

Photo by: a short in the dark