Security and privacy Learnings from prototype development and feedback

Page 161 of 201

10.7.6 Leveraged functionality

There are a number of functions that may be added to a hand-held device to increase leverage the potential value of the device and also ensure that it is carried everywhere and used. As mobile phones started to provide more functions than just phone calls camera, alarm clock, timer, calendar, note recorder, etc, they became more important to carry everywhere. The current generation of multi-function devices gives a user more reasons to remember to carry such a device. Commonly available or potential features of such a device of value to an AAV or stockman would include:  photographs,  ear tag scanning and recording of RFID records,  voice memo recording, and  reference or resource material. The ability to have access to one of more of the items on this list was widely appealing to different users, and their inclusion will improve the chances of the device being carried and used. One of the issues not satisfactorily resolved during this project was the linking of a hand held device to a small portable ear tag reader for NLIS tags. The small printing of numbers on these tags and the potential delays and errors in data capture would limit the number of animal tags captured, however most researchers are in agreement that accurate reporting of animal outcomes is vital. Although data capture was possible using a Bluetooth enabled NLIS RFID scanner, at the time this report was written, it was still somewhat cumbersome. An NLIS ear tag reader would need to be carried another device to charge, carry and use and the ear tag reader has to be synchronised to the hand-held device to transfer an ear tag record to the shipboard application at the right time and linked to the right record. It is expected that either RFID tag readers will be developed, as smaller and more easy to use devices or that software capacity will be developed so a hand-held device can be used to scan and read RFID tags.

10.7.7 Security and privacy

Industry stakeholders have repeatedly raised concerns of commercial sensitivity and privacy and have tended to react negatively to any discussion of systems that might involve a centralised database of any form. Such concerns are valid, however it is our opinion that security can be managed at whatever level industry wishes to achieve. There are many perspectives to any discussion about collection and management of sensitive data. Almost everyone already uses internet systems to house and manage sensitive data with various levels of security to control access and ensure privacy. Examples include: internet banking, company records, state and national animal health records and many others. Any form of internet access involves risk management, although it can be managed. The first demonstrated versions of the EpiCollect system were built with a single, central, shared database. Within this, records were stored by vessel and voyage and consignment and exporter and a variety of other ID fields. It is possible to implement specific security Page 162 of 201 controls in a shared centralised database, such that each user has their own access user name and password and can be restricted to access only those records that are relevant to their username. Different users may have different levels of authority ability to read but not change any record, ability to change data or enter new data, ability to authorise others and so on. The levels of security implemented in shared systems can be made as complex and powerful as are required. We have also developed relational databases where the data tables back end of the database are separated from the user interface and functionality front end of the database. This allows a common or shared interface front end that can be maintained and updated as required, that could be web-based but that does not store any sensitive data. Individual users exporters for example could then install their own individual copy of the data tables the back end and store their own data and no- one else’s data in these tables. Users could then manage their own levels of internet access to their own data tables. When a common or shared front end is linked to a specific back end then the full functionality of the application is enabled but on ly for the specific user’s data. Finally, it is possible to develop a software application and associated server a full working system and have each separate user install their own separate copy. This approach loses much of the benefit of central data storage and requires potentially more investment in product maintenance and upgrades since they may need to be updated across multiple individual users and each version may need more development to retain backwards compatibility.

10.7.8 Flexibility vs specificity