D11.2: Mobility and LBS

Title: THE USE CASES

The Use Cases

Due to complexity of the communicational relationships and the number of different LBS offered on the market, the number of possible scenarios is manifold. Therefore three scenarios were chosen to show the various impacts with regard to the identity of a person. These are especially scenarios with a data subject or with a data object that is closely and directly linked to a data subject. The three scenarios selected are: 

1. Scenario 1: Using LBS within the private communicational context in cases of emergency (emergency calls and emergency location) 

2. Scenario 2: Using a friend around service within the private communicational context 

3. Scenario 3: Using LBS for tracking in the communicational working context 

Scenario 1: Location in case of a medical emergency

In this scenario, Alice uses a mobile phone together with a special medical emergency service. In case she uses the emergency button on the phone, her GPS location data is automatically transferred together with her call to a specific rescue control centre. The rescue control centre is able to send medical professionals (if needed with special equipment, e.g. if Alice’s location is somewhere in the high mountains) to the location where Alice submitted the emergency call (pull service). Except for emergency calls, her location data is not collected, nor transferred or stored by the service provider.

In this scenario, data processed and stored in emergency cases are being deleted by the service provider after the end of one accounting period of the medical professionals and rescue services involved (in general one year). So her location data is (in general) not available for profiling purposes. In the chosen scenario, the rescue control centre performs its service in the European Union. Accordingly, it complies with data protection legislation, such as European Directive 95/46/EC, and implements a high level of IT security related technologies. 

Figure : Workflow in the medical emergency scenario.

At the same time, Alice is data subject and user, as she transfers her own location data in a special situation for a special purpose to a special service provider (in this case the rescue control centre). The workflow to be used in cases of emergency is strictly defined and agreed by all participants in the communication, the communicational policies of Alice and the LBS provider match in this example. This communicational context, which is more complex compared to the examples discussed in D11.1, raises questions of data protection and multilateral security, as not all of the personal data remains under Alice’s control. In this example, the rescue control centre is aware of these issues and takes care of them by applying appropriate measures for data protection and IT security. The use of LBS in cases of emergency has no significant impact on the identity of Alice when carried out in the described way. 

Figure : Identity of Alice in the medical emergency scenario.

Scenario 2: Using a friend finder service

In this scenario Alice uses a so-called friend finder or “buddy alert” service. All persons for which the use of the location service is possible, need to be client of the same service provider. In addition, they have to edit service preferences, allowing each other to exchange location information. Using location data from various telecommunication providers, the (pull) service informs a requesting user via SMS, how far away a certain person is from the user’s current location. In return, the person whose location was inquired gets a message informing it about the distance to the requester (push service). If both are close enough and interested, they can get into contact via mobile phone to arrange a meeting.

Alice is registered for this service. Via SMS or web front end she administers a list with her friends on a central server of the LBS provider. Her boyfriend Bob is on that list as well. Bob in turn is client of the LBS provider and has Alice in his list of friends as well. So the location service can be used by both.

Figure : Workflow in the friends around scenario.

In this scenario workflows and the communicational policy are predefined by the LBS provider. The users (data user and data subjects) accept and agreed by signing the contract and by editing a profile (as described above). In this example there is a general consent among the users to use the service. The person whose location is requested is subject of a push service and has no opportunity to declare an individual consent. In any case, location data is generated and processed.  

In order to protect the private sphere of the user, the location data in this scenario is blurred. This is done by not transmitting the exact location of the users but only transmitting information on the distance between the users. This blurring of precise location data is part of the communicational and privacy policy of the LBS provider. 

There is no need to store any detailed or blurred location data for accounting purposes after they are submitted to the users. In this scenario, the LBS provider does not do so, as laid out in his data protection policy. Therefore, he follows the data minimisation principle stated in the European Directive 95/46/EC. Therefore location data generated by this service cannot be easily used for profiling purposes. 

Compared to the Scenario 1, the impact on the identity of the users of the LBS can be more severe, especially in cases where somebody else is initiating the service. For example when Bob has scheduled a business trip to the capital and on that date and time the service locates him at a nearby beach resort, this reduction of his private sphere can have major impact. As this service can be initiated by all members of a group of trust (in this case Alice and Bob), this reduction of the private sphere can happen to all of them, as their control over the workflow is limited. A process asking for individual consent before any tracing transaction would be more privacy respecting, but probably not practical. In addition this service can cause severe problems when the link between a user and “his” tracked device is not robust. 

Figure : Identity of Alice in the friend around scenario.

Scenario 3: Tracking in the working context

In this scenario, a mobile phone with GPS locator is installed in a transportation vehicle (e.g. a lorry) to track it on its way to different destinations in Europe. Alice is the driver of that lorry and thus has highly flexible working hours. From a central server, the mobile phone is called regularly to submit the current location of the vehicle (pull service from the perspective of the data user, Alice’s employer). The submitted location data are stored in a central database. This data is used to track and trace the lorry. In case of significant discrepancies, compared to the route plan, the employer calls Alice, asks for the reason and discusses with her modifications of the route plan. The location data and additional information from Alice, such as data concerning the traffic situation, is used for further planning of the routing. (In addition the location information is used to monitor Alice in her function as driver of the lorry – at least in a general sense.)

Figure : Workflow in the lorry tracking scenario.

In this scenario, the employer of Alice is LBS provider and user, while Alice is a linked data subject. She is subject to workflows and communicational policies defined by her employer. In difference to scenarios 2 and 3 discussed in chapter 3 of FIDIS deliverable D11.1, her location data is generated, stored and analysed by her employer. Consequently, he or she has complete control over her location data, which is monitored by this service. 

This kind of profiling leads to a reduced private sphere (at least when working and being on business trips) and reduces her autonomy and flexibility when doing her job. In addition Alice’s location data may be attractive for third parties and thus has to be subject to the application of strict data protection rules and a high level of IT security. The application of data protection and IT security clearly is the responsibility of Alice’s employer.  

In this example the location data of Alice is being used to supervise her while she is doing her job. In such situation consent for processing and storage of her location data cannot easily be base on a free will as required by the European Directive 95/46/EC. In any case, transparency concerning used personal data, the way of processing, and the use of the results by the employer has to be documented and agreed on – for example as part of the employment contract.  

In some European countries this is also subject to approval by a workers’ council, which is (for example in Germany) stated and regulated by a Works Council Constitution Act.  

Figure : Identity of Alice in the mobile working scenario.