Environnement de simulation

Nous avons implémenté le mécanisme de délégation proposé en Java, et nous avons mesuré la performance du mécanisme sur des terminaux stationnaires et mobiles. En outre, nous avons implémenté un serveur LBS en PHP, basé sur les services de géoloca- lisation de Google (Google Places API), qui collecte et stocke localement les requêtes des utilisateurs avant de renvoyer les résultats reçus de l’API. Les requêtes stockées sont utilisées pour évaluer le niveau de confidentialité garantie par Deloc.

De même, nous avons implémenté le serveur du répertoire inconscient, pour fournir les données de dispositifs actifs. Les deux serveurs ont été exécutés sur une machine équipée d’un processeur Intel Core i7-3960X 3.30Ghz et 32 Go de mémoire vive. Nous avons également utilisé un ensemble de données de BrightKite [20] qui contient 58228 nœuds avec 4491143 (≈ 4,5M) coordonnées géographiques. Chaque tuple est composé de l’identifiant de l’utilisateur, sa position et de l’horodatage respectif.

Comme notre plateforme fonctionne dans le cas de requêtes en temps réel, nous avons mis en place un programme de simulation qui imite le comportement des utili- sateurs. Nous avons d’abord préparé le nouveau jeu de données en limitant l’ensemble de données original aux nœuds ayant plus de 70 tuples, de façon à ce que notre nouvel ensemble de données B soit composé de 9963 nœuds avec 3956113 (≈ 4M) coordonnées géographiques.

Étant donné que l’ensemble de données utilisé contient des données réelles des utili- sateurs, les coordonnées partagées ne sont pas uniques et peuvent être dupliquées ; un utilisateur peut émettre une requête plusieurs fois à partir de la même position. Par ailleurs, et pour imiter le contenu d’un dispositif réel, nous avons généré un répertoire pour chaque nœud à partir d’un ensemble aléatoire de données.

Le répertoire contient l’ensemble des coordonnées géographiques respectives échan- tillonnées à partir de l’ensemble B, une liste de contacts générée contenant 50 à 200 entrées aléatoires, et les données du propriétaire du dispositif généré (par ex. nom, cour-

rier électronique, identifiant unique). Les données contenues dans le dossier sont utili- sées pour calculer une empreinte unique qui reflète le cas des applications actuelles où l’empreinte digitale est utilisée pour identifier un dispositif de manière unique.

Dans notre cas, les informations utilisées pour les empreintes digitales comprennent le nom complet du propriétaire, le courrier électronique (c’est-à-dire compte du proprié- taire), le numéro de téléphone, l’adresse MAC de la puce WiFi et la liste de contacts. À l’exception de la liste de contacts, toutes les informations ont été stockées dans un seul fichier JSON dans le répertoire généré. Le listing 4.1 illustre un exemple d’un fi- chier JSON contenant des données générées aléatoirement pour imiter leur équivalent dans un dispositif réel. Il est important de mentionner ici que les applications du monde réel peuvent recueillir des données plus précises sur un utilisateur (par ex. date d’anni- versaire, contenu multimédia, image de profil), notre sélection est basée sur des infor- mations minimales qui peuvent fournir, une fois combinées, une empreinte numérique unique pour chaque utilisateur.

Le programme de simulation exécute pour chaque répertoire généré une unité d’exé- cution (Thread) indépendante qui l’enregistre dans le serveur de répertoire inconscient en tant qu’un dispositif. Chaque unité d’exécution exécute un ensemble de requêtes géo- dépendantes (1 à 20 requêtes) séparées par des périodes de temps aléatoires (1 à 15 mi- nutes). À chaque requête, l’unité d’exécution recherche des POI autour des coordonnées échantillonnées à partir des coordonnées de l’ensemble B.

Listing 4.1 – Exemple des données générées pour simuler un dispositif

1 {

2 "uid": "5620fbfd1f3c",

3 "sex": "M",

4 "phone": "(758)163-7968",

5 "mac": "99:ef:27:e3:55:06",

6 "owner": "Joshua Hurst",

7 "email": "ronald52@example.org"

L’unité d’exécution qui émet la requête la transmet à d’autres unités en récupérant la liste de celles disponibles depuis le répertoire inconscient, jusqu’à ce que l’unité d’exé- cution finale la reçoive et interroge le serveur. Ainsi, la requête reçue par ce dernier contient l’identifiant unique de l’unité d’exécution finale, son empreinte digitale et les coordonnées géographiques et la requête géodépendante de l’émetteur. En conséquence, la procédure de simulation a permis de fournir 51783 requêtes géodépendantes représen- tant la connaissance du LBS concernant le trafic du réseau de la foule de délégation.

Notons ici que la sélection des coordonnées géographiques à partir de l’ensemble B dépend essentiellement de l’horodatage extrait du fichier original. À chaque fois qu’une unité d’exécution sélectionne une nouvelle position, elle sélectionne celui avec l’horo- datage le plus proche de la demande précédente. Cette sélection permet une simulation plus réaliste où les positions dépendent du temps. De même, après la sélection, la posi- tion jumelle unique est calculée pour être utilisée à la place des coordonnées originales. Nous avons conduit une simulation supplémentaire qui vise à valider les facteurs d’efficience en utilisant l’émulateur des appareils Android Nox App Player2 . Chaque dispositif émulé a été configuré pour fonctionner sous Android KitKat 4.4.2, avec un processeur central et 512 Mo de RAM. À l’aide des mêmes serveurs du répertoire incons- cient et LBS, les 24 dispositifs émulés traitent des requêtes basées sur les délégations à l’aide de coordonnées échantillonnées à partir de l’ensemble de données B. Chaque dis- positif émulé stocke le temps pris par une requête pour se compléter, ainsi que la taille des requêtes et des résultats géodépendants.