Privacy Preservation Framework Interface

4.2.1 Privacy Preservation Framework Interface

For all data acquisition requirements, the GAMBAS middleware ensures that the permissions are granted in accordance with the privacy settings of the middleware. The privacy settings in the

GAMBAS middleware are handled by the PRF. The main purpose of the PRF in the GAMBAS middleware is to allow a controlled access to the personal and private information about the user. Since the potential services targeted in GAMBAS require service providers to access context information of the user, it is of utmost importance that only the relevant information is shared with the right resolution to the right service provider. As already specified, the context information is gathered and processed through the DQF in the personal mobile device of a user, therefore, the PRF and the DQF must communicate so that the context data is exported in a privacy preserving manner.

As every export of user’s context information is filtered based on the privacy policy of the user, for every request of data by the service provider, the DQF checks it with the privacy framework. If the PRF allows the data to be sent, only then the users’ context information is exported. The PRF and the DQF communicate this information check through control interfaces provided by the PRF. Specifically, PRF provides different methods that allow the DQF to check if a certain data type is allowed to be detected. The DQF must call these methods before creating a recognition stack for detecting any kind of data or context. Based on the results from these methods the DQF detects the context data and subsequently sends it to the service providers.

4.2.1.1 Privacy Feature Analysis

In order to allow acquisition and subsequent export of user’s context information, the GAMBAS middleware ensures that the context recognition applications can gather and export only the allowed context features. In order to achieve this, the data DQF checks for permissions with the privacy preserving framework whenever a new application is started.

When a new application starts the GAMBAS SDK sends a start request to either of the subcomponents of the acquisition framework. These subcomponents (component system or the activation system) analyses the feature requirements of the application and then checks with the PRF whether the desired features are allowed to be gathered. The PRF based on the privacy settings set by the user informs the acquisition framework whether the requested features are allowed to be gathered or not. If the requested features are allowed then the context recognition application starts gathering context information and if the requested features are not allowed then the application shows a message to the user indicating that the application cannot be started.

In case when user sets new privacy settings the core service indicates this change to the acquisition framework which again checks permissions with the privacy framework. If an already running application does not adhere to the new privacy settings then the application is shut down immediately. Figure 18 shows how the requests for starting and stopping of configurations by the SDK are handled by DQF and PRF.

The current list of privacy features that a user can set includes features related to the acquisition of sensing data such as audio sensing, location sensing, motion sensing, ambient sensing and features related to the communication such as enabling of remote gateway communication, enabling of Wi‐Fi and Bluetooth as communication technologies etc.

Figure 18 – DFQ Interaction with PRF

4.2.1.2 Application Example

An example of sample application in which the interaction between the DQF and PRF is required could be an audio sensing application which takes voice commands as input and performs certain actions such as opening a webpage, opening a certain application etc. If such an application uses the GAMBAS middleware, then upon its startup the GAMBAS SDK would start the relevant subcomponent of the DQF. The subcomponent (either component system or the activation system) would then check the privacy settings with the PRF. In this example application the subcomponent will check with the PRF whether the permission to use microphone is allowed or not. If the use of microphone is permitted then the DQF will start the audio sensing for the application and if the use of microphone is not permitted then the application will display a message to the user that the application cannot be started due to lack of permissions. In case the PRF allows use of microphone and the application starts but at some point the user change the privacy settings then the core service will indicate a change of settings to the DQF which will again checks with the PRF whether the use of microphone is still allowed and if in the new privacy settings the use of microphone is not allowed then the DQF will stop the application immediately.