Using Mobile Phones for Secure,Distributed Document ...15-821/READINGS/PAPERS/parikh2005.pdf · CamForm applications In designing CAM services, we found it convenient to refer to

74 PERVASIVEcomputing Published by the IEEE CS and IEEE ComSoc ■ 1536-1268/05/$20.00 © 2005 IEEE

T H E S M A R T P H O N E

Using Mobile Phones forSecure, DistributedDocument Processing inthe Developing WorldPaper plays an essential role in many information ecologies in thedeveloping world, but it can be inefficient and inflexible. The CAMdocument-processing framework exploits smart mobile phones’ utility, usability, and growing ubiquity to link paper with moderninformation tools.

We’ve recently seen growinginterest in the digital divide—the division between peoplewho use modern digital toolsand information services for

personal or professional purposes and those whodon’t. This has given rise to the optimistic notionthat if digitally disenfranchised people in ruralareas of the developing world can adopt infor-mation technologies in a sustainable way, theycan achieve many development objectives. TermedInformation and Communication Technologies

(ICT) for Development, thisvision carries a broad man-date—allowing billions of peo-ple access to services as impor-tant and varied as health care,

education, and financial and governmental ser-vices. While initial implementations have far togo before they claim any definitive successes, thisidea has great intellectual and moral appeal. Ourproject team has worked on several projects thatsought to make this vision of low-cost rural infor-mation services a reality.

Even as currently posed, rural and pervasivecomputing share many infrastructural, interface,and application-level themes. The basic problemis to introduce computing seamlessly into a phys-ical, natural world populated by nonexpert userswho can’t, don’t, or would rather not spend their

time in front of computers. These users aren’tknowledge workers, don’t use modern informa-tion technology as part of their daily lives, andwould like maximal utility from computingdevices with minimal engagement. At a systemslevel, both rural and pervasive computing faceenvironmental constraints in power, network con-nectivity, and cost-bearing capabilities. Moreover,applications in both domains must build valuechains around technological innovations that canhave a real, beneficial impact on people’s lives.

The smart phone is our pervasive informationappliance of choice. Its communication facilitiesoffer immediate utility to any user, urban or rural,rich or poor, which lubricates its introduction toany context. The numeric keypad’s familiarityand long history make it comfortable for billionsof users. Solid state memory, extended batterylife, and a compact, rugged form are all greatdesign choices for the village environment.

The CAM frameworkWe’ve developed an information services archi-

tecture that uses a smart phone equipped with abuilt-in digital camera to process augmentedpaper documents. CAM, so called because thephone’s camera plays a key role in the user inter-face, is a three-tiered, document-based architec-ture for providing remote rural information ser-vices. The user tier comprises a set of paper forms

Tapan S. ParikhUniversity of Washington

and artifacts that people use to recordinformation, perform queries, and con-duct transactions. The server tier is astandard Web application server, whichcan reside locally, in a nearby town, orvirtually in the Internet ether. The mobilephone acts as a roving middleware, play-ing the role of scanner, user interface,network, cache, and preprocessor. Fig-ure 1 presents the CAM architecture’soverall structure.

The CAM framework comprises fourcomponents. Users initially interact withCamForms, which are augmented paperapplications. The CamShell scriptinglanguage is used to embed processinginstructions in these forms, which theCamBrowser mobile phone applicationscans and processes. CamBrowser con-nects to a local or remote CamServer,which receives and organizes CamFormsubmissions and supports additionaldata entry and document processing.

CamForm applicationsIn designing CAM services, we found

it convenient to refer to sets of aug-mented paper documents as CamFormapplications. Each document can repre-

sent a distinct query or data entry action,one step in an action sequence (as in thecase of a multipage form), or a previousaction’s result. Taken together, Cam-Forms give a view of the application’scurrent state and provide various inter-action options with a distant server, notunlike a traditional client.

Paper has several advantages. Havingdaily lives filled with physical tasks, ruralusers are much more comfortable withartifacts they can handle and touch.Paper affords a physical representationof information that can be communallyviewed, edited, and stored. In somecases, illiterate users have even learnedto interpret data from paper forms. Forthe time being, it’s unlikely that anyaffordable digital interface will be suit-able for this kind of use.

However, paper is notoriously bad forother uses. You can’t easily search, index,or archive it. Using it to perform calcu-lations and create consolidated reportsis difficult. In our work with communitymicrofinance groups around the world,we found that data consolidation andreporting using manual, ledger-basedsystems is virtually impossible. We

needed a way to digitally capture infor-mation from paper and let computingsystems do the things they’re good at. So,we had to find a way to link the physi-cal world of paper with the digital worldof information.

CamShellWe use CamShell to embed processing

instructions in CamForm documents. Acamera-equipped mobile phone runningthe CamBrowser application interpretsthese instructions, which use the phone’suser interface and networking librariesto process and route the document.

We embed data in our forms using the2D visual-code-recognition library thatMichael Rohs and Beat Gfeller devel-oped.1 This package lets the phone’scamera scan 83-bit 2D codes (includingseven bits of error correction). Because of this substrate size, CamShell is com-posed of fixed-length, 76-bit instruc-tions. When mobile phones with higher-resolution cameras are more widelyavailable, the data-carrying capacity ofthis substrate should increase accord-ingly, and we’ll be able to make CamShellmore expressive. In the meantime, we’ve

APRIL–JUNE 2005 PERVASIVEcomputing 75

3G MMS

Kiosk

Transport

Phone

WWW

WorldTownVillage

Bluetooth

Scan

Paper form

HTTPMultimedia messaging

service message

Print

Figure 1. Three-tiered CAM framework. CAM provides the appropriate information medium for each context. Rural users transfer paper-based information to roving smart-phone middleware, which uploads the data to remote storage for distribution in various ways.

designed a compact but powerful pro-gramming language that’s sufficient formany uses.

Each instruction encodes its sequencenumber in the first four bits. Code recog-nition isn’t exact, so the phone might notrecognize all the codes embedded on aform in one scan. In a sense, it mustreassemble the program from the indi-vidual codes after scanning. The sequencenumber is useful for ensuring that thephone executes each of the instructionsin the proper order and completes allinstructions before the program’s end.The main instruction classes are

• assignment instructions, which assigna 32-bit value to a 32-bit identifier.They can be used to encode hiddenvalues in documents.

• dialog instructions, which launch dif-ferent types of dialogs (number, cur-rency, date, text, and so on), letting theuser transcribe data from the docu-ment. The user-entered value isassigned to a 64-bit identifier, whichserves as the dialog prompt. Thisinstruction can also be used to sendnotification messages to the user.

• control and arithmetic instructions,

which are used for simple arithmeticand branches. They’re useful forencoding loops—for example, whenreading data from a table.

• application-launching instructions,which open other applications in sep-arate threads (such as Web and Wire-less Application Protocol browsers),sending the current variables as formparameters. Other options includemaking a phone call or sending a mul-timedia messaging service (MMS)message.

• multimedia instructions, which openpredefined audio and image files.These provide for audio and graphi-cal prompts, which we’ve found use-ful for interacting with semiliterateusers. In our current implementation,prerecorded voice prompts accom-pany all dialogs if so desired.

• networking and security instructions,which provide for secure communica-tions with CamServer.

CamShell programs are composable—that is, if you have a multipage form ordifferent sections of a program on sepa-rate documents, you can scan them insequence or overlay them as long as the

sequence numbers match up. This letsyou compose several physical artifactsand documents together for a singlerequest.

CamBrowserThe CamBrowser application’s pri-

mary purpose is to capture a visualimage of the form and decode and inter-pret the embedded CamShell program,which executes the user interface thatcollects information from the user. CamBrowser executes instructions insequence, starting with instruction zero.Internally, a simple virtual machinekeeps track of the current programcounter and local variables. You canscan codes either by pointing the cam-era at the CamForm (scan mode) or byexplicitly taking a picture (click mode).We’ve found the former to be more suit-able for quick, directed user interaction,while the latter is more effective for cap-turing an entire CamShell program andentering large amounts of data—forexample, in a loop.

We’ve avoided using optical characterrecognition because of its high error ratesand associated usability concerns. Usersmust manually transcribe all the Cam-Form data using the phone’s alphanu-meric keypad (see Figure 2). In the future,we’re considering adding simple recog-nition features, such as automatic popu-lation of checkboxes or selection ovals,and delegating some recognition tasks tomore powerful upstream servers.

The CamBrowser application executesuser instructions until it encounters anetwork or application request. Therequest can be one of three types: a URL,a phone call, or an MMS message. Theinterpreter executes the request using theappropriate application, with the localvariables as the request content.

In the case of a URL, the phone canoperate in one of three network modes:

76 PERVASIVEcomputing www.computer.org/pervasive


Figure 2. A prospective user enteringCamForm data using the mobile phone’salphanumeric keypad.

• online, in which the phone executesHTTP requests over an Internet con-nection.

• offline, in which the phone cachesrequests locally and executes themlater when it has connectivity, eithervia a short-range (Bluetooth) or long-range (Internet) connection.

• proxy, in which the phone acts as aproxy interface for a nearby PC, for-warding requests over a Bluetoothconnection. The PC’s Web browserprocesses and displays these requests.

These network modes let users choosewhere and how to incur communica-tions costs. If they live in an area wherethe cellular network isn’t good, or if ser-

vice costs are disproportionately high,they can physically carry the phone to abetter connected location.

Users can view the response documenton the phone’s screen, on a nearby PC,or printed from a connected printer.Response screens can include furtherCamShell scripts, which users can scanfrom the screen or from a printed copy.The scripts can include scannable linksto further content or can act like wizardsthat construct new CamForms based onprior input.

CamServerThe CamBrowser connects to the

server via HTTP requests to standardWeb applications, which can be written

in any scripting language, such as Perl orPHP. The CamBrowser also uploadscaptured images to the server for a visualrecord or further upstream processing.

We’re refining our model using XMLto provide generalized document ser-vices. In the new model, users scan andthen package CamForms into an XMLfile containing the image, the data theyentered, and the CamShell program.This package is sent over the network,where the CamServer receives it. TheCamServer organizes CamForm sub-missions and supports further browser-based data entry and document pro-cessing. This lets phone users delegatecertain tasks upstream, allowing morearduous data entry or recognition tasks


D uring our work with community groups in rural India, we

found that paper plays a critical role in many work practices.1

It’s used ubiquitously for data storage and exchange and establish-

ing trust between transacting parties. It’s an information medium

the local people own and trust, and it provides a greater sense of

security than rented or borrowed appliances. On the basis of these

observations, we concluded that, for now, paper should be retained

as an integral part of the rural information ecology.

Other researchers have commented on paper’s importance in

workplace settings and sought ways to improve coordination

between paper and digital media.2–5 Companies have extended

these efforts to develop commercial document-processing systems

that recognize structure and text from scanned paper forms and

integrate them with back-end data sources.6 Most recently,

researchers have developed visual codes to embed camera-

scannable digital data in physical documents.7–9 These efforts have

sought to augment paper—to integrate it with a digital world that

can index, search, and retrieve information with great flexibility.

Our work builds on this tradition in several ways. First, this is the

first project that uses a mobile phone as a primary data-capture

and -entry device in a document-processing system. Second, we

introduce the CAM framework, including CamShell—a phone-

scannable scripting language that can encode a user interface

along with processing and routing instructions within paper docu-

ments. Third, we present mobile document processing as a cost-

effective and accessible way of providing information services to

remote areas in the developing world.

REFERENCES

1. T. Parikh et al., “Design Studies for a Financial Management System forMicro-Credit Groups in Rural India,” Proc. 2003 ACM Conf. UniversalUsability (CUU 03), ACM Press, 2003, pp. 15–22.

2. A. Sellen and R. Harper, The Myth of the Paperless Office, 1st ed., MITPress, 2002.

3. W. Mackay, “Is Paper Safer? The Role of Paper Flight Strips in Air TrafficControl,” ACM Trans. Computer-Human Interaction, vol. 6, no. 4, 2000,pp. 311–340.

4. W. Johnson et al., “Bridging the Paper and Electronic Worlds: The PaperUser Interface,” Proc. SIGCHI Conf. Human Factors in Computing Systems,ACM Press, 1993, pp. 507–512.

5. F. Guimbretière, “Paper Augmented Digital Documents,” Proc. 16thAnn. ACM Symp. User Interface Software and Technology (UIST 03), ACMPress, 2003, pp. 51–60.

6. “IFP Success Stories,” IBM, www2.clearlake.ibm.com/GOV/ifp/success_stories.html.

7. J. Rekimoto and Y. Ayatsuka, “Cybercode: Designing Augmented Real-ity Environments with Visual Tags,” Proc. Designing Augmented RealityEnvironments (DARE 2000), ACM Press, 2000, pp. 1–10.

8. D.L. Hecht, “Printed Embedded Data Graphical User Interfaces,” Com-puter, vol. 34, no. 3, 2001, pp. 47–55.

9. M. Rohs and B. Gfeller, “Using Camera-Equipped Mobile Phones forInteracting with Real-World Objects,” Advances in Pervasive Computing,A. Ferscha, H. Hoertner, and G. Kotsis, eds., Austrian Computing Soc.(OCG), 2004, pp. 265–271.

Integrating Digital Media into Paper-Based Information Ecologies

to be done on a PC. In this way, the sys-tem provides flexibility in the trade-offbetween recognition and local andremote data entry.

SecurityThe CAM architecture’s distributed

nature makes security an important con-cern. CamShell provides instructions forperforming encryption, digital signing,or both (signcryption). These instruc-tions include digital keys and can beembedded either directly in CamFormsor within special security tokens, calledCamTokens. When the CamBrowserprocesses these instructions, the softwareautomatically signs and/or encrypts thecollected data before transmission. CAMapplication developers can use theseinstructions to create secure, signed com-munications channels between a Cam-Form client and the CamServer.

Usability concerns in maintaining sys-tem security have recently received atten-tion in the literature.2 Rememberedtokens such as passwords and PINs havecome under fire as being inflexible andinsecure. Conversely, humans have along history of trust practices builtaround exchanging physical tokens (forexample, money). Physical keys asimplemented in CamShell might be moreusable in rural areas because

• they carry more information. Mostrural users are unlikely to remember

long or unfamiliar combinations ofletters, and their remembered pass-words would be vulnerable to cracks.Physical tokens can carry much moredata and would be easier to replace ifcompromised.

• users can enter them securely. Ruralusers are unlikely to have the capacityor unfettered access to enter a con-ventional password or PIN withoutothers observing it.

• users can explicitly share and distrib-ute them. Physical tokens can have anarbitrary nonzero duplication cost, sousers can distribute, lend, or sharethem with fixed risk.

The notion of uniting physical andinformation security isn’t novel. Mag-netic stripe cards, smart cards, andradiofrequency identification tags(RFIDs) all take this approach. CamTo-kens stake a middle ground betweenthese alternatives and the rememberedtoken schemes popular on the Internet.While they’re not as hard to duplicate asother physical approaches, CamTokenswould require an explicit and protractedaction to forge or steal in a village. Inrural areas, a printer or photocopiermight be hours to days away.

At the same time, CamTokens’ pro-duction cost isn’t out of reach for the com-munity. This lets the community createand issue CamTokens, in contrast tosmart cards and RFIDs, which require

external manufacture and management.Anne Adams and Martina Angela Sassehave shown that most secure informationisn’t kept private, but is shared within acircle of people who have some temporaltrust relationship.3 This is even more truein the family-based but tumultuous envi-ronment of a rural village. With Cam-Tokens, village users can easily experi-ment with different security schemes.

We’re working on encoding public,private, and shared one-time keys usingCamTokens. The CAM framework usesthese to create PGP-like secure commun-ication channels between independentparties or to provide one-time securechannels between a user and a serviceprovider. Because we can exchange secu-rity tokens physically through readilyavailable “back-channels,” we avoidusing a centralized public-key infra-structure that plagues current public-keyimplementations.

TrustTrust was another important consid-

eration in the CAM user interface’sdesign. In most cases, CamForm userswon’t have direct access to a mobilephone and will therefore have to rely onlocal phone-equipped agents to captureand transmit their data. Because of themobile phone screen and keypad’s lim-ited size, it’s difficult for these users toensure that the information entered inthe CamBrowser matches the valuesthey’ve provided on the form. We’reexperimenting with several ways toaddress this difficult issue.

First, the system can transmit theform’s scanned image to the CamServerto provide an online digital representa-tion of the form as the user entered it.Second, users can retain the physicalCamForms as records of their transac-tions. Third, the service provider cansend a printed summary from the Cam-Server to the user acknowledging receiptof the transaction and its content.



Figure 3. Self-help group membersreviewing notes in rural Tamil Nadu, India.

Finally, we’re implementing audio feed-back using text-to-speech to let usershear the data as it’s being entered.

Because we’ve found audio to be oneof the most important factors drivingCAM interaction, we expect the lastmethod to most effectively and immedi-ately reassure users that their data hasbeen entered and transmitted correctly.However, system implementers canchoose any of the methods outlined aboveto ensure user trust in their application.

Self-help group applicationsOver the past few years, we’ve been

designing and implementing informationsystems for self-help groups. SHGs aresemiformal, community-owned finan-cial cooperatives (see Figure 3). In India,they usually include 15 to 30 members,almost always women. Each membercontributes a fixed amount of money atregularly scheduled monthly or weeklymeetings. The group lends this commu-nity capital to members for education,health care, buying agricultural inputs,starting a business, and so on.

In India, once these SHGs haveachieved maturity and accumulated acertain amount of capital, they’re eligi-ble for loans from commercial banks.Under a National Bank for Agricultureand Rural Development program, loansto SHGs are refinanced at preferred inter-est rates, creating a viable business oppor-tunity for banks working in rural India.

We’ve created two CAM applicationsthat we believe will help SHGs achieveindependence and economy of scale,greatly expanding the reach of this fledg-ling community revolution.

SHG-NotebookLocal nonprofit nongovernmental

organizations (NGOs) most commonlyform and train SHGs. Government agen-cies, banks, international NGOs, and for-profit companies might also play a role.

These organizations assume thatalthough organizing and training SHGshas significant costs, the groups will even-tually become independent, no longerrequiring regular technical assistance.

However, SHGs have many detailedinformation management tasks. Theymust maintain accurate internal records,recording transactions and current bal-ances for group members. Moreover,they must use this information effectivelyto collect outstanding payments andguard against fraud.

SHGs keep their records in physicalnotebooks and ledgers, which requiressignificant rigor in bookkeeping meth-ods. Most SHG members in India arepoor rural artisans, laborers, or farmersunable to manage these records’ com-plexity. So, they permanently rely onlocal literate people and NGO staff tomaintain their records and mediate dis-putes. NGOs must often vouch for thegroups’ records when approaching abank for a loan. This dependence onNGOs limits the groups’ independenceand self-sustainability.

We’re working on SHG-Notebook asa way for SHGs to digitally transcribetheir records for bulk processing. SHG-Notebook captures the minimal amountof information required for SHGs’accounting and loan tracking. SHG

members can take the SHG-Notebookto a kiosk, where a local phone-equippedagent can scan the records with the Cam-Browser and upload them to the server.The group can request monthly state-ments and financial reports from theagent for a small fee. This creates a com-mercial service-based model for SHGdata management.

Some organizations have attempted tocapture data from SHG group meetingsusing PDAs.4 Our system offers advan-tages in terms of the paper user inter-face’s usability, the use of a mobile phonecamera as the data-collection device, andthe proposed service architecture’s scal-ability and sustainability.

SHG-CheckbookThe high cost associated with money

transport is another significant overheadin interacting with SHGs and othermicrofinance clients around the world.After microfinance group meetings,clients or NGO staff often must travelto and from bank branches with largeamounts of cash to make group depositsand withdrawals. As microfinancegroups usually meet according to a reg-ular schedule, thieves can easily predictwhen such individuals might be travel-ing through a particular area.

In one case, the manager of a large


Figure 4. A CamID used in the SHG-Checkbook application.

microfinance organization told us howone of his staff was murdered duringsuch a robbery. In another case, an NGOhad to equip its officers with private carsbecause public transit was consideredunsafe. Moreover, while funds are intransit and financially idle, someone—in most cases, SHG members—must payfor the interest that should be accruingon that money.

Transacting in cash also increases thepotential for fraud by SHG members andNGO staff. NGOs and other microfi-nance service providers usually can’t offertheir clients flexible savings accountsbecause it would be too difficult to trackhow much money should be collectedeach day. This leaves the door wide openfor fraud that could take weeks to trackdown. Several of the organizations we’veworked with have caught staff membersunderrepresenting client payments.

We’re working on SHG-Checkbookas a way to enable secure, human-mediated electronic transactions inremote rural areas. SHGs would conducttransactions with a registered bankingproxy equipped with a mobile phonerunning CamBrowser. These proxiescould be traders, merchants, or otherlocally known persons. Later, the bankor NGO would settle client accountswith the proxy in exchange for a pre-determined service fee.

When processing an SHG-check, theproxy banker first scans the member’sCamID, as shown in Figure 4. This pop-ulates the member ID and group IDfields and provides the user’s private key.The proxy banker then scans the check,which provides the remaining informa-tion for the transaction. The banker thuscombines the CamID and SHG-check

documents into a single CAM request. SHG-checks carry both the bank’s

public key and a one-time shared key.The system encrypts the request usingthe bank’s public key and signs it withboth the user’s private key and the one-time shared key, ensuring the message’sconfidentiality and authenticity.

Using SHG-Checkbook, SHGs canwrite checks to members to disburseloans and use deposit slips to keepunused funds in interest-bearing bankaccounts. This electronic currency wouldlet SHGs maintain local liquidity with-out wasteful and dangerous physicalhandling of money.

Usability testingWe conducted three days of usability

testing and design workshops with SHGmembers, community leaders, and sup-porting staff in Pulvoikarai, Tamil Nadu,in mid-January 2005. Although adetailed analysis of this data is pending,our initial impressions are remarkablypositive.

The users we tested had never used acamera or a PC. Most had never used amobile phone, although they’d seen oth-ers using one. We found that most ofthese users were using the CamBrowserwith ease in five to 15 minutes. This wasa remarkable improvement in the learn-ing times we’d noted in our earlierresearch with a PC-based interface.5 Theaccessible locus of interaction affordedby paper CamForms and the guidedinteraction driven by the audio-enabledCamBrowser made introducing the sys-tem almost seamless. Out of the 14 userswith whom we conducted detailedusability tests, all found the system eithereasy or very easy to use.

We also identified some potentialusability concerns. Users weren’t com-fortable with the phone’s small buttonsand stylized design. Process breakdownsthat moved the focus away from thecamera-driven CamBrowser interfacetook great effort to resolve, often requir-ing external intervention. We’re explor-ing ways to address these issues, possi-bly through new hardware or softwareprototypes that are more specialized forCAM-based interaction.

Pilot implementationsWe’re planning the first pilot imple-

mentations of SHG-Notebook and SHG-Checkbook for summer 2005. We’ll con-duct them with help from our partnersekgaon technologies, the Covenant Centre for Development, and theMahakalasm SHG Federations. We’vebegun discussions with the local bank forlinking these applications with its infor-mation systems and internal processes.

In the meantime, we’ve been workingwith rural communities, companies, andsocial-service organizations to identifymore CAM applications. We’re target-ing a few application domains, includ-ing rural distribution tracking, agricul-tural scoring, government services, andpersonal communications. We expect todo at least one more pilot in one of theseapplication areas by summer 2005.

Our experiences designing,implementing, and deploy-ing information systems inrural India have shown that

the CAM framework offers significantusability, accessibility, and scalabilityadvantages over traditional informationservice architectures. Our system facili-tates the management of large amountsof information across a distributed,infrastructure-poor landscape dottedwith novice users. This is similar to manyexisting systems—even to the Internet as



the AUTHOR

Tapan S. Parikh is a PhD candidate in computer science at the University of Wash-ington. His research is focused on the design, development, and implementation ofaccessible information services increasing economic opportunity and potential forexpression in disconnected rural communities around the world. Earlier projects in-cluded the Hisaab project, which investigated user interface design for semiliteraterural users, and the Knownet-Grin project, a grassroots information network linkingrural innovators and entrepreneurs. Tapan received his MS in computer science fromthe University of Washington. Contact him at Univ. of Washington, Dept. of Com-puter Science, Box 352350, Seattle, WA 98195-2350; [email protected].

a whole. As we’ve seen in the developedworld, if this service is made available inan affordable, accessible way, there arealmost unimaginable new markets justwaiting to be created. We look forwardto helping create them.

ACKNOWLEDGMENTSSeveral colleagues have provided valuable feedbackand technical advice during the course of this project.I would specifically like to thank James Landay, ScottKlemmer, Ed Lazowska, David Notkin, Gaetano Bor-riello, Richard Anderson, and Ken Fishkin for their con-tributions. Kaushik Ghosh and Apala Lahiri Chavan ofHuman Factors India worked on earlier iterations ofthis research and are contributing to the CAM usabil-ity testing. ekgaon technologies and the Covenant

Centre for Development in Madurai, India, have pro-vided translations and are working on the pilot imple-mentations. Last but certainly not least, I thank thewomen of the Mahakalasm SHG Federations for theircontinued partnership and patience.

REFERENCES1. M. Rohs and B. Gfeller, “Using Camera-

Equipped Mobile Phones for Interactingwith Real-World Objects,” Advances in Per-vasive Computing, A. Ferscha, H. Hoertner,and G. Kotsis, eds., Austrian ComputingSoc. (OCG), 2004, pp. 265–271.

2. A. Whitten and J. Tygar, “Why JohnnyCan’t Encrypt: A Usability Evaluation ofPGP 5.0,” Proc. 8th USENIX Security Symp.,USENIX, 1999, pp. 169–184.

3. A. Adams and M. Sasse, “Users Are Notthe Enemy: Why Users Compromise Secu-rity Systems and How to Take RemedialMeasures,” Comm. ACM, vol. 42, no. 12,1999, pp. 40–46.

4. C. Waterfield, “CGAP IT Innovation Series:Personal Digital Assistants (PDA),” Con-sultative Group to Aid the Poorest,www.cgap.org/docs/IT_pda.html.

5. T. Parikh et al., “Design Studies for a Finan-cial Management System for Micro-CreditGroups in Rural India,” Proc. 2003 ACMConf. Universal Usability (CUU 03), ACMPress, 2003, pp. 15–22.

For more information on this or any other comput-ing topic, please visit our Digital Library at www.computer.org/publications/dlib.


EXECUTIVE COMMITTEEPresident:GERALD L. ENGEL* Computer Science & EngineeringUniv. of Connecticut, Stamford1 University PlaceStamford, CT 06901-2315Phone: +1 203 251 8431Fax: +1 203 251 [email protected]: DEBORAH M. COOPER*Past President: CARL K. CHANG*VP, Educational Activities: MURALI VARANASI†VP, Electronic Products and Services: JAMES W. MOORE (2ND VP)*VP, Conferences and Tutorials: YERVANT ZORIAN†VP, Chapters Activities: CHRISTINA M. SCHOBER*VP, Publications: MICHAEL R.WILLIAMS (1ST VP)*VP, Standards Activities: SUSAN K. (KATHY) LAND*VP, Technical Activities: STEPHANIE M. WHITE†Secretary: STEPHEN B. SEIDMAN*Treasurer: RANGACHAR KASTURI†2004–2005 IEEE Division V Director: GENE F. HOFFNAGLE†2005–2006 IEEE Division VIII Director: STEPHEN L. DIAMOND†2005 IEEE Division V Director-Elect: OSCAR N. GARCIA*Computer Editor in Chief: DORIS L. CARVER†Executive Director: DAVID W. HENNAGE†* voting member of the Board of Governors† nonvoting member of the Board of Governors

E X E C U T I V E S T A F FExecutive Director: DAVID W.HENNAGEAssoc. Executive Director: ANNE MARIE KELLYPublisher: ANGELA BURGESSAssistant Publisher: DICK PRICEDirector, Administration: VIOLET S. DOANDirector, Information Technology & Services: ROBERT CAREDirector, Business & Product Development: PETER TURNER

PURPOSE The IEEE Computer Society is theworld’s largest association of computing profes-sionals, and is the leading provider of technicalinformation in the field.

MEMBERSHIP Members receive the month-ly magazine Computer, discounts, and opportu-nities to serve (all activities are led by volunteer members). Membership is open to all IEEEmembers, affiliate society members, and othersinterested in the computer field.

COMPUTER SOCIETY WEB SITEThe IEEE Computer Society’s Web site, at www.computer.org, offers information andsamples from the society’s publications and con-ferences, as well as a broad range of informationabout technical committees, standards, studentactivities, and more.

BOARD OF GOVERNORSTerm Expiring 2005: Oscar N. Garcia, Mark A. Grant, Michel Israel, Rohit Kapur, Stephen B. Seidman, Kathleen M. Swigger, MakotoTakizawaTerm Expiring 2006: Mark Christensen, Alan Clements, Annie Combelles, Ann Q. Gates, James D. Isaak, Susan A. Mengel, Bill N. SchilitTerm Expiring 2007: Jean M. Bacon, George V.Cybenko, Richard A. Kemmerer, Susan K. (Kathy)Land, Itaru Mimura, Brian M. O’Connell, ChristinaM. SchoberNext Board Meeting: 10 June 2005, Long Beach, CA

IEEE OFFICERSPresident and CEO : W. CLEON ANDERSONPresident-Elect: MICHAEL R. LIGHTNERPast President: ARTHUR W. WINSTONExecutive Director: TBDSecretary: MOHAMED EL-HAWARYTreasurer: JOSEPH V. LILLIEVP, Educational Activities: MOSHE KAMVP, Pub. Services & Products: LEAH H. JAMIESONVP, Regional Activities: MARC T. APTERVP, Standards Association: JAMES T. CARLOVP, Technical Activities: RALPH W. WYNDRUM JR.IEEE Division V Director: GENE F. HOFFNAGLEIEEE Division VIII Director: STEPHEN L. DIAMONDPresident, IEEE-USA: GERARD A. ALPHONSE

COMPUTER SOCIETY OFFICESHeadquarters Office

1730 Massachusetts Ave. NW

Washington, DC 20036-1992

Phone: +1 202 371 0101

Fax: +1 202 728 9614

E-mail: [email protected]

Publications Office10662 Los Vaqueros Cir., PO Box 3014Los Alamitos, CA 90720-1314Phone:+1 714 8218380E-mail: [email protected] and Publication Orders:Phone: +1 800 272 6657 Fax: +1 714 821 4641E-mail: [email protected]

Asia/Pacific OfficeWatanabe Building1-4-2 Minami-Aoyama,Minato-kuTokyo107-0062, JapanPhone: +81 3 3408 3118 Fax: +81 3 3408 3553E-mail: [email protected]