This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
It is widely accepted that intelligent connected mobile devices have changed working and communication methodologies in a way not seen since the PC revolution. Recent research by investment bank JP Morgan states that smartphone sales have increased by 120% in the two years up to 2012  and with the trend set to continue past 2016 , it is clear that owning a "take everywhere" device is ever becoming less of a tendency and more of a requirement.
As the smartphone trend continues, new market opportunities begin to open, particularly relating to the vast and varied volumes of mobile data that can be collected from such platforms. One example of this is mobile device tracking, an area which inherently has endless real world business and consumer applications. Inevitably as location-aware connected devices become more prevalent, the ability to monitor a device's location becomes more useful: be this through intelligently delivering location specific alerts, gathering statistics, or evaluating employee performance, to name but a few examples.
Another such scenario in which location tracking has proven useful is parents wishing to track children (or indeed any carer wishing to track a subject). Research for the UK communications regulator Ofcom in 2011 stated that "almost half of [UK] teenagers (47 per cent) now own a smartphone" . Considering the overall growth in penetration of smartphones since this period, it is likely now well over 50 per cent. Combine this then, with the results of 2012 a survey by children's charity "Children 1st", who state that 51% of parents would enable the GPS tracker on their child's phone in order to know where they are , and it becomes clear that there is significant interest in this market.
Tracking a mobile device carried by an individual presents a number of problems beyond the obvious ethical hurdles. While technologies to monitor a location in real time exist for smartphone platforms (such as Greenalp's Real Time GPS Tracker ), such systems require a parent to regularly check the application in order to gain significant useful information. Taking the case of a parent wishing to track a child - for example knowing when the child had reached school - constantly monitoring the application for an indeterminate period of time is inefficient and inconvenient. In addition, many such device trackers do not offer any form of security, making the system fairly useless for parents wishing to track children, and remain confident that such personal data stays safe.
1.3 Functional Objectives
The aim of this project is to deliver a multi-tier secure mobile tracking application for parents featuring the ability to define regional boundaries, which when crossed, will generate a suitable alert for the parent. The application should allow parents to track one or more children based on the location of their smartphones, while monitoring the information and defining boundaries on their own device. Real time tracking of these devices should be provided, along with the ability to recall historical location data from a central resource and display it on a user adjustable map.
1.4 Academic Objectives
The academic objectives of this project are to demonstrate my ability to manage and deliver a major piece of work in my subject area. The project will allow me to fully demonstrate and apply the skills and techniques I have learnt throughout the course of my degree, and combine these with some of the knowledge and experience gained while on my work placement. Through managing a project of this size I will be able to develop and enhance my abilities in project management, written and verbal communication, and the presentation and demonstration of a completed system.
By developing a multi-layered mobile focussed system, I will be able to illustrate my creativity in problem solving in an area which has not been specifically taught on my degree program. In addition to mobile devices, the project will be targeting a range of networking and server side technologies, demonstrating and reinforcing my abilities to understand, design and produce complex technical systems for a range of technical areas.
Talk a bit about other project objectives: ie project management etc (Bethans section)
1.5 Personal Objectives
For many students, this will be the largest project over which complete responsibility has been held. As such, the opportunity is relished to gain experience in managing a project that involves taking a problem, and delivering/presenting a solution to a potential customer. Such a project will provide a real test of the organisation and time management skills that have been developed not only through the degree course, but also during my placement year.
The problem space chosen, mobile development, is one which suits my interests, but not so much my experience - so will no doubt provide an additional challenge. Whilst I have never developed an application for a mobile device, it is a space which I feel the market is moving swiftly into - and in which a keen interest is taken. By combining a simple mobile application with a range of server side and networking technologies, I hope to mitigate the risk of lack of experience in the mobile sector, with experience and confidence in the others.
2.1 Review of Existing Commercial Solutions
A number of commercial solutions currently exist which claim to deliver a range of functionality akin to that intended to be developed in this project, including:
Real time tracking of remote devices.
Storage of historical location data.
Secure/encrypted streaming of personal data between devices and/or servers.
Alerting based on location in a geofence or similar manner.
Focus on family use and/or child tracking.
A summary of similar applications feature sets can be found in table 1.
Table 1. A feature comparison of popular commercial tracking solutions.
Real time Tracking
Historical location data
Location on Demand
Data encrypted and/or secure
Geofencing: Distance from fixed point
Geofencing: inside or outside a polygon
Google Latitude 
Apple Find My Friends 
Life 360 
Phone Sheriff 
Core 9 
iTeen 365 
Informer Lite 
Trackstick Mini 
From reviewing existing solutions it becomes clear that there are a number of common strengths amongst competing applications, particularly those optimised for smartphone platforms:
Strong, intuitive and functional user interface, for example Apple's Find My Friends application (iOS devices only) features a UI consistent with the overall platform design style (Figure 1).
Figure 1. Apple's Find My Friends application for iOS devices .
Simple setup procedure; no technical knowledge required.
A number of solutions offer web based management interfaces as well as platform specific applications.
Encryption/security of location data in transit.
Ability to track/follow multiple "child" devices, in real time and often with the ability to pull back historical information.
Many solutions support a range of platforms such as iOS, Android, Blackberry, Windows Phone, as well as the PC. For example, Google Latitude is shown in Figure 2 running on Android and Blackberry devices, as well as in a browser on an iOS device.
Figure 2. Google Latitude running on three different smartphone platforms .
Issues - The Project Problem
Analysing this table, it becomes obvious that there is no single child tracking solution that offers everything a parent may require, with one notable exception being found in every commercial solution. Although delivering geofence style alerts based on a distance from a fixed point (i.e. is the device within a given radius) may be helpful for many scenarios, it is certainly not an ideal solution. Take for example; if a parent wished to know whether a child was within the boundaries of a park, or was walking down an adjacent busy road, a circular geo-fence would be completely insufficient. This leads to a simple conclusion: when a higher than usual degree of accuracy is required, a polygonal fence of n sides needs to be established, a feature which is missing in every major commercial tracking solution on the market today.
A handful of recent studies have also been conducted into geofencing, and its applications for tracking not just children, but also fleet vehicles. A 2009 paper presents some sample applications for geofencing in the scope of transport and logistics, concluding that "geofencing is a highly flexible technique", with their being "no need for on-site investments: barriers, badge readers, cameras" . Based on the fact that geofences benefit from existing and ever improving high precision, high availability location services, notably GPS, EGNOS, and the upcoming ESA GALILEO  system, this has potential for a highly effective low cost solution to existing issues. Additional studies have also identified benefits for geofencing in relation to location context aware advertising, as well as location specific information and alerting .
Perhaps more directly related to this project however, is the issue of ethics. Inevitably, tracking a person in real time presents a number of social and ethical issues relating to directly infringing an individual's privacy - even if a parent is tracking a minor. There is also of course the possibility of the information being misused either by the parent or the company holding the data, or the data itself being factually incorrect as a result of selective availability, or another failure in the public GPS system . A recent study into location tracking for patients suffering from Alzheimer's has suggested however that a number of these issues can be overcome through employing geofence based tracking. Through removing the need for real-time tracking and instead issuing relevant alerts, it is possible to maintain a patient's independence, while ensuring they are secure. .
Relevance to the Computing Community
The proposal for this project is to develop an application, which enables users to freely define a geofenced area of any polygonal shape. From extensive research, there appears to be no other commercial application or academic project, which offers a solution to this problem, making this an issue of particular interest. The main difficulty is the curvature of the Earth. Solving this issue requires translating a conventional (or Euclidean) point in polygon algorithm (for example a Ray Cast) into elliptic space, such that is suitable for the geographic coordinate system (i.e. latitudes and longitudes). This project will investigate and evaluate a number of ways in which this can be achieved, before settling upon and implementing a solution in the final application.
Derived Informal Specification
Based on the analysis conducted of existing commercial products and academic studies, it is possible to derive an informal functional scope for the project. From this, the following features are considered important:
Real time tracking of multiple child devices, with information displayed either on another device or in a browser.
Historical location information stored somewhere for later retrieval.
Location information encrypted when sent "over the air" between application components.
Parents may define and visualise geofences on a distance from a fixed point basis, and receive a corresponding alert when a tracked device crosses and boundary.
Parents may define and visualise geofences of any size or shape (polygonal), and receive a corresponding alert when a tracked device crosses and boundary.
Location information may be requested on demand from the tracked device; i.e. the parent can force the device to update its location.
The user interfaces must be intuitive and simple to use, while still enabling a user to quickly navigate through the applications powerful feature set.
The application should be family friendly in nature, with the tracking software having a limited impact on the devices power consumption
The architecture must be flexible such that any platform of GPS device could be tracked, even if multiple platform applications do not exist from day one.
It is intended that this project will consume approximately 400 - 600 hours of time including the analysis, design, implementation, and testing phases, loosely following a traditional waterfall style development model. Inevitably when developing a cutting edge system such as this, some technologies initially chosen for particular tasks may prove to be inadequate, so the development methodology will have to be tweaked somewhat so as to be agile to this risk.
Use Case Diagram
A Use Case Diagram is drawn to show intended user interaction with the system through its full range of available functionality. Such an illustration is shown in figure 3.
C:\Users\Dad\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\0450ZTJU\Use Case Diagram.jpg
Figure 3. Use Case Diagram for the TrackiT Application.
In order to ensure the successful delivery of a project, stakeholders and their unique requirements must be identified and illustrated, as shown in table 2.
Table 2. Stakeholders of the project.
Interest in Project
Project supervisor: Dr James Anderson
Overall supervision for the successful completion of the project
Sufficient technical complexity to meet academic requirements
Ensure suitable project management methodology followed
Ensure project is on time, on budget, and within scope
Quality of end product is sufficient
Project moderator: Dr James Ferryman
Moderation of project marks
Logical and well-structured material, supporting ease of assessment.
Customer: general public
Buys the product
Functional and non-functional requirements as specified in this section
Developer: James Cross
Responsible for the delivery of the entire project
Sufficient technical complexity to meet academic requirements
Ensure suitable project management methodology followed
Ensure project is on time, on budget, and within scope
Quality of end product is sufficient
Project meets criteria to achieve a high mark
Security has been identified as one of the key non-functional requirements of the proposed application, resulting from the large amount of highly sensitive personal data that will flow through the system and be stored in the database. Because of this, it is necessary to conduct a vulnerability study so as to identify potential security issues with the system, and provide a specification that hopefully mitigates any risks or issues identified. Details of the results of this study are shown in table 3.
Table 3. Vulnerability study of the proposed system.
Interception of streamed location data between device and server by an attacker.
Encrypt all communication using SSL.
Theft of a device.
Never store personal information on the device, or only store information in encrypted form. Source code never distributed with the application. Ability to remotely wipe the device to stop location data being sent to it.
Theft of passwords from the applications database.
Securely encrypt passwords in the database.
Denial of service attack against the application server.
Ensure sufficient excess bandwidth on the server, with a properly configured firewall.
Erroneous commands issued in an attempt to crash the server.
Isolate each request in a sandbox such that it can never crash the whole application. Perform correct validation on inputs; authenticate each request.
Attacker pretends to be a parent and attempts to issue commands.
Authenticate each request using secure tokens. Encrypt the transmission of the token.
Interception of communications between the application server and the database server.
Host the database and the application on the same server behind a correctly configured firewall.
Application traffic conflicts with another application's traffic resulting in information disclosure.
Isolate the application/database servers on a dedicated machine using a non-registered custom TCP port for communication.
The following represents a MoSCoW analysis of the application's functional requirements based on the project specification derived from analysis of existing commercial applications and academic research.
Parent can install an application on a device, and track where the device has travelled through a separate user interface (maybe another mobile app, web page, or desktop application)
Parent can define a distance from a location that a user may travel, and receive an alert if this distance is exceeded
Support at least one of iPhone, Android, Blackberry or Windows Phone
Parent can define areas on a map (by drawing/constructing a geo-fence) and receive alerts when a device arrives in or leaves this area
Support fully secured transmission of location data between a client and the location server
Parent can receive mobile alerts either through an application push
Parent can view the child's device location on their own device
Location is viewable in best case real time
Handle switching between different Internet connections: 3G, GPRS, Wi-Fi etc.
Support multiple devices and parents (using the same device type)
Allow parents to view device statistics, for example battery life
Support more than one mobile smart phone platform (for the device tracking) e.g. Android and iPhone
Support location on demand - i.e. the parent can actively request the device's current location
Have a fully functioning admin application for a parent's mobile device
Automatically update all parent devices for a given user account when a change to a geofence occurs
Support the ability to remotely wipe or de-authenticate any device.
Support administration through a web page
Parent can define a distance from a pre-defined route of travel, outside which they would receive an alert
Parent can define a distance from their own device, outside of which they would receive an alert
If communication to the device is lost, the parent should receive an alert containing the last known location
Support database level encryption.
Have a panic button on the device (to alert the parent immediately)
Allow the parent to remotely enable the camera/microphone
Support alerting via SMS
Support more than one device platform at launch
Allow parents to access any other information about a device, for example text messages, or web browsing history.
Table 4 lists the non-functional requirements for the TrackiT project. Non-functional requirements are those, which cannot formally be defined in terms of specific application functionality, but are equally important in specifying the overall quality of any product.
Table 4. Non-functional requirements for the project.
Personal data security
Personal information must remain secure, both in transit and whenever stored on the device. This includes location data as well as passwords. Data in the database should not be accessible by unauthorised users. Users should only be able to access their own data.
The tracking system should not significantly impact a host device's battery life.
Alerts should be delivered promptly once a device crosses a boundary or other set condition.
Data stored should be accurate and its integrity maintained.
The core framework should scale to many devices.
The application will inevitably rely on some form of server and database architecture. This should be highly available ensuring accessibility from anywhere on the internet at all times.
The application should be reliable, in that it performs consistently and as expected at all times.
The system should always respond in a timely manner to user requests, both in regards to the user interface, and the time taken to process network requests. This can also tie in to the server requiring a low latency connection to the internet.
Malformed requests to the system should never be able to crash the server.
Invalid data should not be erroneously inserted into the database, or cause the system to crash.
The software should be written such that it is difficult to exploit or use for malicious purposes. This may include input validation or other techniques to ensure consistency.
The architecture should be designed so additional platforms can be connected later: i.e. it would work with Android, iOS etc. as required.
The application should remain stable and run as expected over protracted periods of time. This means frequent restarts are not required, and the application does not leak resources such as memory.
The user interface should be designed such that it is intuitive and easy for novice users, while still allowing rapid access to the entire feature set. This should include the ability to visualise geofences on a map.
Gantt - put reference to the chart in the PID
System Components and Technology Choices
A range of inter-communicating components are required to meet the functional specification. These components along with specific technology choices and motivations are detailed in this section.
A smartphone application will be required which will provide not only device information, but also the fundamental frequent and accurate location information upon which the rest of the system will rely. Before this can be done however, a primary smartphone platform must be chosen for development. Table 5 shows an evaluation of various competing smartphone platforms along with features and statistics relevant to this choice.
Table 5. Smartphone platform comparison.
Market Penetration (%) 
Native SDK Language
App Privilege Restrictions
Background GPS Possible?
Personal Development Experience (based on native language)
RIM Blackberry OS
Microsoft Windows Phone
Based on the research shown in table 5, it becomes fairly obviously which smartphone platform should be the primary focus for development in this project. Google Android has by far the highest penetration of any smartphone platform globally, eclipsing its nearest rival more than 3:1 in terms of market share at the end of 2012 . Perhaps this is driven largely by the fairly limited restrictions on the Android platform, making it relatively easy for an application developer to have the control they require over the host device. This particular aspect of the platform is crucial for the project: gathering frequent location information in the background and transmitting it to a server is not straight forward, nor can service continuity be guaranteed on platforms such as iOS, or Windows Phone. Combining this with my knowledge of Java, Android becomes the obvious platform of choice.
As Android has been chosen as the primary development target platform for this project, it follows that the application designed for parents use (to view location information and receive alerts) should also be on the same platform. This saves time by sharing common components, and removes to learn about than one platform. Cross application compatibility can also be ensured through the common properties of shared primitive data types as well as custom objects. Android is also the most popular smartphone platform maximising the target market for users.
While the child application will simply be designed to capture a devices location in the background, and transmit it to the system's application server, the usage of the parent application will be somewhat more complex. This application will be the main method of interacting between a user and the system, and as such requires a carefully designed user interface. For example, parents will need to be able to easily draw, edit, and remove geofences, while still viewing multiple children's positions at the same time. With this in mind it seems logical that the extra screen space afforded by a tablet would come in useful when designing such a user interface. While still popular, Android tablets do not have the same level of market penetration as Android smartphones, making a tablet exclusive application more difficult to justify. As a result, the parental application should be written with a dynamic user interface compatible with both tablets and smartphones. Such a UI offers the best of both worlds: usability when a tablet is available, as well as portability and compatibility when not.
In order to coordinate communication between various connected devices, as well as manage the storage of location information, an application server will be required. Such a component could be written in any number of languages; however Java has been selected for the following reasons:
Object and primitive compatibility, extensibility and re-usability with Android devices
Significant developer experience in this language
Simple multi-threading support essential to handle multiple simultaneous connected devices
Support for a range of web frameworks including:
Simple Object Access Protocol (SOAP) via JAX-WS (Java API for XML Web Services)
Representational State Transfer (REST) via JAX-RS (Java API for RESTful Web Service)
Transmission of serialised objects over TCP/UDP sockets
Ability to develop using available Windows resources, and deploy to Linux web servers with guaranteed behaviour (thanks to the Java VM), and improved performance/reliability
Easy to rapidly develop applications based on existing frameworks
Support for a wide range of databases including MySQL
The system is required to store historical location information for later retrieval by parents, as well as key device information such as remaining battery, charging state, and data connection type. Geofences will also need to be stored somewhere, along with user credentials and specific configuration. From this it is clear that what is required is a fast, reliable and maintainable persistent data store; for example a relational database. The obvious choice for this is the free relational database solution: MySQL. MySQL is a the world's most popular open source database , providing a database server with multi-user access to multiple database tables, including support for a wide range of data sets, as well as SSL. Also importantly for this project is its ability to scale and automatically replicate its data across multiple redundant or live database servers, providing a perfect solution to the projects scalability requirement. Simple compatibility with Java is provided through a native MySQL connector for Java.
Web Service Model
In order to provide communication between various devices it is required to specify a web service model which will define the sort of API that can be provided to devices. Based on the requirements specification, such a model should be able to provide:
Efficient low overhead communication between device and server, particularly when little bandwidth is available and latency is high (for example on a cellular connection)
Easy integration with mobile devices
Support for security on top of the basic model
Extensibility for function calls from devices as well a browser connectivity
Request isolation - such that no single request can crash the application server
A number of common methodologies exist for achieving this. Aside from writing a custom socket protocol using a serialised object byte stream (which would be very development time intensive, and likely produce a lower quality result), there are two major approaches that can be taken.
REST vs. SOAP
REST - Representational State Transfer. The fundamentals upon which the internet is built: stateless CRUD (create, read, update, delete) operations on public uniquely addressable resources (everything is a resource) over HTTP (or HTTPS). REST is more of an architectural style than anything else, specifying a uniform and stateless, yet layered and cacheable client server interface with support for code on demand. Resources can take any form, are easily manipulated using GET and POST (amongst others) HTTP methods, and are accessed via unique URL's . In order for an API to be truly "RESTful", such URL's should be "clean", i.e. they contain only the path of a resource, and no query strings .
SOAP - Simple Object Access Protocol. "An XML based protocol allowing applications to exchange information over HTTP" . SOAP focusses on accessing and executing named operations through various interfaces each of which implement some business logic. Support is also included for a number of enterprise specific features including atomic transactions, reliable message retry, and security through intermediaries , none of which are critical to this project.
Java RESTful API
Based on these evaluations it becomes clear that building a RESTful web API is the obvious path to take for this project: none of the additional heavyweight SOAP enterprise features are required, and being tied into an XML based API at this stage is not advantageous. Building an API based on REST principles makes it easy for clients to interface with the application thanks to its HTTP URL driven nature, with the support for building API's as well as web pages built in. A REST style API also fulfils a number of additional project requirements including scalability (as requests are stateless), efficiency (everything is done using simple HTTP requests), and security (SSL is supported).
A number of RESTful frameworks for Java exist each based on the Java API for RESTful web services (JAX-RS), including the reference implementation Jersey, and the more popular Restlet . Restlet is written in such a way that protocol and application concerns are kept distinct , while including built in support for a number of components including SSL, POP3 and SMTP protocols, as well as data formats including both XML and JSON. Perhaps the key benefit of Restlet though is its fundamentally modular structure, making it fully extensible, and ensuring it is possible to unify the development of web sites and web services into one design.
JSON vs. XML
A 2010 update to the Android OS introduced a brand new high performance native JSON parser, making JSON a realistic alternative to XML for web services on the Android platform for the first time. Like XML, JSON is a text based standard for data interchange, however a recent experiment has shown that for relatively small data sets, the equivalent JSON string takes up 30% less space and is 30% quicker to parse than XML . Research into the Android platform for IBM confirmed this research in a 2010 study, showing important battery life and network transmission performance benefits as a result of using JSON . Considering the impetus on any smartphone application to be as battery friendly as possible, combined with the baked in support for JSON in both the chosen Restlet framework and the Android platform, and it is clear that JSON is the data format of choice for the TrackiT API.
Restlet fully supports the Secure Socket Layer (SSL) protocol, which has become the de-facto standard for securing all private communication over public networks. SSL ensures messages sent between two communicating parties remains private, unmodified, and not repeated by any third party through methodologies such as:
Message Authentication Code
Encryption of the payload
Due to its broad usage, SSL is very easy to implement on a range of platforms, highly secure, and has a low encryption overhead, making it perfect for securing communication between mobile devices.
High-level System Architecture
Based on the component and technology choices made, a high level system architecture diagram has been draw illustrating how each component communicates with its peers. This diagram is shown in figure 4.
Figure 4. High-level system architecture.
Software Architecture Design
Communicating components will need to be able to operate on resources provided by the RESTful API through calling a number of functions, all of which will be sent over an SSL connection. For each function a database operation is usually involved in order to verify the calling device, as well as perform the relevant operation on the persistent data store, for example deleting a geofence. A summary of these functions is shown in table 6.
Table 6. Custom REST API Functions provided by the TrackiT Server.
Child, Parent, Web UI
Success flag, auth token
Attempt to login. If the source device does not exist, create it along with an authentication token. Send this token to the device (cookie if it is a browser).
Update GCM Token
Device ID, Authentication Token, GCM token
Used to update the Google Cloud Messaging (GCM) token stored in the database, which I used to send push notifications to the device.
Latitude, Longitude, Battery remaining, Location source, Accuracy, Altitude, Bearing, Network, Charge Status, Velocity, Data Connection Type, Device ID, Authentication Token
Send a new location update to the server
Save Radial Geofence
Centre Point, Radius, Device ID, Authentication Token
Create a new or update an existing radial geofence
Load Radial Geofences
Device ID, Authentication token
Request for radial geofences to be pushed to the device
Delete Radial Geofence
Device ID, Geofence ID, Authentication Token
Attempt to delete a radial geofence
Device ID, Authentication Token
Requests for the latest location data to be pushed to the device
Save Polygon Geofence
Device ID, Authentication Token, Geofence ID, Geofence Markers
Create new or update existing polygonal geofence
Load Polygon Geofence
Device ID, Authentication Token
Polygon geofences for this device
Load geofences for this device
Delete Polygon Geofence
Device ID, Authentication Token, Geofence ID
Attempt to delete a geofence
Load images for the Web UI
Load CSS for the Web UI
Load HTML for the Web UI
Load Device Details
Load DTML for the Web UI
Load Map Simulator
Load the Google Map location simulator page
Data Storage Design and Data Dictionary
In order to efficiently store data in the proposed MySQL database, a relational data design is required. Full details of this design are found in appendix Error: Reference source not found.
Source and Version Control
With any large project, source code version control is important to ensure erroneous code changes can be reverted if they have an unintended impact on a production system. Correctly implementing source control also makes it easy to keep track of changes over time, while also enabling work to be conducted on multiple machines. A number of approaches exist to version control, however three of the most popular are:
GIT, a distributed version control system. This means that every GIT working directory is a fully fledged repository with complete revision tracking capabilities. The benefits of this approach are that a network connection is not required to make commits.
CVS (Content Versioning System), the basis for many other systems including SVN.
Subversion (SVN), a client server version control system based on CVS but with some useful additional features such as atomic transactions, and improved performance .
The initial choice of version control for this project was GIT - due to its distributed nature, network connections are not required to make repository commits. Unfortunately however technical difficulties were experienced at the early development stages resulting in a change of approach. Instead, a free subversion repository was configured with the online provider Assembla , who provide space for unlimited private repository's up to 1Gb in size.
Correctly configured version control also makes it easy to deploy project releases to online webservers for production and in the wild testing. Whereas conventionally, the project would have to be packaged as a JAR and transferred to the host, a publically accessible SVN solution makes it very easy to pull down directly onto the server. The code can then be compiled and run directly, making the process of deploying small changes and bug fixes very fast.
Development and Implementation
This section contains details of the development cycle undertaken for the implementation of this project as specified in the section 3, in order to meet the requirements specification in section 2.
The TrackiT server sits at the very core of the TrackiT system, being responsible for hosting the web services API, it will handle all incoming requests from client devices and web browsers. As illustrated in the high level system architecture diagram (figure 4), this component will be responsible for all data processing, validation and alerting, and most importantly interfacing with and managing the database connectivity.
Web Hosting and Configuration
In order to host such a service, it must to be publically accessible from anywhere over the internet. For the purposes of development and testing, this application will be hosted on a personal server connected to a home network (full specification in appendix Error: Reference source not found) and as such must be configured appropriately. The server has been chosen due to its ample processing, memory, and storage specification ensuring there are unlikely to be any application bottles necks as a result of large data volumes. The most important thing to note is that this server is sitting behind a firewalled NAT device with an externally facing dynamic IP address. This is overcome in the following ways:
Open a port on the external firewall that is not currently in used. For the purposes of this project port 2610 (TCP) has been chosen.
Forward port 2610 external requests to the internal server on the same port (Appendix Error: Reference source not found, figure 1).
Register for a dynamic DNS service. For the purposes of this project, DynDNS has been chosen , and is configured with a lightweight process running on the host. Each time the public IP of the edge router changes, the host updates the DynDNS DNS servers such that the selected domain always points to the correct public IP. For this project, jamescross91.dyndns.tv is the chosen domain name (jamescross91.dyndns.tv:2610 with the port qualifier).
In order to ensure maximum security of the application, the development server is also fully updated with the last software and anti-virus patches, along with a resilient software firewall configuration.
The architecture for the TrackiT server has been designed such that it is as maintainable, reusable, and scalable as possible with straightforward extensibility another key goal of the design. Throughout the implementation, the four main characteristics of the object-orientated paradigm have been followed:
Abstraction - for example the abstraction of database specific logic away into an object.
Encapsulation - combining data and methods in an object, hiding member variables and only allowing publically exposed methods to operate on them. For example creating classes that map directly onto database tables, with private members for field names and public methods to access and manipulate them
Inheritance - Modelling and utilising the similarities between classes, for example implementing a generic alerts manager and extending it specifically for each platform that the alert is to be issued too.
Polymorphism - The use of functions of the same name but with multiple forms distinguished by different places in the class hierarchy. For example calling the alert function on different derivations of the alerts manager class will call a different function on the child object depending on the platform it is alerting.
Class diagrams to this effect can be found in the appendices.
A configuration driven application can be defined as one that is "not restricted to the model of the code, such as classes, fields, and relationships" , making it easy to adapt an application to suit different business cases through the adaption of business rules. Where possible this methodology has been followed through the development of the application, making it trivial to adjust and deploy changes to the application without having to make changes to code.
Implementing a configuration driven architecture in Java is fairly trivial. Configuration key value pairs are stored in a properties file, and a static class (ReadProperties.java) is implemented to parse the text. A specific class can then read an element from the properties file by making a static function call: "ReadProperties.getProperty(propertyName);". A copy of the properties file for this application can be found in appendix Error: Reference source not found.
Behaviour Monitoring: Logging
Accurate and informative logging is important for any production worthy system of reasonable complexity for a number of reasons including debugging, access history, and the ability to verify historical correctness. In order to achieve this, the project employs an open source logging framework: Apache log4j . Log4j makes it easy for application developers to add configuration driven logging to production applications without incurring a heavy performance cost . Log4j logging can also be enabled at runtime without modifying the applications binary (meaning it doesn't need to be recompiled). Being configuration driven in nature, it is easy to produce a consistent log, with error messages shown in red, along with a time, as well as the class and line at which the error was experienced. A copy of the log4j configuration file is shown in appendix Error: Reference source not found.
Diagram and remove information to appendix
Given the frequency with which multiple connected devices will be updating their location information (the application will be write heavy), employing an efficient database connector is very important. As was mentioned in the design section, Java features a native connector for the selected MySQL database platform (MySQL Connector/J , making rudimentary connectivity trivial. The problem with this method however, is that every time a device sends a request to the API (requiring a database operation, which is most API functions), a new connection must be established between the application server, and the database server. Often such a connection will only be required for a few milliseconds while the application processes relevant data, before the connection is closed, and the API thread is shut down. Despite the database server and the application server being hosted on the same physical machine, establishing a database connection is time expensive - involving "additional JDBC driver overhead" .
A number of techniques to minimise access times, improve database utilisation, and to provided security and resilience have been implemented, and are described in appendix Error: Reference source not found. These are:
Database connection pooling
SQL statement/query caching
SQL injection defensibility
Automated cross-host database replication
Business logic abstraction
FIGURE 5 PLACEHOLDER
Given the vast amount of personal information being processed and stored by the application, and in line with the requirements specification and design, security is one of the project's primary concerns. In this context, security falls into two main categories: protecting information, and preventing any form of unauthorised access to the application.
Recent statistics show that as many as 73% of users use the same password for their bank account as they do for other applications and websites ; increasing the responsibility every web service has for protecting its user's credentials.
Many solutions to this problem involve hashing a user's password using a one way function (known as a restricted function, the security exists in the algorithm). The password can then be validated by hashing an input, and comparing it to the hash stored in the database. Unfortunately such algorithms (for example MD5, or SHA1) are highly vulnerable to brute force attacks using techniques such as pre-computed rainbow tables. The results of the disclosure of password hashes can be devastating; in 2012 more than 6 million unsalted password hashes were stolen from LinkedIn . LinkedIn used a simple SHA1 algorithm for its password hashes, an algorithm which is so vulnerable that online tools and database exist to crack it automatically .
A far more secure solution is to employ a cryptographic technique known as salting. Hash salting is the processing of appending a long random character set to each password string before it is salted, defeating the pre-computation advantage afforded by rainbow and lookup tables that makes conventional salting so insecure. Hashing and salting must of course always be performed on the server. Salting does not however prevent brute force techniques altogether; the best solution is to deliberately employ a slow, CPU intensive hashing function. For the purposes of this project, the PBKDF2 (password based key derivation function) from RSA labs has been used. The following algorithm has been implemented based on the work of Defuse Security :
Generate a random salt of 32 chars using the java cryptographically secure pseudo-random number generator (CSPRNG) algorithm
Prepend the users password with the salt
Hash the composite string with the PBKDF2 hashing function using 1000 iterations (this slows down an attacker if they attempt to brute force the password)
Prepend the hash with the random salt, splitting them with a colon.
Load the password hash and salt from the database
Split the string on the delimiter (colon), gaining the password hash as well as the salt
Prepend the password to be validated with the salt from the database
Hash the composite string, and check it against that which was loaded from the database. If they match, the password is valid
Otherwise respond with an error message (always username OR password incorrect to prevent hackers from fingerprinting valid user accounts).
Full Java code for these two algorithms can be found in appendix Error: Reference source not found.
In order to ensure only validated users and devices are able to access the parts of the system (and data) which they are entitled to, an authentication scheme has been employed. Similar to the way that websites maintain state through the issuance of cookies, a random authentication token is generated for each device when a user initially successfully logs in. This authentication token is then stored on both the device and in the applications database. There are a number of benefits to this approach:
Passwords are only ever stored and handled by the server, never the client device. This means that if the device is stolen, there is no password to extract
Devices are outside of the controlled environment, so if the application is ever broken in to there are no authentication or encryption algorithms (or keys) which can be stolen
Passwords only ever need to be transmitted once: when the user initially logs in
Each request can be individually validated and authenticated
Authentication tokens are generated using the same CSPRNG algorithm used for password salting but with twice the length, ensuring they cannot be guessed.
This mechanism has been employed in the application using the following algorithms:
Validate the users credentials
Generate a random authentication token
Save it in the database along with the devices other details
Respond to the device with a login success flag, and the authentication token. The device will save and encrypt this in a secure storage location for later retrieval.
If the database is ever compromised, it is easy to simply regenerate each of these authentication tokens and force users to log in again.
This is always performed upfront as soon as any device request is received, and before any processing begins:
Decrypt the devices request message using the SSL protocol
Load device information from the database
Extract the authentication token from the devices request
Compare the authentication token from the device with that stored in the database
If the two match, continue to process the request
Otherwise respond with an error message to the device.
Code for these two algorithms can be found in appendix Error: Reference source not found. Add a flow chat for this stuff
Authentication of web users is achieved in much the same vein as the authentication of devices, except using cookies. Cookies are generated using the same CSPRNG algorithm as authentication tokens. The only difference in the process is that instead of returning the token in a POST response message, the server instructs the browser to save the cookie. The cookie is then transmitted to the server with each HTTP GET request for validation, and the resulting web pages content varies depending on whether the cookie is valid or not.
Forcibly Removing a Device
In the event that a device is stolen, it is important that a parent has the ability to prevent the system from continuing to stream their child's location information to that device - as called for by the requirements specification. This particular function is managed through the use of a universally accessible web browser control panel, the implementation of which is discussed elsewhere. The control panel works by making a call to the public REST API provided by the application server, which once the user request has been validated, will attempt to remove the device from the system. This is achieved through two simple steps:
Delete the device from the database, explicitly removing the devices authentication token: this means that any requests from the device will be denied
Push a message to the device informing it that it has been removed from the application. The device will process this message, delete its copy of the authentication token, and log the user out from the system.
If the parent latterly retrieves the device and wishes to continue using the application, they simply need to log in again; causing the device to be added and a new authentication token will be generated and issued.
In order to ensure private data transferred between devices and the application server remains secret, some form of communication encryption is required. As this project is following the web services model by using a REST API, it makes sense to follow a similar model for security. The majority of web based applications (including high risk financial ones) use SSL to encrypt communications between the client and the server, and as such the same technology is employed for this application.
The first step if wishing to make use of SSL is to acquire a signed certification for the server to use. As this project is just being developed for test purposes at this stage, it is not required to pay for a certificate signed by a certificate authority, a so self-signed is sufficient. This can be done using a utility bundled with the Java SDK called keytool. Keytool is a command line utility allowing developers to create a self-signed and password-protected certificate, with the ability to choose from a range of algorithms. This can be created with a command such as:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
This generates a new self-signed certificate and private key using an RSA algorithm for the key, a key size of 2048 bits, and a validity of 360 days (before the certificate expires). The certificate is then placed in the java secure keystore (keystore.jks).
The second step is to force RESTlet to only accept connections over HTTPS using SSL. By default this is not supported, however thanks to the modular nature of the framework, it is possible to replace the default HTTP connector with a third party HTTPS connector, for example the Simple Framework HTTPS Connector  which has been used with this application. This connector must then be configured with the path of the keystore, the name and type of the certificate to use, and the password for the encrypted keystore. By removing the default HTTP connector and only accepting connections on the HTTPS protocol, clients are forced to connect using SSL, thus encrypting all traffic between them and the server. Additional problems relating to the use of self-signed certificates on the Android platform are discussed in section Error: Reference source not found.
Full details of database implementations can be found in the relevant section; however there are some important configurations in relation to security context that should be mentioned in this section. These can be summarised as follows:
Access to the database server is only provisioned to the local machine: that is, clients attempting to connect directly to the database externally will be denied regardless of their credentials. This ensures only the application server has access to the database. As should be expected, all data flows from the database should go through the application in order to be fully sanitised.
The root user account password is changed to something secure.
Database access from the application server is provisioned on a specific user account, with access carefully provisioned on a table-by-table basis.
The intention of such changes is to keep users' personal data private, with full access control to the database provided only through sanitised requests via the applications REST API.
Another benefit of implementing a RESTful API, and in particular using the RESTlet framework is the isolation afforded to each client request. When a request hits the application server, a new thread is spawned for it, resulting in almost complete isolation from the rest of the application. The benefit from this is obvious: it is very difficult for a single request to crash the server, regardless of errors in the logic or if the request itself is malformed.
RESTful web services are also in their very nature stateless, making the application highly scalable, but also placing a large reliance on the underlying database. As each request is dealt with in isolation, state is not maintained between requests, and there is no concept of a session. This means that any required state must be loaded from the database as and when required. Examples of this include device information, location information, and the status of various geofences and related alerts.
The Restful web service has been implemented as illustrated in the design section of this document, and can be accessed directly through a URL taking the following form:
For example HTTP POST's sent to https://jamescross91.dyndns.tv:2610/device/child/location are used to update a devices location.
https://jamescross91.dyndns.tv:2610/web is used for the web management console.
The REST API is insufficient for handling all of the data transmission requirements of the application. While possible for the server to send clients data, this is only achievable if a client initiates the communication (i.e. in response to a client request). There are a number of cases where this method of information passing alone is not suitable, and the server needs to initiate the transfer of information to a client (push communication):
A device has crossed a geofence
A new location update has arrived for which a device is subscribed to