1. Introduction
Like many museums, the Hunterian Museum and Art Gallery at the University of Glasgow, operates a photo library service for the provision of images and reproduction rights for publication use of artworks and objects from the collections. Previously, the Photo Library service has been part of the remit of the Hunterian’s retail unit, and operated a “traditional” photo service, providing clients with prints for sale or transparencies on loan, for a fee, for up to three months.
As many museums have discovered, this is an approach that is very costly to deliver due to the considerable amount of administration involved. So much so that many photo library services can at best break even financially, and in many cases, including the Hunterian, a true audit of the service would show that the income generated from the activity fell short of the cost of providing the service. Thus, in the Hunterian’s case, being a department of the University of Glasgow, a situation existed whereby the University was de-facto subsidizing publishers to use the images of the Hunterian’s collections in their publications. It might even be argued that given that the University (and thus the Hunterian) is government-funded, the taxpayer was subsidizing the profits of commercial publishing companies!
Furthermore, in recent years museums have become a lot more concerned about passing prints and transparencies out of their control to third parties to digitize for publication due to the potential copyright issues that may arise as a result.
These considerations were brought into focus when in 2004, as part of a strategic review of operations, the Hunterian transferred the management of its retail operations to a commercial company set up and owned by the University. The Museum was reluctant to hand over control of its image assets to a commercial company and, therefore, needed to find an alternative “home” for the Photo Library. At this stage, the Head of the Hunterian’s Multimedia Unit was asked to take over management and development of the Photo Library, with a remit to improve the general service level and, in particular, the income-generation potential of the image resources.
2. Digitizing the Resource
Previously, because of its somewhat under-developed position within the retail unit, the Photo Library had existed somewhat in isolation of the advances in technology. The image resource consisted of many thousands of prints and transparencies stored in picture files within numerous filing cabinets. (See fig.1) Retrieval of images on receipt of a written, telephoned, or (the exceptional) e-mailed request required manual searching through the filing cabinets followed by dispatch by post and, in the case of transparency loans, follow-up written reminders to clients to return the item at the end of the loan period.
Figure 1: Labour intensive manual image retrieval.
It was, therefore, decided that the first task on the road ahead would be to digitize the image resource to prepare the content and the search processes for migration to a computer-based image retrieval system.
The University of Glasgow’s Hunterian Museum and Art Gallery is officially recognized under the Scottish Executive’s Recognition Scheme as having a collection of national significance. The collections are extensive and wide-ranging with just over one million objects, including one of the most distinguished public art collections in Scotland. The first challenge, in beginning the preparation of collection material for Photo Library use was, therefore, to assess customer demand for Photo Library resources and determine a schedule for selection and digitization which would both address the desire to generate a significant cache of digital images to begin the process of developing a retrieval system and which would generate images that clients actually wanted to purchase. Consequently a fair amount of “cherry-picking” of the collections was undertaken to take account of likely customer demand. In addition, some parts of the collections had already been digitized under various externally funded projects, and these items were incorporated into the first round of digital asset gathering. The decision was made to capture digitally or scan transparencies at 300 dpi producing a digital image of around 18mb suitable for publication quality to A4 size. This would meet the requirements of the vast majority of clients needs and would keep the ever-increasing demands on server storage space within manageable and reasonably predictable scales. This first collection of digital images, some 3000 in number were stored on photo CD’s with rudimentary indexes and contact sheet thumbnails. (See fig. 2)
Figure 2: Photo CD image folders.
Rudimentary as this CD folders set up was, it was a massive improvement on the staff time spent on image searching and retrieval. There were obvious time costs still inherent in such a system of image management, and back up of CD’s was time-consuming and laborious. It was, however, only a stopgap measure.
The next step was to construct a digital asset management (DAM) system. It was at this stage we engaged our colleagues in the University’s Department of Computing Science, with whom we have had a very long and fruitful collaborative partnership (more on that later). As ever we were limited by costs in deciding which path we might go down in terms of software purchases and development. In the first instance, therefore, we decided to develop an image retrieval system in Filemaker Pro Version 8. (See fig.3)
Figure 3: Screenshot of Filemaker Pro system.
While this was inexpensive and served our purposes rather well for a time, it worked far better as a stand-alone system, which the Photo Library staff could use on their own desktop machines rather than as a networked facility. We spent a considerable amount of time, and staff and student effort in evaluating a Web version of this system in 2005. The results of this evaluation, which was not undertaken lightly, resulted in a decision to abandon the existing system and find an alternative software package that would handle the simultaneous transfer of high-resolution files over the Web.
At this stage, we were fortunate enough to have as a visitor to our Multimedia Studio at the Hunterian, Donald Farmer, the Program Manager for the SQL software package at Microsoft in Redmond, Washington. We discussed with Donald our aspirations for a robust Digital Asset Management system and he suggested Microsoft’s SQL Enterprise Edition. Whilst this was an extremely attractive option for us, the cost of this software would have been considerably beyond our budget. However, Donald was very keen to support us in what he considered to be pioneering work, and came up trumps and arranged a very generous donation of software packages for us from Microsoft that in total would have cost around $100,000 at retail prices.
It may be useful, at this point, to discuss, in some detail, the factors taken into consideration when establishing the new DAM system in Microsoft SQL. To that end, we will now acknowledge the business connection to the technology and examine the project from the technical perspective.
The Hunterian Museum wants to increase the visibility of their products by increasing their presence on the Internet. The overall marketing approach strives to increase the visibility of the museum by increasing the museum’s asset exposure on their primary Web site as well as through merchants such as The Bridgeman Art Library (which is visible at http://www.bridgeman.co.uk). Therefore, the increase in exposure for the museum increases their potential points of sale, generating the possibility for increased revenue. The aspect of the marketing campaign that is of particular interest to this discussion involved all aspects associated with expanding their Web site so they can display watermarked thumbnails on the Internet. An additional benefit to making the images available over the Internet is the increased availability to departmental personnel.
3. HOPL Development
This section examines the security of the application from several perspectives. These perspectives included the HOPL security requirements, the development process, and the technology. The theory behind the approach is available in three technical reports that have been published in the University of Glasgow’s Department of Computing Science (Glisson and Welland, 2007a, Glisson and Welland, 2007b, Glisson and Welland, 2006).
3.1 Security Requirements
The security requirements identified in the initial discussion revealed the following information:
The Hunterian’s desire to maintain a high level of customer confidentiality through the protection of any data that is collected via the Internet. This level of data protection needs to be compatible with the Freedom of Information Act (FIA) and the Data Protection Act (DPA).
- The Hunterian also expressed a desire to have a level of system operation integrity which translates into a high confidentiality level in the system.
- The levels of security that the Hunterian indicated interest in protecting included defacement, communication and transaction.
- The Hunterian wanted to look into the use of image watermarking
- The Hunterian desired to look into the use of digital marking high-resolution images with something to identify the image with the customer.
- The Hunterian did have implicit procedures in place when examining disaster recovery. The University of Glasgow Computing Service was backing up the Web site and the low-resolution images that were currently associated with the site. The high-resolution digital images were backed up on different hard drives within the Hunterian. It should be noted that all of the hard drives were located in the same building, leading to a physical security issue. It should be noted that there was no formal disaster recovery plan in writing.
The basic security requirements revealed in the discussion above can be summarized as follows:
- High level of customer confidentiality and integrity
- Data Protection
- Operation Integrity
- Customer Communication
- Protection of Images via Water Marking
- Protection of Images via Customer Number Identification
- Compliance with existing disaster recovery procedures
3.2 Development Process
The Hunterian applied an implicit traditional life cycle development methodology in its development environment. The developers were assigned to specific aspects of the project. They were asked to contribute to the design of the project and then they were expected to develop the application as agreed upon with the project manager. The project manager then kept track of the progress as the developers proceeded through the agreed upon stages of the project. The project manager also attempted to coordinate any additional outside assistance as needed.
In the real world, the Hunterian, as with many other businesses, has limited funds to contribute to application development. The developers for the Hunterian are generally Glasgow University Computing Science students who have been brought in for a specific project. The incentive for the students is the experience they gain while working with an actual organization on a real problem along with the fact that the project is associated with a course mark. Hence, the high turn over and limited availability of a student’s time places restrictions on the development team. This means that the Hunterian may have multiple students working on specific aspects of a project. The high turnover in students, coupled with a high number of potential students working on a project for very short periods of time, creates a volatile environment that can be very difficult to ensure that accurate documentation is being accomplished. The Hunterian imaging project had at least fifteen different developers that worked on various aspects of the project over the duration of the development life cycle. The volatile environment described above naturally raises security issues from a development and documentation perspective. However, it is a realistic situation that most industries cope with on a daily basis.
3.3 Technology
The technology implemented for this project, as with many organizations, was determined by existing resources, financial constraints and donations. The Hunterian has a limited budget to spend for development and a small technical staff. Since Microsoft donated the SQL Server application and the Visual Studio software for the project, the technical scope was established early in the development process. The use of the software provided the Hunterian with up-to-date code libraries and professional quality development tools.
The point was not to argue the validity or the usefulness of the tools from a security capabilities perspective, but to acknowledge that they existed and provided options to the developers. It is also useful to note that the Hunterian decided to code the application in Visual Basic which limited access to some of the security tools being offered in the 2005 Visual Studio. One suggestion that was not implemented was the use of source control systems. Source control systems provide versioning control during code development. This allows for code roll-backs in cases where bugs are intentionally or unintentionally introduced into the code.
3.4 Application Implementation
These high-level security requirements transformed into the following security design recommendations:
- Implement logins to establish authorization and authentication
- Implement / integrate a secure payment system
- Encryption of the payment transaction if possible
- Confirmation of the transaction prior to end-user download
- Page monitoring for post-back information from payment system
- Make the discount request manual for the purpose of adding a layer of human verification
- Web page protection of top ten coding vulnerabilities
- From a security standpoint, code needs to be modularized as much as possible.
- Install and use a professional source code management system.
- Any data that is going to be passed via a URL will need to be encrypted.
- Any sensitive data that is being stored on the database will need to be encrypted.
The recommendations that were implemented include numbers one, two, three, six and seven. It should be noted that recommendation numbers three, six and seven were limited in their implementations. The elements that were specifically tested for, out of the top ten vulnerabilities in Web applications, included: un-validated input, broken access controls, injections flaws, and improper error handling. As far as the sixth recommendation goes, the only data that is encrypted is the data going to the payment system and the user password. The only stored data that is encrypted in the database is the user password. The marking of images to record customer numbers was deemed out of scope for this project and tabled for later investigation. Due to the limited resources, the developers were trusted to implement the security requirements as requested. Although security solutions were discussed during design and testing, an in-depth code review was not conducted. Throughout the creation of the application, the developers were advised to specifically code against the top vulnerabilities identified by OWASP (The Open Web Application Security Project, 2004). Additional items that were discussed, but not implemented, include locking the user out after a set number of log-in attempts and keeping a log of the user’s activities within the program.
In order to address the Hunterian’s need to implement / integrate a payment system into the application, they accepted and implemented the suggestion to implement the payment solution via PayPal. There were several reasons for using PayPal as the payment service provider. These reasons range from marketability, to code practicality, to security. PayPal is a worldwide organization that is recognized as a legitimate payment service by the global public with over one hundred million account members worldwide. PayPal has been very successful at establishing itself as a technology leader in the area of payment solutions, receiving several awards for technical excellence (PayPal, 2006). Since HOPL is geared to the general public it was wise to use such a provider.
More importantly, it was an even wiser decision from a coding and a security perspective. PayPal provides excellent reference materials along with a development center for developers. The development center is basically a sandbox area constructed so that developers can test their code before going live. The developer documentation also goes into detail on the encryption of Web site payments. This information even provides a reference link to developers for creating their own certificates. The recommendation was for the Hunterian, if they had time, to encrypt the payment. If they did not have the time to figure out the encryption piece of the code, then they should use the PayPal configuration for the exchange of the payment information and the encryption could be added later. The developers took the security issue to heart and correctly implemented an encrypted payment system with PayPal.
Overall, the PayPal services were highly utilized by Hunterian’s developers in the design of the payment aspect of the HOPL system. This includes developing the code necessary to encrypt the transaction information before it is sent to PayPal and configuring HOPL to act accordingly upon the automated response from PayPal. The way HOPL is constructed it actually waits for a real-time response from PayPal before allowing a customer to proceed. This is an excellent feature for HOPL and provides a level of security in the payment transaction that is beneficial for the organization. Another security feature that was built in, from the perspective of accountability, is the notification to the developer when anyone other than PayPal attempts to post to the PayPal response page. The use of the public and private keys helps establish trust between the Hunterian system and the PayPal system. This trust is supported by the fact that the Hunterian system enforces accountability through the system log-in process that has to take place prior to an order being placed. This helps the Hunterian establish trust and accountability within the system.
When it came to testing, the idea of outsourcing penetration testing and load testing was discussed with the Hunterian project manager. The ideas were turned down when compared with the available resources. The testing for the application was handled primarily through the developers and outside testers. Three outside testers (including one of the authors) were asked to examine the site. Two major bugs in the system were discovered along with a couple of minor link errors and text display errors. Both bugs were discovered by over filling text fields. The first bug was found in the advanced search page. One of the text fields for the advanced search allowed the user to input more text than the field could handle. This generally causes the system to overwrite memory space that is being used to hold other information. In this case, the system then became confused on session information. This in turn caused the Web page to produce an error page that provided information which included the technical explanation for the problem, the line on which the error occurred, storage drive location along with indications as to the language in which the system had been written and the platform on which the system was running. This information could be useful for malicious attacks and, therefore, it is recommended that only generic error messages be displayed.
The second bug was discovered using the same basic technique but with a slight twist. The second address line in the user detail page was flooded with text; however, text entered at the end of the input field was not random text. This part of the input was constructed using the Structured Query Language (SQL) and attempted to retrieve data from one of the database tables. The actual query was not successful. However, the page that was returned to the user of the system provided information that could be used against the system in future attacks. This information included the error statement, information that could be used to help determine the database platform and to what extent the system executed the SQL code.
The issues discussed above provide a couple of examples of problems that Web pages can experience. The Open Web Applications Security Project (OWASP) provides a very useful list of the top ten vulnerabilities in Web Applications (The Open Web Application Security Project, 2004), which should be considered when developing and testing Web applications.
4. Integrating the System to an Existing Financial Infrastructure
The University of Glasgow, as is the case with most large organizations, has a long-established set of financial practices, with numerous forms to be completed to comply with various (and often mystifying) tax regulations and sales and invoicing practices. This proved to be one of the most difficult areas of developing the system in order to integrate of financial practices which could not be ignored and which did not, in many cases, lend themselves to transfer to an online process with minimal human intervention. It required many long hours of discussion and compromise to reach a point of convergence between the two systems of operation. Finally, however, we did manage to bring our colleagues from the University Finance Office on board and all system operations from point of sale to funds being transferred from Paypal and lodged into the University’s bank, thence to the designated Photo Library account, have been completed successfully and without difficulty.
5. The Computing Science Perspective
The Department of Computing Science (DCS) in Glasgow University has been collaborating with the Hunterian Museum and Art Gallery (the Hunterian) for more than ten years. Projects in the Hunterian provide students with the opportunity to undertake ‘real world’ projects rather than solve toy problems created by DCS staff. The students are able to carry out a full system development cycle from requirements capture, through design and implementation, to testing and evaluation with end-users. They also gain valuable experience dealing directly with customers such as museum curators, other members of staff in the Hunterian, schoolteachers and pupils. Typically these projects have explored new technology of interest to the Hunterian or developed products for use within the Hunterian. Individual students, undergraduate and postgraduate, and teams of students have undertaken projects in the Hunterian. The HOPL project was large enough to provide a challenging project for a team of five students in the third year of their undergraduate degree.
The HOPL project was interesting because it gave students an opportunity to use a commercial database product, Microsoft SQL Server, to design and build a large database combining text and images. They also had to design and build a robust Web-based user interface to provide access to the database content. The second interesting challenge was that there was an existing computer-based system for storing the images which, unfortunately, could not be enhanced to provide a secure Web-based application. So, the team had to consider how to transfer the data from this existing system to their new system in a systematic way with minimal effort. Of course, the positive aspect of the existing system was that all the images had already been captured digitally.
Finally, the other unusual aspect of the HOPL system was that it was intended to be a secure commercial system for paying customers. Our previous projects had mainly been educational, for school children or the general public, or for use within the Museum. As noted in the previous section, the problems of providing a secure payment system offered an opportunity for one of our PhD students (Brad) to try out some ideas from his research on Web-based security.
The team produced a good prototype system with a sound database design and well structured user interface providing Web-based searching and browsing facilities for the retrieval of images. The students gained valuable experience applying theory from courses such as database design and human-computer interaction, and also learnt new implementation skills, such as programming in Visual Basic and creating Active Server Pages (ASP.NET). They had to design and implement a user authentication subsystem for different classes of users and provide different levels of access for these users. The students also learned about handling images, both thumbnail images and high-resolution images with watermarks, and linking these with the text fields in the database. They gained valuable transferable skills through writing a substantial report, documenting the system for their customers and presenting their work to both customers and their peers. Overall, the project was judged to be very successful from an academic point of view. However, the system delivered at the end of the team project was not robust enough to be made available to the public and it lacked a secure payment mechanism.
Two members of the team were employed during the summer vacation to develop a more robust system and carry out thorough testing. With guidance from Brad, they also integrated a secure payment system with the image retrieval system. These students were employed on Hunterian scholarships. Each year a number of students from various academic disciplines are employed by the Hunterian on ten-week scholarships to carry out projects in the Museum. Many DCS students have benefited from this scheme and often their projects have involved further development of earlier student projects to take them from a prototype (proof of concept) system to a more robust and usable product.
The HOPL system is now fully operational at http://www.hopl.gla.ac.uk
Figure 4: Screenshot of the HOPL home page.
6. References
Glisson, W. B. and Welland, R. (2006) Web Engineering Security (WES) Application Survey Technical Report University of Glasgow, Glasgow, 31 http://www.dcs.gla.ac.uk/publications/paperdetails.cfm?id=8287
Glisson, W. B. and Welland, R. (2007a) Web Engineering Security (WES) Technical Report University of Glasgow, pp. 51 http://www.dcs.gla.ac.uk/publications/paperdetails.cfm?id=8509
Glisson, W. B. and Welland, R. (2007b) Web Survey Technical Report University of Glasgow, 27 http://www.dcs.gla.ac.uk/publications/paperdetails.cfm?id=8508
PayPal (2006), Vol. 2006 PayPal.com, California,. http://www.paypal.com/uk/cgi-bin/webscr?cmd=p/gen/about-outside
The Open Web Application Security Project (2004) The Open Web Application Security Project, http://www.owasp.org/index.jsp
Cite as:
Devine, J., Picture This: Developing A Museum On-Line Photo Library, in International Cultural Heritage Informatics Meeting (ICHIM07): Proceedings, J. Trant and D. Bearman (eds). Toronto: Archives & Museum Informatics. 2007. Published October 24, 2007 at http://www.archimuse.com/ichim07/papers/devine/devine.html
Search A&MI