1Introduction - Professor Kevin Curran – Technology ...
Integrating Geolocation into Web Applications for additional securityJonathan Orr – B00341744orr-j@email.ulster.ac.ukSupervisor – Dr Kevin CurranAbstractPeople are increasingly using the Web to conduct business. It is becoming increasingly common to conduct financial transactions online whether bidding for goods on auction sites or transferring money through an online bank account. These accounts contain sensitive information and tight security is essential.Online fraud is constantly on the rise, millions are lost every year as a result of online fraud. It is therefore important that users of services such as online banking have confidence in such services. Fraudsters are now targeting online bank accounts rather than the banks themselves. Banks employ the highest security measures to ensure security breaches don’t happen, it is therefore easier for fraudsters to attack account holders themselves. People who bank online are responsible for the details that access their account. Acquiring these details is therefore the preferred method of hacking online bank accounts. Frameworks such as Google Gears now have the ability to to determine the physical location of a person in real-time. This geographical information can be very useful in applications such as online banking. For instance, if we know the geographical location of a computer performing a particular transaction, then we can ascertain whether unusual requests are being performed.This project will research online banking and the geolocation technology in order to illustrate the importance of geolocation information and how it could be implemented to heighten security and reduce fraud in terms of online banking. This project will therefore integrate the Google Gears API with a prototype banking demo to illustrate the benefits of monitoring geographical location of users.The systems requirements will be defined and used as the specification to design, implement and test the application. The application will demonstrate how the Geolocation API can be invoked to identify a user’s real world location. To demonstrate how such information can benefit financial institutions such as online banking accounts. The location returned by Gears will be used to notify the user of his/her location and then checked to see if it is a valid location during login. This will demonstrate how the geographic location of a user can be used as an extra security precaution by denying access to accounts from invalid locations. A simple yet functional login interface will be used to demonstrate a user logging into such accounts and prompts used to alert the user of the functions taking place in the background regarding their location. AcknowledgementsI would like to thank Dr Kevin Curran my project supervisor. I would not have completed this document to the standard expect without his help and advice. I would also like to thank him for suggesting a project in which I have enjoyed working on and have interest in.I would also like to thank my girlfriend and family for supporting throughout my time and University and indeed this project. Table of ContentsContents TOC \o "1-3" \h \z \u 1Introduction PAGEREF _Toc260071036 \h 11.2Layout of Report PAGEREF _Toc260071037 \h 32Online Banking PAGEREF _Toc260071038 \h 52.1Online Banking Security PAGEREF _Toc260071039 \h 52.1.1Rapport PAGEREF _Toc260071040 \h 62.2Online Banking Fraud PAGEREF _Toc260071041 \h 72.2.1Types of Scams PAGEREF _Toc260071042 \h 72.2.2High-Risk Countries and Regions for Online Fraud PAGEREF _Toc260071043 \h 92.2.3The Clampi virus PAGEREF _Toc260071044 \h 103Geolocation PAGEREF _Toc260071045 \h 113.1Geolocation in action PAGEREF _Toc260071046 \h 113.2Geolocation applications PAGEREF _Toc260071047 \h 133.3How geolocation works PAGEREF _Toc260071048 \h 133.4Real-time location systems PAGEREF _Toc260071049 \h 153.4.1Wireless LAN PAGEREF _Toc260071050 \h 153.4.2Global positioning system (GPS) PAGEREF _Toc260071051 \h 163.4.3IP geolocation PAGEREF _Toc260071052 \h 174Gears PAGEREF _Toc260071053 \h 194.1Gears API Summary PAGEREF _Toc260071054 \h 194.1.1Geolocation API PAGEREF _Toc260071055 \h 204.1.2Geolocation API Network Protocol PAGEREF _Toc260071056 \h 204.1.3Geolocation API Demo PAGEREF _Toc260071057 \h 214.1.4Detecting and Installing Gears PAGEREF _Toc260071058 \h 214.2Implementation PAGEREF _Toc260071059 \h 224.3Security and Privacy considerations PAGEREF _Toc260071060 \h 224.3.1Privacy considerations for implementers of the Geolocation API PAGEREF _Toc260071061 \h 224.3.2Privacy considerations for recipients of location information PAGEREF _Toc260071062 \h 234.4Gears in motion PAGEREF _Toc260071063 \h 235Requirements Specification & Analysis PAGEREF _Toc260071064 \h 255.1Problem Specification PAGEREF _Toc260071065 \h 255.1.1Scenario PAGEREF _Toc260071066 \h 255.2Requirements Analysis PAGEREF _Toc260071067 \h 265.2.1Functional Requirements PAGEREF _Toc260071068 \h 265.2.1Non - functional Requirements PAGEREF _Toc260071069 \h 275.3Use case Diagrams PAGEREF _Toc260071070 \h 285.4Hardware and Software Requirements PAGEREF _Toc260071071 \h 295.5Development Languages PAGEREF _Toc260071072 \h 306System Design PAGEREF _Toc260071073 \h 316.1User Interface PAGEREF _Toc260071074 \h 326.2Proposed Implementation of System PAGEREF _Toc260071075 \h 337Implementation PAGEREF _Toc260071076 \h 357.1Application screenshots PAGEREF _Toc260071077 \h 357.2Installing Gears PAGEREF _Toc260071078 \h 377.3Retrieving a user’s location PAGEREF _Toc260071079 \h 397.4Validating a user’s location PAGEREF _Toc260071080 \h 428Testing PAGEREF _Toc260071081 \h 448.1Test cases PAGEREF _Toc260071082 \h 458.2Stages of testing PAGEREF _Toc260071083 \h 458.3Component testing PAGEREF _Toc260071084 \h 458.3.1Retrieve location testing PAGEREF _Toc260071085 \h 468.4Integration testing PAGEREF _Toc260071086 \h 478.5System testing PAGEREF _Toc260071087 \h 498.6Requirements testing PAGEREF _Toc260071088 \h 498.7Findings of testing PAGEREF _Toc260071089 \h 509Evaluation PAGEREF _Toc260071090 \h 529.1Evaluation of Functional Requirements PAGEREF _Toc260071091 \h 529.2Evaluation of Non-Functional Requirements PAGEREF _Toc260071092 \h 539.3Findings of evaluation PAGEREF _Toc260071093 \h 5410Conclusion PAGEREF _Toc260071094 \h 55Appendix A: application.js PAGEREF _Toc260071095 \h 57Appendix B: gears_init.js PAGEREF _Toc260071096 \h 59Appendix C: index.html PAGEREF _Toc260071097 \h 61Appendix D: success.html PAGEREF _Toc260071098 \h 62Appendix E: Test cases PAGEREF _Toc260071099 \h 63References PAGEREF _Toc260071100 \h 64Table of Figures TOC \h \z \c "Figure" Figure 1: Phishing Message from 'RBS' PAGEREF _Toc260071101 \h 7Figure 2: Financial Fraud Action UK bank Losses 06-09 PAGEREF _Toc260071102 \h 9Figure 3: Geolocation in action PAGEREF _Toc260071103 \h 12Figure 4: Amazon application PAGEREF _Toc260071104 \h 13Figure 5: You can tell a lot from an IP address PAGEREF _Toc260071105 \h 15Figure 6: Geolocation API Demo PAGEREF _Toc260071106 \h 21Figure 7: Radar application PAGEREF _Toc260071107 \h 24Figure 8: Process login PAGEREF _Toc260071108 \h 28Figure 9: Functionality of Gears PAGEREF _Toc260071109 \h 29Figure 10: Example login page PAGEREF _Toc260071110 \h 32Figure 11: Interaction overview diagram PAGEREF _Toc260071111 \h 33Figure 12: Gears Security Warning PAGEREF _Toc260071112 \h 36Figure 13: Login screen PAGEREF _Toc260071113 \h 36Figure 14: Location error message PAGEREF _Toc260071114 \h 37Figure 15: Successful login PAGEREF _Toc260071115 \h 37Figure 16: Gears detection code PAGEREF _Toc260071116 \h 37Figure 17: Gears installation page PAGEREF _Toc260071117 \h 38Figure 18: Gears successfully installed PAGEREF _Toc260071118 \h 38Figure 19: gears_init library PAGEREF _Toc260071119 \h 39Figure 20: Global variables PAGEREF _Toc260071120 \h 39Figure 21: updatePosition function PAGEREF _Toc260071121 \h 40Figure 22: handleError function PAGEREF _Toc260071122 \h 40Figure 23: getCurrentPosition function PAGEREF _Toc260071123 \h 41Figure 24: PositionOptions class PAGEREF _Toc260071124 \h 41Figure 25: checkCountry function PAGEREF _Toc260071125 \h 42Figure 26: Validate login details PAGEREF _Toc260071126 \h 43Figure 27: Function invalid() PAGEREF _Toc260071127 \h 43Figure 28: A model of the software testing process PAGEREF _Toc260071128 \h 44Figure 29: Retrieve location test PAGEREF _Toc260071129 \h 46Figure 30: Map interface PAGEREF _Toc260071130 \h 47Figure 31: checkCountry() test PAGEREF _Toc260071131 \h 48Figure 32: Evaluation of Functional requirements PAGEREF _Toc260071132 \h 52Figure 33: Evaluation of Non-Functional Requirements PAGEREF _Toc260071133 \h 531IntroductionOnline banking has become a part of everyday life. You can do just about anything with your account(s) once you have set up an online account with your bank. This therefore makes security a big part of online banking. Most banks require you to set up an account with a username, password and pin to protect access to your account; you can even download software that will protect websites such as an online banking account where you enter sensitive information.One of the main concerns with online banking is that of security. Fraudulent and accidental security breaches are a rare occurrence. Banks employ many procedures and systems in order to prevent these incidents. As a result they invest a considerable amount of time and money in developing systems which will prevent fraud and unauthorised access. If a security breach is discovered, the bank is liable for all money stolen, and, as a result, insures them against the possibility.The security used in online banking is a combination of technology and user authentication. The bank will use a 128 bit Secure Session Layer (SSL) encryption protocol, between its server and the user's browser. The user's browser will show a padlock when the session is secure. Using SSL can be thought of as preventing eavesdropping. If a hacker were to attempt to listen to the data transmission, they would have to guess the decryption key which is a 1 in 3.4 x10 to the power of 38 chances, making it infinitely secure. From a technology point of view, on-line banking is secure.The weakest link of on-line banking is user authentication. Typically, a user has to supply a set of answers to questions, which they have previously entered upon registration, as well as a username and password. The banks place the responsibility of keeping these answers secure with the user. If any are disclosed and money is stolen, the liability lies solely with the account holder, not the bank.Fraudsters therefore target the login details of users through a number of different scams in order to pose as the registered user and access their account, therefore bypassing security measures put in place by banks with ease. Despite the longstanding efforts of banks and the IT security community to warn end users, specifically people using online banking applications, to beware of phishing schemes, many people who open the e-mails and visiting the phony sites still end up handing over their credentials, researchers claim.Online banking fraud is on the rise, fraud losses totalled ?39m during the six months to June 2009, a 55 per cent rise on the 2008 figure. Improving security in terms of online banking is therefore a big concern. Anyone in the world could access your account if they gain access to your account information; countries such as Nigeria have a history of online fraud.Location awareness is becoming a big part of web development especially with the introduction of mobile devices such as smart-phones and PDAs. Geolocation is the process of automatically identifying a web user’s physical location without that user having to provide any information. Such technology is already being implemented on the web to determine how a user arrives at country-specific websites for example. A web users location can be very useful information, a whole host of services can be centred on a user’s location. The social networking site Twitter for example has recently incorporated geolocation. A Twitter user can now find what people are posting from the place where an important event is happening, or what people are saying about a specific restaurant or store.Gears (formerly Google Gears) is software offered by Google that enables more powerful web applications by adding new features to your web browser. One of the features of Gears is the Geolocation API; this enables a web application to obtain a user's geographical position. Gears is already being used to develop new and exciting web applications. Basically Gears is a set of JavaScript APIs that can be integrated into your browser.Throughout this report I therefore intend to identify the benefits of monitoring the Geolocation of users online and show how this information can be incorporated into improving security of online banking by integrating the Gears API with a prototype banking demo.1.2Layout of Report OverviewAs this report is based on improving security for web applications that deal with financial transactions such as online banking. Using online banking as an example to create a demo application, to display these benefits I therefore researched various areas of online banking and geolocation. This research then had to be taken and analysed to determine what elements of it were relevant to the application, this report has therefore been structured in the following manner.In chapter 2 we take a brief look at online banking in general and security measures already being implemented in the world of online banking. Fraud is discussed including the different forms of scams that are capable of compromising online bank accounts as well as the figures behind these scams. We also take a look at locations around the world that have a history of online fraud and take a look at Nigeria, a country that is notorious for online fraud. Chapter 3 moves onto geolocation, an overview is provided and detail into how geolocation works. How geolocation is already being implemented on the web is also covered, and the technologies that make geolocation possible.The Gears framework is reviewed in chapter 4 including a summary of its APIs. The Geolocation API is reviewed in more detail here as this is the API that I wish to implement. How the Geolocation API functions and issues to consider when implementing the API are covered. Examples of how the Geolocation API is already being implemented are included.Requirements specification and analysis is the aim of chapter 5. Problem specification and a system scenario are illustrated. The functional and non-functional requirements are defined along with corresponding use case diagrams. Hardware and software requirements and development languages are also mentioned.Chapter 6 defines the architecture of the system. How the system requirements are meet is defined here in a description of how the system will function. The user interface is also looked at including an example and HCI guidelines. An interaction overview diagram depicts the control flow of the proposed system along with a textual description.Chapter 7 looks are how the proposed system was implemented. Screen shots, code snippets and information on the technologies used are illustrated to define how the system has been implemented and in turn how it is intended to be used.Chapter 8 explains why testing is important and highlights the different stages involved in testing. How the system was tested throughout each stage is illustrated and results analysed. Test cases involved in testing the system can be seen in Appendix F. Chapter 9 how the system has met its functional and non-functional requirements (laid out in chapter five) are evaluated in this chapter.Chapter 10 concludes the report. Why the project was deemed necessary, how it was implemented and whether it was deemed a success is talked about here. As well as what was learnt from the project and how it could advance in the future.2Online BankingOnline banking (or Internet banking) allows customers to conduct financial transactions on a secure website operated by their retail or virtual bank, credit union or building society. Online banking uses today’s technology to give people the option of bypassing the time consuming paper-based aspects of traditional banking. With an online banking account you can:View a summary of your account(s) in real time.View bank and credit card statements, this includes transaction history, charges and interest on your account.Transfer money between accounts and schedule future transfers.Make payments, pay your credit card, pay/set up standing orders and direct debits.Order a cheque book.Most large banks now offer online banking and therefore security to go with it. Banks spend years building up relationships with their customers and therefore a level of trust. For banks to convert people to banking online they have to ensure that their customers will be safe and secure. After all banking online benefits both the banks and its customers in general. Customers can bank from the comfort of their home and the banks save money on costly paper handling and teller interactions.2.1Online Banking SecurityBanks such as Barclays have excellent security as they ask the user to enter their login details by selecting information form drop-down menus. Simply using menus rather than the keyboard stops keyloggers from quickly capturing passwords. Keylogging software is blamed for online banking fraud more than doubling in 2008. It soared to ?52.5m last year, up from ?22.6m in 2007 according to the UK Payments Administration.Barclays also offer users the Kaspersky Internet Security Suite for free if you bank with them online. The Kaspersky Internet Security Suite offers anti-virus protection and a personal firewall to help stop viruses and Trojans before they get hold of your data. It also includes a spyware scanner, spam filter and parental control features. However, anti-virus software and firewalls only go so far, most banks including my own offer a free software solution known as ‘Rapport’ for safer online banking.2.1.1RapportRapport is a software solution from Trusteer that secures communication from keyboard to website; many banks now offer this software for you to download as added protection against fraud whilst banking online. It detects and prevents Man–in-the-Browser, Man-in-the-middle, phishing, and other attacks launched directly against the user. When users browse to sensitive websites such as online banking, the Rapport plug-in immediately locks down the browser, and prevents any unauthorized access to web pages and sensitive information that flow through the browser. This browser lockdown is achieved through a combination of access control, encryption, and verification technologies that take place in the background, completely transparent to the user. The purpose of the browser lockdown is to prevent malware known as Man-in-the-Browser from accessing the browser itself, as well as keystrokes typed into the browser, and communication that enters and leaves the browser. While the browser is locked down, malware cannot read the content of web pages, or information entered into these websites. Malware cannot tamper with web pages or web communication. In addition to locking down the browser, Rapport also locks down communication with the website. It authenticates the website, and forces end-to-end secure communication with the website. This communication lockdown prevents both Man-in-the-middle and phishing attacks, and prevents criminals from accessing sensitive web communication. Unauthorized attempts to access the browser or its communication are automatically reported to the Trusteer cloud-based fraud analysis service. The Trusteer team of fraud analysts works 24x7 analysing this information from customers all over the world, in order to identify new attack patterns. Institutions registered for the Trusteer service receive immediate reports and actionable alerts of new attacks, and can learn of attacks as they happen, instead of days, weeks, and sometimes months later.2.2Online Banking FraudDeceiving a user to steal their login information is the most common attack on users banking online. Two well known examples of these attacks are phishing and pharming.2.2.1Types of ScamsPhishing is the criminally fraudulent process of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication.What this means is, if you bank online, you could receive an email claiming to be from your bank asking you to ‘update’ or ‘verify’ information regarding your account. You will then be asked to click on a link that will direct you to another website in order to do so, this will be a fake website set up by the fraudster, and any information entered on this site will be captured by the fraudster and therefore be manipulated by them. Figure 1 shows an example of a scam email.Figure SEQ Figure \* ARABIC 1: Phishing Message from 'RBS'Banks will never contact you by email to ask you to enter your password or any other sensitive information by clicking on a link and visiting a web site. The emails are sent out completely at random in the hope of reaching a live email address of a customer with an account at the bank being targeted.Pharming is a hacker's attack aiming to redirect a website's traffic to another, fake website. Pharming can be conducted either by changing the hosts file on a victim’s computer or by exploitation of a vulnerability in DNS server software.Trojan Horses are a type of computer virus which can be installed on your computer without you realising. Trojans can be capable of installing a ‘keylogger’ on your computer that captures all the keystrokes entered on your keyboard. The keylogger can then be used to capture passwords for certain websites. Trojans can even be used to take screen shots of websites you visit. This information is then sent to the fraudster over the internet. Like phishing, emails are sent out at random asking users to click on a link that will direct them to a fake/malicious website where vulnerabilities in the web browser are used to install the Trojan. Money Mules, most of these scams are conducted by fraudsters overseas, if a fraudster is successful in hacking your account, it is however impossible for the fraudster to make a cross-border transfer from your account to one overseas outside of the UK, this is where ‘Money Mules’ come in. Money Mules basically launder the funds obtained from Phishing and Trojan scams. They are recruited online by fraudsters and receive funds in their accounts; these funds are then withdrawn and sent overseas using a wire transfer service. The fraudster receives his money and the mule a commission for his/her services.Jan to June 2006Jan to June 2007Jan to June 2008Jan to June 2009+/-(08/09)Online banking fraud loses?22.4m?7.5m?25.2m?39.0m=55%Figure 2: Financial Fraud Action UK bank Losses 06-09Figure 2 shows that online banking fraud loses rose by 55% over the last year. The rise is mainly due to fraudsters employing more sophisticated methods and choosing to target customers of banks rather than the banks themselves, which are more difficult to attack.In general it is very difficult for someone to gain access to your login details as long as you take the right precautions. Fraudsters mainly gain access to these details by tricking the user into providing them. If someone does gain access to your details it is then very easy for them to use them. It is not just within the UK and Ireland that fraudsters are trying to hack your account, someone on the other side of the globe could be doing so, and in fact a number of countries have a higher rate of online fraud than others.2.2.2High-Risk Countries and Regions for Online FraudCountries or regions that are regarded as having high risk online fraud include Africa, Amsterdam in Holland, Belgium, Bulgaria, China, Eastern Europe, Egypt, Ghana, Malaysia, Russia, Malm? in Sweden, Nigeria, Pakistan, Palestine, Romania, Indonesia, Israel, Lithuania, Southwest Asia, Turkey, Ukraine and Yugoslavia.Nigeria – High RiskNigeria remains one of the largest fraud and scam operations in the world. New tactics by criminals in Nigeria are increasingly sophisticated, and victims range from individuals, to investors, to multi-national corporations. New system technology allows Nigerian criminals to hide their true location, masking their IP address and using non-Nigeria phone numbers and mailing mon Fraud:Advance fee fraud, dating scams, dating fraud, inheritance scams, online dating scams, business fraud, investment scams, charity, and employment fraud.2.2.3The Clampi virusCyber criminals have created a highly sophisticated Trojan virus that steals online banking log-in details from infected computers. The Clampi virus, which is spreading rapidly across hundreds of thousands of computers in Britain and the United States, infects computers when users visit websites that host a malicious code. Once on the computer, the virus sits unnoticed until the user logs on to bank, credit card or other financial websites. It then captures log-in and password information and sends it to a server run by the attackers. They can then tell the compromised computer to send money to accounts that they control, or they can buy goods with the stolen credit card details. The Trojan has a list of more than 4,500 finance-related websites that it monitors, including British high street banks. Security experts warned that it was one of the stealthiest and most pervasive threats to computers using the Microsoft Windows operating systems. This is an extract from a recent article (21/09/09) in The Times newspaper about the so called ‘Clampi’ virus. It shows just how sophisticated and global online fraud is becoming. A security operations manager at a top online security company referred to the virus as “a complex threat”. Researchers have found that the virus is monitoring not just banks, but credit card companies, online casinos and retail sites to name a few. The virus originated in the US and is spreading around the world, particularly English-language countries. Evidence that the virus has targeted UK high street banks is already present. It is estimated that more than 1,000 out of 40,000 or more infected computers have been in Britain. In America Clampi stole online banking details from the public school district in Sands Spring, Oklahoma. The attackers then submitted a series of false payroll payments, totalling more than $150,000. The Washington Post reported that Cyber criminals stole more than $700,000 from the Western Beaver School District in 74 fraudulent electronic transfers.Clampi is one of a new wave of viruses to target the online banking system. Its emergence came as security experts warned that malicious websites hiding Trojan viruses were no longer confined to sites such as gambling and pornographyA recent report by IBM security systems found an increase in malicious content such as viruses on trusted sites, including popular search engines, blogs, online magazines and mainstream news sites. The number of links to malicious web pages rose by more than 500 per cent in the first half of this year. Attackers recently placed a virus in an advert on the website of The New York Times.3GeolocationGeolocation is the identification of the real-world geographic location of an Internet-connected computer, mobile device, website visitor or other. IP address Geolocation data can include information such as country, region, city, postal/zip code, latitude, longitude and time zone. Geolocation may refer to the practice of assessing the location, or to the actual assessed location, or to locational data. This chapter will provide an overview of geolocation in general, we will look at how geolocation works, how it is being implemented on the web already and take a look at the real-time location systems that make geolocation possible.3.1Geolocation in actionIn order to understand how geolocation works, it is best to see it in action, chances are you already have. Search engines such as Google use geolocation not just for global navigation and search, but to provide users with locally relevant results. In order to demonstrate this I entered ‘restaurants’ into Google and got the following results.Figure SEQ Figure \* ARABIC 3: Geolocation in actionAs you can see, highlighted in red are business results for restaurants in my local area, I didn’t enter my location when searching, yet Google somehow knows where I live. If I would have searched for a ‘computer store’ for example I would be presented with computer stores in my local area. How did Google know where I live, geolocation is how.Another example of this is, if I enter ‘’ into my web browser and click return, I am automatically directed to ‘google.co.uk’. This is to ensure users around the world find content that has been localised for them. If for example a user from Spain enters ‘’, without geolocation (s)he would be directed to the and have to navigate through the site to find the link to the Spanish site. Geolocation is increasingly being implemented to ensure web users around the world are successfully being navigated to content that has been localised for them. Companies especially are investing heavily in this. Due to the ‘.com’ dilemma, most companies are finding that more than half of the visitors to their global (.com) home pages are based outside of their home markets. The majority of these users don’t find the country site that has been developed for them. Companies such as Amazon have introduced geolocation as a method of dealing with this problem. 3.2Geolocation applicationsGeolocation applications are as you can see already being implemented on the web. Companies for example also use geolocation to navigate users to localised content. Amazon uses geolocation to ensure that its customers shop from the most relevant websites. If I browse to , I am displayed with the following homepage.Figure SEQ Figure \* ARABIC 4: Amazon applicationNotice the ‘Shopping from the UK?’ banner, Amazon knows that I am shopping from the UK and therefore wants to direct me to the UK website; this is beneficial to the user as the content of the American website () will vary to that of the UK website. Currency and region restrictions on DVDs and video games are examples of this. Amazon could if it wanted automatically direct the user to the UK website like in the Google example; however it doesn’t do so as this allows Americans who live in the UK to continue shopping from the .com site. 3.3How geolocation worksThe foundation for geolocation is the Internet protocol (IP) address, a numeric string assigned to every device attached to the Internet. When you surf the web, your computer sends out this IP address to every website you visit.IP addresses are not like mailing addresses. That is, most are not fixed to a specific geographic location. And knowing that a particular ISP (Internet Service Provider) is based in a particular city is no guarantee that you’ll know where its customers are located. That’s where geolocation service providers come in. Geolocation service providers build massive databases that link each IP address to a specific location. Some geolocation databases are available for sale, and some can also be searched for free online. As the IP system is in a constant state of flux, many providers update their databases on a daily or weekly basis. Some geolocation vendors report a 510% change in IP addresses locations each week. Geolocation can provide much more than a geographic location. Many geolocation providers supply up to 30 data fields for each IP address that can help to further determine if users really are where they say they are. These may include: Country, region, state, city, ZIP code, area code Latitude/longitude Time zone Network connection type and speed (i.e. dial-up or Broadband; slow or fast) ? Domain name and type (i.e. .com or .edu)Not every IP address accurately represents the location of the web user. For example, some multinational companies route Internet traffic from their many international offices through a few IP addresses, which may create the impression that some Internet users are in, say, the UK when they are actually based in France. Or, if someone is using a dial-up connection from Ireland back to their ISP provider in the France, it will appear like they are in the France. There are also proxy services that allow web users to cloak their identities online, a few geolocation providers however have introduced technology that can look past these proxy servers to access the user's true location. Figure 4 depicts a map of IP addresses within Europe.Figure 5: You can tell a lot from an IP addressIn addition, some providers can now locate, down to a city-street level, people connecting to the Internet via mobile phones or public Wi-Fi networks. This is accomplished through cell tower and Wi-Fi access point triangulation.3.4Real-time location systemsA real-time location system (RTLS) is one of a number of technologies that detects the current geolocation of a target. These technologies include wireless LAN, GPS (Global positioning system), and IP geolocation. We will look at these in more detail below.3.4.1Wireless LANA WLAN has the ability to locate wireless enabled devices anywhere within a local coverage area, usually to provide access to the internet through an access point. Any device that is communicating with the wireless network has the potential to be located in real time using the wireless system. Wireless LANs have become more popular especially in the home due to ease of installation and the increasing popularity of laptops. Wi-Fi hotspots are being set up in and around towns and cities; businesses such as coffee shops, hotels, and shopping centres now offer wireless access to the internet for free in some cases. Devices that connect to a wireless network are known as stations, these so called stations are all equipped with wireless network interface cards (WNICs). Wireless stations fall into two categories; access points and clients. Access points (APs) normally routers are base stations for the wireless network. They transmit and receive radio frequencies for wireless enabled devices to communicate with. Wireless clients can be mobile devices such as laptops, PDAs, mobile phones, or fixed devices such as desktops and workstations. 3.4.2Global positioning system (GPS)GPS is a "constellation" of 24 well-spaced satellites that orbit the Earth and make it possible for people with ground receivers to pinpoint their geographic location. The location accuracy is anywhere from 100 to 10 meters for most equipment.21 GPS satellites and three spare satellites are in orbit at 10,600 miles above the Earth. The satellites are spaced so that from any point on Earth, four satellites will be above the horizon.Each satellite contains a computer, an atomic clock, and a radio. With an understanding of its own orbit and the clock, it continually broadcasts its changing position and time. (Once a day, each satellite checks its own sense of time and position with a ground station and makes any minor correction.)On the ground, any GPS receiver contains a computer that "triangulates" its own position by getting bearings from three of the four satellites. The result is provided in the form of a geographic position - longitude and latitude - to, for most receivers, within 100 meters.If the receiver is also equipped with a display screen that shows a map, the position can be shown on the map.If a fourth satellite can be received, the receiver/computer can figure out the altitude as well as the geographic position.If you are moving, your receiver may also be able to calculate your speed and direction of travel and give you estimated times of arrival to specified destinations.GPS signals do not generally penetrate the interiors of buildings, therefore limiting the use of GPS to outdoor environments where there is a clear line of site to at least three satellites.3.4.3IP geolocation The most established RTLS is not based on wireless networking technology at all but relies on Internet Protocol (IP) addresses to provide geolocation information. Geolocation as explained earlier provides the ability to route users to different websites according to the presumed location of the origination IP address. This capability is often utilised to route the user to data centres that are closer to the user in the hope of providing better performance and faster response time.Avangate, a company that provides professional ecommerce and channel management technology for software companies worldwide published an article on Effective Anti Fraud Tools. The article looks at the fraud detection tools an e-commerce provider should have. One of the tools the article highlights is IP geolocation. Below is what the article highlighted about implementing IP geolocation as an effective anti fraud tool.Knowing the online buyers geographic information might actually result to be a pretty useful tool to prevent fraud. IP geolocation can exactly detect where the user is located or calculate the distance between billing address of online buyers and the actual location of persons entering the orders. Nevertheless, this might not be so efficient since fraudsters could also employ proxy servers in order to hide their true IP address and location. The geolocation technology delivers information which helps determine which transactions are worth reviewing and which are worth allowing. This creates a beneficial balance between the risk of fraud losses and that of blocking legitimate customers. Basically, an IP address is a network identifier issued by an Internet Service Provider to a user's computer every time they are logged on to the Internet. For an order to be considered legitimate, the IP address country and the billing address country should be the same, although there might be exceptions: for instance, the billing address might match the person in spite that the IP might hint at another country. Although this situation might be perfectly legitimate (for instance a person travelling to another country), some extra precautions should be taken. For a more accurate detection, some e-commerce companies are even able to identify the exact city/town and country where the card holder is situated, actually increasing the level of certainty. 4Google GearsGears is an open source project that enables more powerful web applications by adding new features to web browsers. The Gears project aims to improve browsers in new ways, in general Gears is a set of java script API’s that you add to your browser and can call from your web applications. Gears can be used across all platforms (Windows, Mac, Linux etc...) and browsers (Firefox, Safari, Internet Explorer etc...) making it accessible to everyone. Gears is even available on a number of mobile browsers and devices. The overall aim of Gears is to make web applications just as powerful as desktop applications. 4.1Gears API SummaryThis is a list of all the Gears API’s along with a brief summary of their purpose.Factory – Instantiates all other Gears objects.Blob – Provides a way to reference binary data.BlobBuilder – Provides a way to reference binary data.Canvas – Provides a way to perform image manipulation.Database – Provides a SQL database for storing data on the local machine.Desktop – Provides an interface for accessing Desktop functionality.Geolocation – Provides a way to obtain a user’s geographical position.HttpRequest – Provides the ability to send HTTP requests in workers, as well as on the main page.LocalServer – Caches and serves your application's resources locally, making it possible to start a web application without a network connection.Timer - Provides a timer that can be used in workers, as well as on the main page.WorkerPool - Provides the ability to run JavaScript code asynchronously.4.1.1Geolocation APIThe Geolocation API enables a web application to obtain a user's geographical position. The Geolocation API enables a web application to retrieve a user's current position, using the getCurrentPosition method. It allows you to watch the user's position as it changes over time, using the watchPosition method and obtain the user's last known position, using the lastPosition property.The Geolocation API provides the best estimate of the user's position using a number of sources called location providers. Whatever location providers are available are used to figure out the location. Every WI-FI access point and cell tower has an ID, this information along with GPS and IP addresses are sent to a location server and used to give the most accurate position possible. The information you receive back can include latitude / longitude, altitude, horizontal / vertical accuracy and time stamp (when the position was last fetched).The getCurrentPosition and watchPosition methods support an optional parameter of type PositionOptions which lets you specify which location providers to use. To protect user privacy, the Gears Geolocation API server does not record user location, third party sites may do so however, it is therefore recommended that users only allow web sites they trust to access their location. Gears will always tell a user when your site wants to access their location for the first time and the user can either allow or deny your site permission. A site's permission to use location information is separate from the permission required by other Gears APIs. Permission is granted by the user in the same way as for other Gears APIs, through a dialog. You can customise the default dialog by explicitly calling the getPermission method.4.1.2Geolocation API Network ProtocolThe Gears Geolocation API can make use of network servers to obtain a position fix. The server determines the client's position using a set of data provided by the client. This data includes the client's IP address and information about any cell towers or Wi-Fi nodes it can detect.Many devices do not have native access to GPS or other location data. Additionally, GPS can take a long time to get an accurate location fix and does not work indoors. Due to these problems, the network protocol also has the ability to send various signals that the devices has access to (nearby cell sites, Wi-Fi nodes, etc) to a third-party location service provider, who can resolve the signals into a location munication is done over HTTP, with Gears making the request using HTTP POST. Both request and response are formatted as JSON, and the content type of both is application/json.4.1.3Geolocation API DemoFigure 6 shows an example of the Geolocation API in use, as you can see below the user’s position is being retrieved.Figure SEQ Figure \* ARABIC 6: Geolocation API DemoThe users position is then returned, in this example the; city, region, country, latitude and longitude of the users location is returned. It is even possible to return accurate information such as the number / name of the street regarding the user’s position. This is possible through the getCurrentPosition method. The getCurrantPosition provides a previously cached position if available and repeatedly obtains a new position.4.1.4Detecting and Installing GearsBefore an application implementing Gears can call any of its APIs, the application must first detect whether or not Gears is installed on a user’s system. This is to ensure that once the APIs are called, they are present and can be manipulated. Gears therefore needs to check if it is installed on the users system and in turn prompt the user to do if not. Gears is therefore initialised using gears init.js. If Gears is installed, then ‘google.gears’ will be defined. If Gears isn’t installed then the user needs to be directed to an installation page.4.2ImplementationThe Geolocation API is an abstraction for various location APIs that currently exist on mobile platforms (GPS-based, network/cell id-based). Geolocation implementations could be straightforward mappings to native APIs or have a more complex design that combines several location providers and returns the location from the most accurate provider at any given time. The Gears implementation chooses the location provider to invoke subject to the criteria specified with PositionOptions. When location data is requested, the first result that satisfies the criteria is returned via the PostionCallback function. Subsequent invocations will always use the most accurate location data available. This caters for the common case where a less accurate fix from a network-based location provider can be obtained quickly followed by a more accurate GPS fix later. 4.3Security and Privacy considerationsThe Geolocation API can be used to retrieve the geographic location of a hosting device. In almost all cases, this information also discloses the location of the user of the device, thereby potentially compromising the user's privacy. A conforming implementation of the API must therefore provide a mechanism that protects the user's privacy and this mechanism should ensure that no location information is made available without the user's express permission.4.3.1Privacy considerations for implementers of the Geolocation APIUser agents must not send location information to websites without the express permission of the user. User agents must acquire permission through a user interface, unless they have prearranged trust relationships with users, as described below. The user interface must include the URI of the document origin. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session must be revocable and user agents must respect revoked permissions. Some user agents will have prearranged trust relationships that do not require such user interfaces. For example, while a Web browser will present a user interface when a website performs a geolocation request, a VOIP telephone may not present any user interface when using location information to perform an emergency 999 function. 4.3.2Privacy considerations for recipients of location informationRecipients must only request location information when necessary. Recipients must only use the location information for the task for which it was provided to them. Recipients must dispose of location information once that task is completed, unless expressly permitted to retain it by the user. Recipients must also take measures to protect this information against unauthorised access. If location information is stored, users should be allowed to update and delete this information. The recipient of location information must not retransmit the location information without the user’s express permission. Care should be taken when retransmitting and use of encryption is encouraged. Recipients must clearly and conspicuously disclose the fact that they are collecting location data, the purpose for the collection, how long the data is retained, how the data is secured, how the data is shared if it is shared, how users may access, update and delete the data, and any other choices that users have with respect to the data. 4.4Gears in motionWi-Fi based positioning means that you can deliver web applications for laptop users that are automatically customised to your user's exact position. has developed a ‘radar’ application using the Gears Geolocation API (see Figure 7). By simply clicking on the get hotels near you link on the map, within seconds you can view hotels around your current location without having to enter any information at all.Figure SEQ Figure \* ARABIC 7: Radar applicationITN have also developed an application that allows users to view news stories local to their position graphically on a map, using the Geolocation API, plus if you have the Google Earth plug-in installed, the results are shown Google Earth. A service known as ‘Rummble’, a form of social networking application that allows its users to build up trust networks by creating and sending ‘Rumbles’ to one another also implements Gears and the Geolocation API by automatically centring its search of nearby Rummbles on the user's position. 5Requirements Specification & Analysis5.1Problem SpecificationIn most cases online banking can be a very safe and useful application. Provided users take the right precautions; install anti-virus software, firewalls and additional software such as Rapport then it can be very difficult for someone to access your account information and gain access to your account. Most banks now warn their customers about the likes of phishing attacks and as long as customers don’t fall victim to such attacks then they should have no problems banking online. Fraudsters however are developing more sophisticated methods for hacking user accounts and people do get conned and fall for phishing attacks. Users that aren’t computer literate for example and use computers casually to do things such as online banking would probably find an email from their bank very innocent and have no problem following the instructions given on it and fall into the fraudsters hands. Preventing the fraudster however from using the users account information would be a very useful security feature. Most attacks on online bank accounts happen from locations overseas and the funds are transferred out of the country with the help of Money Mules for example. Some country’s have a history of online fraud, such as Nigeria. Gears and its Geolocation API can pinpoint a user’s location with great accuracy. Incorporating this into an online banking application would therefore enhance security by preventing online bank accounts from being accessed from locations with a history of online fraud.5.1.1ScenarioSay for example a user’s online bank account is compromised by a fraudster hacking accounts from Nigeria. Allow the fraudster is in another country, it is very easy for him to access accounts within the UK and Ireland if he has the required information. If however the location of the user accessing the account was to be checked and compared against a list of countries with a history of online fraud, and the location of the user matches a location on the list then the user would be refused access to the account. A report of the attack (including the location, time and account details etc...) could then be generated and the bank notified. The bank could then notify the account holder about the attack and the user’s login details could then be updated to enhance security.The Geolocation information would therefore make the login details stole by the fraudster obsolete and enhance security greatly. I therefore aim to develop a system that will implement the Gears Geolocation API in this way to display the advantages of monitoring the Geolocation of users.5.2Requirements AnalysisThe application will represent an online banking demo that implements the Gears Geolocation API to verify a user’s location. The user will be prompted to enter a user name and password, once the user completes these fields and clicks enter, the location of the user will be checked against a list of countries with a history of online fraud before the login can be processed. If the user’s location is on the list then access to the account will be denied and a log of the attempted login will be generated. There are two types of requirements, System and User requirements; these can then be split into Functional and Non-Functional requirements.5.2.1Functional RequirementsIn software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behaviour, and outputs.Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioural requirements describing all the cases where the system uses the functional requirements are captured in use cases. Functional requirements are supported by non-functional requirements.The application must have a simple yet functional graphical user interface (GUI).Allow users to login with a username and password.Prompt the user to install Gears if not currently installed in the browser.Check the location of the user before verifying login details.Process login if user location is valid.Deny access if login is incorrect.Deny login if user location is invalid, not process login details.5.2.1Non - functional RequirementsA non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be.Security – Users can only submit login details to be processed once their location has been verified. If the user’s location is not a valid location then their login details are not processed and the user will be unable to login to the account. The user will gain access to the account by successfully entering their login details after their location has been successfully verified. A log of each failed login is generated and stored.Performance – The application will quickly process the user’s location so that the login details can be processed without much delay.Usability – User must have Gears installed in their browser before the location of the user can be verified. The system will therefore prompt the user to install Gears if not already present in the user’s system. Users will not be allowed to proceed until Gears has been installed. Gears will then prompt the user with a security message prompting the user to allow Gears to verify the location. The user will not be allowed to proceed until Gears is allowed to check the location of the user. If the user denies Gears this permission then the session is ended.Robustness – The application will be able to deal will invalid data entry and adverse conditions therefore making the system reliable.Portability – The application will adapt to run on multiple platforms, these platforms include operating systems and browsers. The system will therefore run on Windows, Mac, Fedora etc..., and Firefox, Internet Explorer, Safari etc...Privacy – As the application is accessing the location of the user, it is therefore important that this information if disposed of once the task has been completed and protected from unauthorised access. Reliability – The application will provide the service expected be the user.5.3Use case DiagramsAfter assessing the functional and non-functional requirements of the proposed system, use case diagrams have been devised to illustrate how the user will interact with the system and to display the functionality of the system.Figure 8 illustrates what happens when a user interacts with the application.Figure 8: Process login Figure 9 illustrates the functionality of Gears when a user attempts to login to the application.Figure 9: Functionality of Gears5.4Hardware and Software RequirementsThe application will require the following hardware and software.Hardware A computer to run the application (desktop, laptop, workstation etc...)Peripherals such as mice and keyboardsAn internet access pointA server to send a receive location information.Software Web browserGoogle Gears5.5Development LanguagesJavaScript will be used to implement Gears and its Geolocation API. Visual Studio 2008 will be used to create the user interface that will accept and process login information (i.e. username and password). HTML will be used to combine the two into a web application. The overall application will be developed on the Windows platform and tested using various web browsers such as Firefox and Internet Explorer.6System DesignSystems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. In the chapter I will therefore detail the design of the demo online banking application. In doing this I will illustrates the user interface and describe the process flow within the application.The application will present the user with a login screen. Here the user must enter a username and password, as this is a demo application and the emphasis is not on the strength of the username and password, but what is going on in the background (Gears), a simple login screen that can process a username and password will therefore suffice.Once the user enters and submits a username and password, Gears is initialised and checks the users system to see if Gears is present. If Gears is not present on the users system, the user is directed to an installation page where Gears can be downloaded and installed. Users will not be allowed to progress in the login process until Gears has been successfully installed on their system.When Gears is present on the users system the user will be prompted with a security warning, notifying the user that Gears is about to access information regarding the user’s location. In order for users to proceed they will have to allow Gears to do so. User’s who deny Gears of the permission to retrieve their location information will be notified that they cannot progress until Gears is granted such permission. When Gears is allowed to retrieve the user’s location, the Geolocation API is called and the user’s location retrieved. The location of the user is then compared against a database containing locations that have a history of online fraud, if the user’s location corresponds with one on the database then the user’s login details are not processed and the user is refused access to the account. A record of the attempted login is then generated and stored in a separate database. When and only when the location of the user is valid are the user’s login details processed. When the user’s login details are submitted they are verified and if correct then the user is granted access to the account, otherwise the user will be denied access.6.1User InterfaceFigure 10 depicts an example of what the login screen will look like. This is a simple interface to illustrate logging into an account. There are two textboxes, one for inputting a username and the other for inputting a password. There is also a submit button to submit the details entered.Figure 10: Example login pageHCI guidelines:Consistency: It is important to keep consistency within the application. This can be done by using a standard form layout, i.e. placing buttons in the same position, consistent button size, and consistent use of fonts colour patibility with Users’ Expectations: The application should use simple language. The application should have a steady yet easy learning curve. The application should also be intuitive and easy to use.Flexibility and Control: The application should meet the needs of all types of users, both novice and expert.Continuous and Informative Feedback: The user should receive feedback on actions that they performed, e.g. search successful or search unsuccessful. The instructions and ‘About’ information should also be provided.Error Prevention and Correction: Inactive buttons should be greyed out or disabled. This will prevent users from clicking on them and causing an error. Visual Clarity: The interface should be clear and coherent, without too many items cluttering the screen space6.2Proposed Implementation of SystemFigure 11 depicts an overview of the control flow within the proposed system. A textual description is also provided.AccountHolderOnlineAccountGearsIdentifyRequest AuthenticationProvide AuthenticationVerify LocationConfirm LocationFraud PossibleValid LocationFraud PossibleGrant AccessAccountHolderInvalid LocationOnlineAccountOnlineAccountBankAuthenticate identityConfirm identityAccountHolderInvalid IdOnlineAccountOnlineAccountNotify Invalid LocationBankBlock AccountFigure 11: Interaction overview diagramThe account holder identifies himself to the online account.The online account requests the account holder authentication.The account holder provides his authentication.The online account verifies the holder’s location with Gears.Gears confirms the holder’s location.The online account authenticates the holder’s identity with the holder’s bank.The bank confirms the holder’s identity authentication.The account holder is granted access to the account7ImplementationDuring the implementation stage the design is realised as program with the user requirements identified in chapter five being used as the specification. It was stated in chapter five that Visual Studio 2008 would be used to create the user interface that will accept and process login information (i.e. username and password). During implementation however JavaScript was used to create the user interface. This would not be the recommended approach when developing a web application that needed strong password protection, as login information could be easily hacked. As emphasise of this project however is on geolocation information being used to improve security, a simple JavaScript login has been deemed sufficient. Chapter 7 will look at the implementation of the system defined throughout this report; screen shots, code snippets and information on the technologies used are illustrated to define how the system has been implemented and in turn how it is intended to be used. 7.1Application screenshotsWhen a user loads the login page for the first time, a Gears security warning is displayed to the user (Figure 12). This is important as disclosing information regarding a user’s location is potentially compromising the user's privacy. The warning states that Gears is going to retrieve information regarding the user’s location. The user must allow Gears to retrieve such information. To do so the user must check the box and click on the ‘Allow’ button. The login page will then load. The user is only required to agree to this warning once. The next time the user loads the login page it will load without displaying the warning. If the user loads the login page again from another terminal, the warning will appear again on the first attempt.Now that the user has agreed to share his/her location, the login page loads and an alert box appears stating the country that the user is trying to access the account from (Figure 12). This is to illustrate that the application knows the location of the user. The user must click ‘OK’ to close the alert. If a user clicks ‘Deny’ on the security warning the login page will still load but the user’s location will not be retrieved, in this event the user is not able to login into the account.Figure 12: Gears Security WarningFigure 13: Login screenNow that the login page has been loaded and the users location retrieved, the user can now attempt to login to the account. To do so the user must enter the username and password and click submit. When the user clicks submit the user’s location is verified. If the user’s location is not valid, an error message is displayed (Figure 13).Figure 14: Location error messageIf the user is logging in from a valid location, the username and password are verified and access to the account is granted. Figure 15 depicts a successful login. If the username and password is incorrect, the user is asked to submit them again.Figure 15: Successful loginAccessing the site from a browser that does not have the Gears plug-in installed will result in the user being redirected to the Gears installation page. Once Gears is installed the login page will load.7.2Installing GearsWhen a user accesses the login page, the application checks to see if the user has Gears installed on his/her browser. In order for the user’s location to be retrieved, Gears needs to be installed. Figure 16 shows the detection code used to detect if Gears is installed. The code comes from a Google Gears FAQ item and is the recommended way to detect if Gears is installed in a browser. If Gears is not installed, the user is redirected to the Gears installation page (see Figure 17).if (!window.google || !google.gears) { location.href = ""+ "&message=Welcome to Google Gear Installation";}Figure 16: Gears detection codeFigure 17: Gears installation pageThe user can now click on the ‘Install Gears’ button to start the installation process. The user will then be prompted to agree to the terms of service and privacy policy. Once the user agrees the installation file can be downloaded. The user can then open the downloaded file and click ‘Run’, Gears will then be installed automatically. The user’s browser must then be restarted so that it can recognise Gears. The user will be prompted to do so. Once the browser has been restarted the user is directed back to the login page and in another tab the Gears installation page where an installation conformation message is shown (Figure 18).Figure 18: Gears successfully installedNow that Gears has been successfully installed in the user’s browser, the user can attempt to login to the system.7.3Retrieving a user’s locationThe two main challenges faced when implementing my application were:How to retrieve a user’s locationHow to validate a user’s locationHow the Geolocation API was implemented to retrieve a user’s location is now looked at in detail. Code snippets are provided along with an explanation of how the code is used. In order to manipulate the Gears Geolocation API, the ‘gear_init.js’ needed to be downloaded from . This file is needed to initialise the Gears library. The library then needed to be included in my application (Figure 19). You can see the gears_init.js code in Appendix B: gears_init.js.<script type="text/javascript" src="gears_init.js"></script>Figure 19: gears_init library Some global variables were then defined see Figure 20.var geo = google.gears.factory.create("beta.geolocation");var locationFound = false;var lat=0;var lon=0;var addr="";Figure 20: Global variablesgeoholds a reference to a newly created Geolocation objectlocationFoundset to true once a location is foundlatholds the latitude coordinateslonholds the latitude coordinatesaddrholds a string of the country When finding a location using Gears, two functions are needed. One that will be called if a location can be found; the other called if there was an error. The updatePosition function is called when a location is successfully found (Figure 21).function updatePosition(position) { lat = position.latitude; lon = position.longitude; if ( position.gearsAddress.country != null ) addr = position.gearsAddress.country; locationFound = true; if (locationFound) {{ alert('You are trying to access this account from: ' + addr); loginForm.text2.focus();}}}Figure 21: updatePosition functionThe lat and lon variables are set to the found latitude and longitude positions. The addr variable is then set using the country that was found. In a case that a country cannot be found it is first checked to see if it is null, locationFound is then set to true. You can also see from Figure 21 how the country that is returned in the addr variable is used to prompt the user of his/her location.In the event that a user’s location could not be found, an error message is shown. Figure 22 dipicts the handleError function that is invoked when an error occurs.function handleError(positionError) { alert("Failed to get location");}Figure 22: handleError functionThe getCurrentPosition function (Figure 23) is called to actually find the users location. The updatePosition (Figure 21) and handleError (Figure 22) functions above are supplied as callbacks. The third parameter in the getCurrentPosition function is a PositionOptions (Figure 24) object. Here a high accuracy request (enableHighAccuracy: true) has been made and requested that the country be found (gearsRequestAddress: true), supplies the information required to populate the addr variable.geo.getCurrentPosition(updatePosition, handleError,{ enableHighAccuracy: true,gearsRequestAddress: true });Figure 23: getCurrentPosition functionAttributeTypeDescriptionenableHighAccuracyreadwrite boolOptional, requests the most accurate possible results. This may result in slower response times or increased battery consumption. Also, there is no guarantee that the device will be able to provide more accurate results than if this flag is not specified. The default value is false.gearsRequestAddressreadwrite boolOptional, requests reverse geocoded address information as part of the position data. Reverse geocoding is not performed if this flag is not specified or if it is set to false.Figure 24: PositionOptions class7.4Validating a user’s locationFigure 25 depicts the checkCountry() function. The user’s location is validated using this function. The addr variable is compared against three other countries. These countries were outlined earlier in the report as countries with a high online fraud rate and therefore used in my application. If a user from any of these countries tries to login to the account access is denied. Any other country is granted access. In the event that the user’s location is not retrieved, the user is denied access. This is done be checking to see if the addr variable is null.function checkCountry(){ if (addr == "Russia"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == "Nigeria"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == "China"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == null){ alert('ACCESS DENIED!'); invalid();} else{validate(loginForm.text2.value,"name",loginForm.text1.value,"pass");}}Figure 25: checkCountry function If each comparison is proved false then the validate function is called. This is to ensure that the user’s login details are not processed until the location has been verified. The username is set to ‘name’ and the password set to ‘pass’. These values are then checked using the validate function depicted in Figure 26.function validate(text1,text2,text3,text4){ if (text1==text2 && text3==text4) window.location = 'success.html'; else { alert('Username or Password incorrect!'); invalid(); }}Figure 26: Validate login detailsThe values entered in each text field are compared to the value of the username and password set to access the account. At this point the user’s location has been verified. The success.html document is therefore loaded on successful login or an error message displayed to the user. Function invalid is called if an incorrect login is entered Figure 27. This clears the username and password fields after an unsuccessful login and sets the focus to the username text field for the user to try again.function invalid(){ loginForm.text2.value = ""; loginForm.text1.value = ""; loginForm.text2.focus();}Figure 27: Function invalid()The invalid function is also called when an attempt to access the account is made from an invalid location or in a case when no location can be found. This is to make the login interface as user friendly as possible.8TestingTesting is the process of executing a program with the intent of finding errors. The software testing process has two distinct goals:To demonstrate to the developer that the software meets its requirements. For custom software, this means that there should be at least one test for every requirement in the user and system requirements documents.To discover faults or defects in the software where the behaviour of the software is incorrect, undesirable or does not conform to its specification. Defect testing is concerned with rooting out all kinds of undesirable system behaviour, such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption.The first goal leads to validation testing, where you expect the system to perform correctly using a given set of test cases that reflects the system’s expected use. The second goal leads to defect testing, where the test cases are designed to expose defects. The test cases can be deliberately obscure and need not reflect how the system is normally used. For validation testing, a successful test is one where the system performs correctly. For defect testing, a successful test is one that exposes a defect that causes the system to perform incorrectly.Testing cannot demonstrate that the software is free of defects or that it will behave as specified in every circumstance. It is always possible that a test that you have overlooked could discover further problems with the system. As Edsger Dijkstra, a leading early figure in the development of software engineering, eloquently stated (Dijkstra, et al., 1972), ‘Testing can only show the presence of errors, not their absence’. Figure 26 depicts a general model of the testing process.Design test casesPrepare test dataRun program with test dataCompare results to test casesTest casesTest reportsTest resultsTest dataFigure 28: A model of the software testing process 8.1Test casesTest cases have been developed and executed against the application in order to ensure proper functionality is achieved when a user attempts to access the account. The test cases can be viewed in Appendix E: Test cases. Each of the test cases have been designed to test the requirements specified in chapter five and highlight any errors/defects that have not yet been discovered. 8.2Stages of testingThere are many different stages involved when it comes to testing a system. The application will be tested in each of the following stages:Component testingIntegration testingSystem testingRequirements testingOther applied testing stages such as ‘release testing’ for example will not be focused on as my system at this stage is not intended to be distributed to a customer. Each of the testing stages being applied to my system should demonstrate the overall functionality of the system and highlight any problems that need to be addressed. Each testing stage will be explained and my system and its components tested accordingly. Mozilla Firefox and Internet Explorer respectively are both used to carry out all tests on the system.8.3Component testingComponent testing (sometimes called unit testing) is the process of testing individual components in the system. This is a defect testing process so its goal is to expose faults in these components. There are many different types of component that may be tested:Individual functions or methods within an object.Object classes that have several attributes and posite components made up of several different objects or functions. These composite components have a defined interface that is used to access their functionality.Individual functions or methods are the simplest type of component and tests are a set of calls to these routines with different parameters. The retrieve location component needed to be tested as other components are dependent on its functionality. Testing this component would demonstrate that a user’s real world location could be retrieved successfully. It was important the functionality of this component was tested to ensure that it could be successfully integrated into my application. A location needs to be retrieved first, before it can be blocked.8.3.1Retrieve location testingTo test if the real world location of a user can be identified, the retrieve location component was invoked using the getCurrentPosition and updatePosition functions and a marker displaying the location on the map was the result. The country stored within the ‘addr’ variable was displayed with the latitude and longitude coordinates of the location in an info bubble to illustrate the accuracy of the information retrieved (Figure 29).Figure 29: Retrieve location testAs the latitude and longitude coordinates are retrieved by the Geolocation API, the exact location can be pinpointed on the map. The country is displayed to illustrate that it can be used to check a location against another; this will become apparent in the integration testing. Figure 30 shows the code use to create the map interface. google.load("maps", "2.x");google.setOnLoadCallback(initialiseMap);function initialiseMap(){ map = new GMap2(document.getElementById("map")); map.addMapType(G_PHYSICAL_MAP); map.addControl(new GLargeMapControl());mapLoaded = true; createMarker();}function createMarker() { if (mapLoaded && locationFound){var latlng = new GLatLng(lat,lon);var zoom = 7;map.setCenter(latlng, zoom);var marker = new GMarker(latlng);marker.value = 1;GEvent.addListener(marker, "mouseover", function() {var myHtml = "You are in " + addr + "<br/>" +"(latitude :" + lat + ", longitude:" + lon +")";map.openInfoWindowHtml(latlng, myHtml);});map.addOverlay(marker);}Figure 30: Map interfaceThe information being retrieved now proved accurate. The country being retrieved was now displayed in an alert box and tested.8.4Integration testingThe process of system integrating involves building a system from its components and testing the resultant system for problems that arise from component interactions. The components that are integrated may be off-the-shelf components, reusable components that have been adapted for a particular system or newly developed components. For many large systems, all three types of components are likely to be used. Integration testing checks that these components actually work together are called correctly and transfer the right data at the right time across their interfaces. System integration involves identifying clusters of components that deliver some system functionality and integrating these by adding code that makes them work together. The retrieve location component now demonstrated that it could retrieve a location. It is now integrated with the country validation component for further testing. The checkCountry() function (Figure 31) compares the value (country) returned in the addr variable against four other values. In the checkCountry() function, the addr variable is checked against three countries (Russia, Nigeria and China). It is also checked to see if it holds no value (null) in the event of a location not being retrieved. In order to test that these countries are indeed being compared, each country is replaced with the “United Kingdom” throughout each if statement (Figure 31) one at a time. This will illustrate that the addr variable is being compared each time. if (addr == "Russia"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == "United Kingdom"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == "China"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == null){ alert('ACCESS DENIED!'); invalid();} else{validate(loginForm.text2.value,"name",loginForm.text1.value,"pass");}Figure 31: checkCountry() testOn each occasion the user was denied access to the account and prompted the “Access to this account is not permitted from: United Kingdom” error message. This now demonstrated that each country stated was being compared against the country stored within the addr variable. 8.5System testingSystem testing involves integrating two or more components that implement system functions or features and then testing this integrated system. System testing is concerned with testing the entire system. Generally, the priority in integration testing is to validate that the system meets its requirements. However, in practice, there is some validation testing and some defect testing during both of these processes.A location is now able to be retrieved and validated. Both components are now combined and the functionality tested through the submit button. The system is now tested as a whole. Similar tests are carried out as in the integration testing only now to see if the two components work together when a user attempts to login.A former student and friend of mine in Dublin kindly tested the system for me. He tried accessing the account for me from his location in Dublin and reported back his findings. Unfortunately the system did not find his location so the “Failed to get location” error message was displayed. However as no location was found, access to the account was still denied. This compiled with the requirement laid out in chapter five and tested the error handling functions of the system.My colleague was trying to access the account from a laptop with a wireless connection. The following could explain why the location was not retrieved:The location or WiFi access point is not yet in Google's WiFi location database. Specific coverage varies by location and isn't complete. We're always working to improve both coverage and accuracy over time as usage of our location-based services continues to grow.8.6Requirements testingA general principle of requirements engineering is that requirements should be testable. That is, the requirement should be written in such a way that a test can be designed so that an observer can check that the requirement has been satisfied. Requirements-based testing, therefore, is a systematic approach to test case design where you consider each requirement and derive a set of tests for it. Requirements-based testing is validation rather than defect testing; you are trying to demonstrate that the system has properly implemented its requirements. At this stage in the testing process most of the requirements to do with the general functionality of the system that were laid out in chapter five, have succumb to some form of testing. Retrieving a user’s location has been successful implemented and tested so that a user’s location is verified before a user can login. Requirements that have not yet succumbed to testing are tested in this section. It was specified in the requirements that the user would be prompted to install Gears if not already present in the browser. How this was implemented is explained in chapter seven. An html document called ‘testInstall’ is created with the Gears detection code (chapter 7, Figure 16) stored within the document. The document is then opened in two different web browsers, Mozilla Firefox and Internet Explorer. In both cases the browser is directed to the Gears install page. The detection code is added to the system.In the requirements it is also stated that the user would have to login with a username and password and that these details would only be processed when the location returned valid. Valid and invalid login details are entered into the login interface to test how secure the interface is. Combinations of valid and invalid details are also entered. Incorrect details are not processed and the interface proves secure.Not much time was spent in the testing of the login interface as this is not the main aspect of the system and was not a major concern in regards to the overall functionality of the system. A simple login interface was all that was required and was therefore tested with such in mind. However such requirements have been successfully meet.8.7Findings of testingTesting the retrieve location component of the application demonstrated that the real world location of a user can be identified using Gears. By using a map to display the location retrieved by Gears, you are able to see the accuracy of the location retrieved. As the latitude and longitude of a user’s location is retrieved, it is possible to retrieve the user’s exact address if required. However, a country is of a larger scale and even if a users exact location is not retrieved it is more than likely the country will be and therefore more practical to validate a country. The application could if necessary be used to check a location based on a certain region within a country if necessary. By testing the system in the south of Ireland, it became apparent that further testing would be required in foreign locations. When the system was tested in Dublin it proved reliable and did not permit access as a location could not be found. Testing the system in various global locations is obviously not very practical. A simulator could for example be used to perform further testing on the system in the future before integrating the technology in other web applications. Testing the login interface proved that login details were not being processed until a location had been found and validated. This was important as the purpose of the system is to block access to accounts from foreign locations were a user’s details may have been compromised. 9EvaluationThe system has now been designed, implemented and fully tested. It can now be evaluated. How the system has met its functional and non-functional requirements (laid out in chapter five) will be investigated as well as how well these requirements were met.9.1Evaluation of Functional RequirementsThe functional requirements of the system are stated in chapter five. These requirements are now compared to the functionality the system has now.Functional RequirementsLevel of AchievementThe application must have a simple yet functional graphical user interface (GUI).SuccessAllow users to login with a username and passwordSuccessPrompt the user to install Gears if not currently installed in the browserSuccessCheck the location of the user before verifying login details.SuccessProcess login if user location is valid.SuccessDeny access if login is incorrect.SuccessDeny login if user location is invalid, not process login details.SuccessFigure 32: Evaluation of Functional requirementsAs you can see from Figure 32 each of the functional requirements were met in the implementation of the system. Access to the system can be blocked depending on a user’s location and granted otherwise. Login detail’s are processed correctly and only after the location has been verified. A simple GUI was implemented to show the functionality of the system.9.2Evaluation of Non-Functional RequirementsThe non-functional requirements that were also stated in chapter five will now be assessed. Figure 33 show’s if each of the requirements were met. Functional RequirementsLevel of AchievementSecuritySuccessPerformanceSuccessUsabilitySuccessRobustnessSuccessPortabilityFailNot fully testedPrivacySuccessReliabilitySuccessFigure 33: Evaluation of Non-Functional RequirementsSecurity was the most important non-functional requirement of this system. A user’s location was to be retrieved and then used as an extra form of security. Security was successfully met as the system is able to identify a user’s real world position and act accordingly. Usernames and passwords are processed properly. These login details are not to act as a form of security themselves, but to show how a user’s location can be checked as a precautionary measure before processing such information. As the Gears API’s are an add-on to the user’s browser, a location can quickly be retrieved as information in the user’s browser itself is used to provide the location information. This requirement was therefore successfully met.Usability highlighted how Gears needed to be installed in a browser for the application to function. This was met by directing the user to installation page and providing the necessary prompts to help the user understand what was happening and to help with the installation. This was deemed a success. However, the installation process could be seen a hindrance to some users.The system met its robustness requirement by be able to deal with false login information and deal with users logging in from a location that the system could not retrieve. A ‘back’ button was even added to the success page viewed after a successful login. This was to allow easy transaction between pages when testing the system.The system was tested on two popular yet different web browsers to show that it was functional on both. This was the case however the system would need to be tested across all browsers to ensure portability. It was also tested on the Windows XP and 7 operating system’s respectively. Again with success, other operating systems such a Snow Leopard would need to be tested to ensure functionality on a Mac for example.Privacy was met by notifying the user that their location was going to be retrieved by the system. A link to the privacy policy was also provided in this notification. The system was proved reliable in testing. The functionality of the system however is dependent on the Gears Geolocation API’s. If any errors or bugs arise in these API’s the system would not prove very reliable. The system can at times prove unreliable to wireless users in certain cases as highlighted in the testing chapter. The system was reliable in most testing cases and therefore deemed a success. 9.3Findings of evaluation The system has now been evaluated and deemed a success. The system adheres to the requirements specified in chapter five and functions according to the design specified in chapter six. Gears has been integrated into a web application and used to demonstrate the benefits the plug-in can offer a web application such as an online banking account.10Conclusion The aim of this project was to integrate Gears into a web application and use its Geolocation API to determine a real world location. This location information was then to be taken and used to demonstrate how such information could be used to benefit a financial institution. An online banking account was selected as a possible application that could benefit from such information. A demo was then to be created that was able to determine real world locations and demonstrate the advantages of such information.In order to build such an application, the motivation to do so needed to be established and the need for such an application investigated. Various online banking accounts, the security that is available when using such accounts and the cases of fraud associate with them were therefore researched. During this research it became apparent that even with banks providing the best security they could (some more than others), online banking fraud was still a concern all over the world. Peoples bank accounts fall victim to various types of fraud. During my research it became apparent that the majority of cases were as a result of the account holder and not the banks themselves. Account holders where being manipulated in various ways to expose their account details.Geolocation became clear as a means of providing added security. Online banking fraud takes place all over the globe, just because your account is a UK account doesn’t necessarily mean that it cannot be accessed from foreign locations. Some countries are notorious for online fraud. Gears is a collection of API’s that can be downloaded and installed in your browser. These API’s can be used to perform various tasks, one of which is Geolocation. Gears was now to be used to create my application. The software is free, easy to download and is compatible across all browsers.In order to demonstrate how Gears could be integrated into an online banking account and used as a form of added security, a simple yet functional login screen was designed and implemented. The application was developed to block locations with high levels of online fraud. This was to demonstrate how access to such accounts could be blocked even with the correct account details. Many accounts are hacked by fraudsters abroad by obtaining account details. This therefore demonstrated that these details could become meaningless to the fraudster as even though they are correct, access would not be granted due to their location.After implementing and testing my system, it was clear why geolocation is becoming a big part of browsing online today. Advertising for example is using geolocation to change the way in which they advertise and how they reach out to their respective markets. My application demonstrates how geolocation can be used to add security to sites such as an online banking account, yet only really scratches the surface.If my application was to be integrated in online accounts Gears can do the job although it is not the most practical solution. Gears needs to be installed in the browser before it can be used, because of this the user would be forced go through the install process each time they access their account from a different computer. The install process can become tiring after a while as the user is also receiving prompts and having to restart their browser each time they are required to install the plug-in. With the introduction of HTML5 however, Gears can be implemented as well as other browser plug-ins without the need to install. HTML5 is the proposed next standard for HTML 4.01, XHTML 1.0 and DOM Level 2 HTML. Its aim is to reduce the number of plug-ins needed to be installed by users such as Gears. HTML5 therefore comes with Gears pre-installed across all browsers and its functions therefore called without having to go through the install process each time. This would prove to be of great advantage when implementing an application like the one developed throughout this project.There are websites that can provide the type of security my application demonstrates, this however comes at a price. With Gears available in all major browsers thanks to HTML5, web developers can therefore implement Gears as a form of security for free and for a variety of applications and reasons. If this project were to be taken to the next level, instead of blocking access to an account from a certain location, the user could be asked to provide more security details or answer custom questions defined by the user i.e. mother’s maiden name. If a user was in a blocked country on holiday or business, they could access their account without being blocked.To conclude, geolocation can be a very powerful tool. When implemented as a form of security, many web applications can benefit from geolocation and indeed are. With mobile devices becoming more sophisticated and used to carry out tasks that would normally have been done on a desk/laptop such as banking online geolocation can only help improve how we surf the web and how securely we do so. Appendix A: application.jsif (!window.google || !google.gears) { location.href = ""+ "&message=Welcome to Google Gear Installation";}var geo = google.gears.factory.create("beta.geolocation");var locationFound = false;var lat=0;var lon=0;var addr="";function updatePosition(position) { lat = position.latitude; lon = position.longitude; if ( position.gearsAddress.country != null ) addr = position.gearsAddress.country; locationFound = true; if (locationFound) {{ alert('You are trying to access this account from: ' + addr); loginForm.text2.focus();}}}function checkCountry(){ if (addr == "Russia"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == "Nigeria"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == "China"){ alert('Access to this account is not permitted from: ' + addr); invalid();} else if (addr == null){ alert('ACCESS DENIED!'); invalid();} else{validate(loginForm.text2.value,"name",loginForm.text1.value,"pass");}}function handleError(positionError) { alert("Failed to get location");}function validate(text1,text2,text3,text4){ if (text1==text2 && text3==text4) window.location = 'success.html'; else { alert('Username or Password incorrect!'); invalid(); }}function invalid(){ loginForm.text2.value = ""; loginForm.text1.value = ""; loginForm.text2.focus();}geo.getCurrentPosition(updatePosition, handleError,{ enableHighAccuracy: true,gearsRequestAddress: true });Appendix B: gears_init.js// Copyright 2007, Google Inc.//// Redistribution and use in source and binary forms, with or without// modification, are permitted provided that the following conditions are met://// 1. Redistributions of source code must retain the above copyright notice,// this list of conditions and the following disclaimer.// 2. Redistributions in binary form must reproduce the above copyright notice,// this list of conditions and the following disclaimer in the documentation// and/or other materials provided with the distribution.// 3. Neither the name of Google Inc. nor the names of its contributors may be// used to endorse or promote products derived from this software without// specific prior written permission.//// THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED// WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO// EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,// PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;// OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,// WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR// OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF// ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.//// Sets up google.gears.*, which is *the only* supported way to access Gears.//// Circumvent this file at your own risk!//// In the future, Gears may automatically define google.gears.* without this// file. Gears may use these objects to transparently fix bugs and compatibility// issues. Applications that use the code below will continue to work seamlessly// when that happens.(function() { // We are already defined. Hooray! if (window.google && google.gears) { return; } var factory = null; // Firefox if (typeof GearsFactory != 'undefined') { factory = new GearsFactory(); } else { // IE try { factory = new ActiveXObject('Gears.Factory'); // privateSetGlobalObject is only required and supported on IE Mobile on // WinCE. if (factory.getBuildInfo().indexOf('ie_mobile') != -1) { factory.privateSetGlobalObject(this); } } catch (e) { // Safari if ((typeof navigator.mimeTypes != 'undefined') && navigator.mimeTypes["application/x-googlegears"]) { factory = document.createElement("object"); factory.style.display = "none"; factory.width = 0; factory.height = 0; factory.type = "application/x-googlegears"; document.documentElement.appendChild(factory); } } } // *Do not* define any objects if Gears is not installed. This mimics the // behavior of Gears defining the objects in the future. if (!factory) { return; } // Now set up the objects, being careful not to overwrite anything. // // Note: In Internet Explorer for Windows Mobile, you can't add properties to // the window object. However, global objects are automatically added as // properties of the window object in all browsers. if (!window.google) { google = {}; } if (!google.gears) { google.gears = {factory: factory}; }})();Appendix C: index.html<html><head><title>Online Banking Demo</title><script type="text/javascript" src="gears_init.js"></script><script type="text/javascript" src="application.js"></script></head><body><br><br><br><br><br><div align ="center"><font size="2" face="Arial"><font color="green" size="4">Login</font></div><form name = loginForm><p align="center"><b>Username:</b> <input type="text" name="text2" size="20"><br><br> <b>Password: </b> <input type="password" name="text1" size="20"></br></br></p><p align="center"> <input type="button" name="logIn" value="Submit" onclick= "checkCountry()"></p></form></body></html>Appendix D: success.html<html><head><title>Success</title></head><body><br><br><br><br><br><br><div align ="center"><font size="5" face="Arial"><font color="green" size="10">Login Successful!</font><p><br><input type="button" name="back" value="<< Back" onclick="window.location = 'index.html';"><p></div></body></html>Appendix E: Test casesReferencesProject on E-Banking on phishing release: Financial Fraud Action UK announces latest fraud figures on Going Global with Geolocation banking definition banking survey from Which? product information definition phishing email from bank safe online definition explained release: Financial Fraud Action UK announces latest fraud figures risk countries information regarding Nigeria article from The Times regarding the Clampi virus definition of European IP address from an article on Going Global with Geolocation location system definition positioning system (GPS) definition from Avangate on improving e-commerce security definition the Gears Geolocation API functions the geolocation network protocol functions shot of the Geolocation API in use shot of ’s radar application requirements definition requirements definition design definition (1979). The Art of Software Testing ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.