Gestion de données personnelles respectueuse de la vie privéepetrus.inria.fr › ~anciaux › HDR_NA.pdfDes services sont calibrés selon ces données Ex. collecte par formulaire

Gestion de données personnelles

respectueuse de la vie privée

Nicolas Anciaux, Chercheur INRIA, projet SMIS

équipe commune: INRIA Rocquencourt,

Univ. de Versailles Saint-Quentin-en-Yvelines,

et CNRS

Habilitation à Diriger des Recherches

Univ. de Versailles Saint-Quentin-en-Yvelines

Le 9 décembre 2014

1

PR SM

Thèse (UVSQ)

Post doc (U.Twente)

PicoDBMS

Co-design de SGBD embarqué

Benchmark

Traitements BD privées/publiques

GhostDB

Traitements relationnel embarqués

Archi. gestion de données PbD

PlugDB

Collecte et rétention limitée

MinExpCard

Moteur NoSQL/CA embarqué

Modèle de partage (WPS)

Contrôle d’usage

H. van Heerde

(2005-2010)

Y. Guo

(2008-2011)

L. Le Folgoc

(2009-2012)

S. Lallali

(2012-…)

P. Tran Van

(2014-…)

L. Bouganim

P. Pucheral

J.C. Marchetaux

D. Shasha

J.-J Vandewalle

Ij. & Ik. Ray

M. Vazirgiannis

B. Nguyen

P. Bonnet

CR2 INRIA

(CR1 2008)

Vie privée et intelligence Ambiante

Modèle BD de dégradation progressive

InstantDB

P. Apers

L. Feng

M. Fokkinga

Doctorants Collaborations 2000

2005

2006

2008

2010

2012

2014

2

PR SM

Plan de la présentation

Motivation des travaux de recherche : Web Personnel Sécurisé

Contributions et applications

I) Architectures envisagées

II) Evaluation de requêtes embarquée

III) Exposition minimum

IV) Application au « Dossier Médico-Social Personnel »

Conclusion et perspectives

3

PR SM

Le modèle du Web actuel

Données durables et accessibles

Délégation (enjeu de vie privée)

Ouverture et opt-out non garantis

Dissémination sans garantie pour l’usager

Chartes floues, passe-droits, usages secondaires

Centralisation (enjeu de sécurité)

Une simple négligence compromet des millions de dossiers

Attaques massives récurrentes (ratio coût/bénéfice faible)

Ex: Orange 1,3M mai 2014, 800K mars 2014

Cloisonnement (enjeu de complétude)

Stratégie monopolistique

Technique d’appariement contestable

4

Social Photos

Mail Banque

Achat

Pub. ciblée Profilage

PR SM

Le modèle du Web Personnel

Rend leurs informations aux usagers

Encouragé par des organismes (banques)

Par les institutions (opération Blue Button)

CozyCloud, OpenPDS, PlugDB…

Complétude de fait

Nouveaux usages

Vie privée sous contrôle

Ouverture et opt-out de fait

Partage contrôlé, exposition minimale

Calculs globaux anonymes

5

Social Photos

Mail Banque

Achat

Pub. ciblée Profilage

Coordination

médico-sociale

Exposition

minimale

Capteurs Localisation

«Quantified-self»

Calcul global anonyme

PR SM

Notre approche: un Web Personnel Sécurisé

Comment rendre ses données à l’usager ?

Sur son PC ? un service Cloud ?

Un serveur personnel propriété de l’individu…

Dépositaire du patrimoine numérique d’un individu

Régulant la dissémination des données

… intégrant des fonctionnalités de gestion de données

Stockage, indexation, structuration et durabilité des données

Authentification, contrôle d’accès et d’usage

Auto-administré

… et offrant des garanties de sécurité tangibles

Noyau logiciel sécurisé : code réduit , prouvé formellement, open source

Plateforme matérielle : isolée de la plateforme applicative, sécurisée

matériellement, open hardware

6

PR SM


Motivation des travaux de recherche







7

PR SM

Architecture « Serveur Personnel de Données »

Approche institutionnelle

Monde structuré

Par domaines applicatifs

Données: format régulé

Normes, référentiels communs

Droits d’accès: institutionnels

L’individu garde un droit au masquage

«Honnêtes mais curieux»

Chiffrement, comm. anonymes

Défis scientifiques

Gestion de données embarquées,

durabilité, partage (exposition

minimum, masquage, audit),

évaluation globale …

8

Personal

database

John

Content

provider

Document

Wrapper

DBMS

Mapping

rules

<DOC>

<Id> 7 </>

<name> Jim </>

~~~~~~~~~~~~~ </></>

<DRUG>

<Id> 45</>

<name> Mucomist</>

~~~~~~~~~~~~~ </></>

<VISIT Id = “X”>

<Date> 2010/1/1</>

<DocRef>7</>

~~~~~~~~~~~~~ </></>

<PRESCS>

<VisitId Ref=“X”/>

<DrugRef>45</>

<Posology> 3/day</></>

Enriched XML

document

XML Schema e.g.,

hospital

John’s PDS

Application

Appli.

provider

Doctors,

Drugs

conforme

Honest but curious

Encrypted storage

Anonymous comm.

e.g., Santeos

Application

Mappings Mappings

Priviledges Priviledges

DB Schema

provider e.g., Ministry

of Health

[VLDB’10]

PR SM

Architecture « Cellules de confiance »

Centrée sur l’usager

Nombreux dispositifs produisent

des données sur l’individu

Données diverses

Personnelles, issues de capteurs, …

Droits d’accès et d’usage

Définis par l’individu

Infrastructure

«faiblement malicieuse»

Défis scientifiques

Collecte contrôlée (capteurs de

confiance), auto-administration,

contrôle d’usage (UCON*ABC)

9

A

A & B services

A

A Power

provider

Super-

market

Car insurer

B

Syn

c.

A

Portable Trusted Cell Encrypted personal vault Secure data exchange

Ph

oto

s

MyF

iles

Syn

c.

Fixed Trusted Cell S

yn

c

.

Heat sensor

Power meter

F E

D H

G

I C

Internet

café

A & B home

D

E F

H

I

G

B

A

Employer

Hospital

School

C

C

GPS

Weakly malicious

[CIDR’13]

*Obligation, conditions, mutabilité

PR SM

Architectures: conclusion et résultats

Ouvrent à de nombreux défis scientifiques

Gestion de données embarquée

Contrôle de la dissémination des données : exposition minimale

Objectif actuel

Une architecture pour le Web Personnel Sécurisé

2010

2014

2013

Serveur Personnel de Données : VLDB’10

Cellules de confiance : CIDR’13

Archi. avec matériel sûr : tutoriel MDM’13

tutoriel EDBT’14

Folk-IS: papier vision VLDB’14, SIG. record’14

Thèse de Y. Guo (2011)

Thèse de L. Le Folgoc (2012)

Thèse P. Tran Van (CIFRE CozyCloud)

10

PR SM









11

PR SM

Objectif et matériel cible

Gérer des données personnelles dans un composant sécurisé

Volume de données potentiellement grand

e-mails, documents personnels, médicaux, administratifs, données d’interractions, issues de

capteurs, trace GPS, de consommation énergétique, etc.

Des techniques d’évaluation de requêtes embarquées doivent

permettre de n’exposer que des résultats autorisés

Les composants cibles peuvent avoir des formes diverses

12

Secure devices on which

a GB flash chip

is superposed

USB MicroSD

reader

Contactless + USB

8GB Flash

Secure MicroSD

4GB Flash

Personal memory devices

in which a secure chip is implanted

Multimedia

Sim Card Sensor node

PR SM

Gestion de données: une architecture commune

Microcontrôleur

Faible coût

Faible consommation d’énergie

Protection matérielle

Miniaturisation

Maillage (porteur d’un signal),

Couches de composants superposées,

Capteurs (lumière/temp./freq./voltage)

Prévient les attaques physiques

Mémoire de type NAND FLASH

Faible coût

Faible consommation d’énergie

Densité et robustesse

NAND

FLASH

MCU

BU

S

13

PR SM

Contraintes matérielles fortes… mais pérennes

Les microcontrôleurs ont une petite RAM (<128 KB)

Elle est alimentée => consommation énergétique (lié à la quantité)

Elle détermine le prix du microcontrôleur

La RAM n’est pas dense => nuit à la sécurité (liée à la taille)

Ecritures aléatoire coûteuses en Flash (10-500ms carte SD)

Fonctionnement de la Flash: les pages sont effacées avant toute

modification, l’effacement est par bloc vs. écriture par page

Pour compenser ces effets il faudrait de la RAM (cas d’un SSD...)

Or dans l’embarqué, le ratio RAM/mémoire stable ne fait que diminuer

Contraintes durables pour tout dispositifs

autonome, à bas coût (capteurs, carte SD)

ou sécurisé (puce sécurisée ou “durcie”)

14

PR SM

Techniques existantes

SGBD légers

e.g., SQLite, BerkeleyDB, DB2

Everyplace, …

Vise des plateformes plus puissantes

(e.g., smart phones, boîtes Internet)

Indexation de BD en Flash

Adaptation de l’index B+: BFTL [TECS07],

LATree [VLDB09], FDTree [VLDB10]

Stocke les mises à jour de l’index dans

un journal en Flash, indexé en RAM

Les mises à jour sont intégrées à l’index

en batch pour factoriser des écritures

Petite RAM petit index en RAM

intégration fréquente du journal

gains minimes

Systèmes clé-valeur en Flash

SkimpyStash [SIG11], LogBase [VLDB12],

SILT [SOSP11]

Les couples clé-valeur sont stockés dans

un journal en FLASH

Un index en RAM est construit sur ce

journal (~1 octet par couple clé-valeur)

Gestion de données pour MCUs

e.g. PicoDBMS [VLDBJ01], VSDB [TOIS03],

HybridStore [WSN13]

Considère de petits volumes de données

stockés en mémoire interne (EEPROM,

NOR)

Proposition en RI, e.g., MAX [TSN08],

Snoogle [TPDS10], Microsearch

[TECS10]

RAM FLASH

RAM

RAM

15

PR SM

Formulation du problème

Objectif : évaluer des requêtes avec très peu de RAM sur de

grandes quantités de données stockées en FLASH NAND

Comment rompre ce cercle vicieux ?

De nombreuse écritures aléatoires

… avec un coût inacceptable

en Flash Maintenance des index

indexation

massive

Evaluer des requêtes

avec une petite RAM

Stratégie Pipeline

Consomme trop de RAM

Journalisation en Flash

Indexation du journal en RAM

16

PR SM

Notre approche pour résoudre le problème

1- Concevoir des index permettant une évaluation pipeline

2- Organiser toute la BD dans des structures sequentielles

Des containers séquentiels (LC) satisfont les contraintes de la Flash

Allocation & libération réalisées à très gros grain (taille multiple d’un bloc de Flash)

…. de manière à éviter tout émiettement de la mémoire (ramasse miettes coûteux)

Les pages du container sont écrites séquentiellement (et jamais modifiées ni déplacées)

…. de manière à proscrire les écritures aléatoires par construction

3- Passer à l’échelle par réorganisations successives de la BD

Les structures séquentielles sont réécrites en structures plus efficaces

… l’opération de transformation repose sur des containers séquentiels

17

PR SM

Evaluer des requêtes SQL en pipeline

LIN

PS ORD

SUP CUS PAR

Project

Intersect

merge

{LINid}

Tselect sur SUP.Name

{LINid}

Tselect

access ‘SUPPLIER-1’

{LINid , CUSid,

ORDid, PSid}

Tjoin

access

Tjoin sur LIN

Plan d’exécution

Tselect

access

{LINid}

‘HOUSEHOLD’

Tselect sur CUS.Mktsegment

Tjoin on LIN

LIN

id

OR

Did

CU

Sid

PS

id

PA

Rid

Tjoin (index de jointure généralisé)

chaque rowid de la table

racine contient les

identifiants des tuples des

dimensions référencées

SU

Pid

Tselect sur

SUP.Name

Tselect chaque clé de l’index contient

les rowid de la table racine

référencant cette clé

NB: Tselect renvoie

des rowid triés!

Tselect sur

CUS.marketsegment

t20 t50 t30

K1

K2 … … …

… …

Kn

HOUSE HOLD

SELECT CUS.*, ORD.*, LIN.*, PARTSUP.*

FROM CUSTOMER CUS, ORDER ORD, LINETEM LIN, PARTSUP PS, SUPPLIER SUP

WHERE CUS.CUSkey = ORD.CUSkey AND ORD.ORDkey = LIN.ORDkey AND

LIN.PSkey = PS.PSkey AND PS.SUPkey = SUP.SUPkey AND

CUS.Mktsegment = 'HOUSEHOLD' AND SUP.Name = 'SUPPLIER-1'

Table

racine

‘HOUSEHOLD’ ‘SUPPLIER-1’

18

[SIGMOD’07, EDBT’09]

PR SM

Construire un index à base de containers séquentiels

Log2: «Keys» (colonne)

Stocke la clé de l’index à l’insertion du tuples

Log1: «Ptrs»

Stocke une chaîne de pointeurs

Log3: «Filtres de Bloom»

1 FB construit par page de «Keys»

Résumé de la page (2 octets / clé)

Table scan

(640 IOs)

CUSTOMER … … … Joe

… … … Jack

… … … … … … … Paul

… … … … … … … … … … … Jim

… … … … … Tom

… … … …

… … … Lyon

… … … Lyon

… … … … … … … Lyon

… … … … … … … … … … … Lyon

… … … … … Lyon

… … … …

t20

t50

t70

t90

t30

Summary Scan

(17 IOs)

Keys

Log2

… Lyon …

Lyon … … …

Lyon … … … … …

Lyon … …

Lyon … …

Indexed

column

CITY

P16

P78

B.Filters

Log3

Recherche efficace… … mais comment permettre un passage à l’échelle ?

Ptrs

Log1

… BF2 …

BF16 …

BF68 … …

BF79 …

19

[EDBT’14]

PR SM

Assurer le passage à l’échelle de toute la BD

Réorganisation de la BD dans des structures plus efficaces

La réorganisation est une opération purement séquentielle

20

Sta

rt r

eo

rgan

izati

on

DEL2 / UPD2 DATA2

IND1 DEL1 / UPD1

DATA1

ReorgIndex

Merge

*IND1

ReorgIndex

Merge

*DATA0

*DATA1

En

d r

eo

rgan

izati

on

IND0 DEL0 / UPD0

DATA0

Sta

rt r

eo

rgan

izati

on

*IND0

IND2

En

d r

eo

rgan

izati

on

Time

Insta

nce 0

In

sta

nce 1

In

sta

nce 2

[EDBT’14]

PR SM

Design d’un SGBD embarqué pour grosses BD Flash

Travaux actuels

Généralisation de nos techniques aux modèles NoSQL

et à des modèles de contrôle d’accès basés sur des tags

2007

2014

2011

2015

Evaluation embarquée : conclusion et résultats

Design initial (RO) : SIGMOD’07, Démo VLDB’07

Calcul d’agrégats : DAPD’09

Design DMSP : Démo SIGMOD’10

Design SGBDR complet : DAPD’14

Moteur de recherche : VLDB’15 (2eme round)

Démo SIGMOD’15 (soumis)

PlugDB-engine (déposé à l’APP)

Thèse de Y. Guo (2011)

Thèse de L. Le Folgoc (2012)

Thèse S. Lallali (en cours)

Transfert PlugDB CozyCloud

21

PR SM









22

PR SM

Collecte et rétention limitée des données

Principe législatif univoque (OCDE 1980, directive EU95/46/EC)

Limiter la collecte et la rétention des données au nécessaire

Scénario d’usage

Un individu fournit des données personnelles (en guise de preuve)

Des services sont calibrés selon ces données

Ex. collecte par formulaire

Aides sociales, banques, assurances…

Le minimum de données

doit être collecté…

Ces principes ont aussi des avantages pour les organismes

Traitement des demandes accéléré (CG78)

Coût réduit en cas de fuite de données (lié au volume de données)

Sentiment de « sur-collecte » ressenti par 50% des citoyens EU

23

Offre de service

Formulaire complet

Jean 83 ans beaucoup d’inform- -ations

Formulaire vierge

PR SM

Techniques existantes

Pour les sites Web : P3P (contribution pionnière)

Principes du “besoin d’en connaître” et du consentement pour les sites web

Identifie des politiques conflictuelles, ne calibre pas l’information exposée

Bases de données hippocratiques (IBM)

Fait l’hypothèse que les données nécessaires sont connues à l’avance

Ne tient pas si l’utilité de la donnée dépend de son contenu (fréquent)

Ce qui est le cas de nos scénarios d’usage…

Négociation automatique et modèles ouverts de contrôle d’accès

Les attributs sont exposés à minima

Requêtes simples

Quelques attributs échangés

24

Bob Alice

Credentials

Disclosure policies

Resource R

Access control

policy

Credentials

Disclosure policies

Computes

minimum

set

SMC

PR SM

Architecture à collecte minimum

Ingrédients

Règles de collectes (proc. de décision) :

Assertions individuelles:

attribut=valeur

Métrique d’exposition:

nombre d’assertions

Problème:

Trouver l’ensemble minimum d’assertions qui valide les règles

25

salaire>30K€ patrimoine>100K€

garantie>50K€ ass_vie=oui prêt+élevé

salaire>30K€ taux_impots>10%

age<30 niveau_etude=univ. assur_reduite

Offre de service

Jean 83 ans beaucoup d’inform- -ations

Règles de collecte Formulaire vierge

Minimisation

du contenu

du formulaire

Formulaire minimum

PR SM

Solutions

Solution exacte

Min Weighted SAT (NP-Complet)

Résolution par solveur trop longue (>100 assertions)

Solution approchée

Heuristiques adaptées aux topologies réelles

Règles d’attribution des aides sociales (CG78) : 63 règles, 440 prédicats

Jeux de données multi labels publiques

Réduction d’information toujours importante (> 40% vs. état de l’art)

Algorithmes simples (linéaires dans le nombre de prédicats)

…. et fonctionnant avec très peu de RAM (quelques Ko)

Proto. carte à puce : confrontation confinée des règles et des données

En quelques secondes pour les plus grandes instances considérées (>600 prédicats)

26

[PST’12, EDBT’13]

PR SM

Exposition minimum : conclusion et résultats

L’intérêt de notre solution

Spectre très large (support des classifieurs multi-labels)

Exécution sécurisée (règles privées)

Décision finale préservée

Travaux actuels

Nouvelle modélisation du problème pour capturer certaines inférences :

Connaissance des règles de collecte (non satisfaites)

Connaissance antérieure (formulaires déjà transmis)

Connaissance de l’algorithme de réduction

27

2012

2015

Problème d’exposition minimum : PST’12

Version étendue (règles plus riches): ISI’13

Application à l’aide sociale : Démo EBDT’13

Classifieurs multi-labels : Fund. Informatica’15

Collab. B. Nguyen & M. Vazirgiannis

Tangente’14

IREP, MyProfile => fidélité

PR SM









28

N. Anciaux – soutenance HDR

Coordination médico-sociale

Personne dépendante

Domicile

DMP, serveurs (ALDS, Cogitey), équipements personnels, outils domotiques…

29

Acteurs

médecins, infirmières, kinés, assistantes sociales, porteurs de repas,

aides journalière,

entourage…

Systèmes

Besoins exprimés :

• Dossier complet (à domicile, en consultation)

• Respectant des règles d’accès différenciées

• Synchronisé avec des chaînes de traitements


Solution 1 : dossier papier au chevet


Domicile

30

Acteurs

Systèmes

Dossier complet (au chevet, en consultation)

Aucune confidentialité

Doubles saisies

Ne capture pas l’information domotique



aides journalière,

entourage…


Solution 2 : dossier centralisé


Domicile

31

Acteurs

Systèmes

Dossier complet (connexion Internet)

Pas de double saisie

Problème du consensus transverse (santé, social, public, privé, etc.)

Sentiment de Défiance, surveillance (délégation & centralisation)

Connexion internet itinérante pour tous (porteurs de repas, ménagères…)



aides journalière,

entourage…


Solution DMSP : dossier patient

Domicile

32

Acteurs

Systèmes




aides journalière,

entourage…


Sauvegarde

Boîte aux lettres

Synchronisation

33

Dossier complet (au chevet, en consultation)

Droits différenciés,

Restauration à partir d’une archive chiffrée

Synchronisé avec les chaines de traitement externes

Difficulté de convaincre les institutionnels

Solution DMSP : fonctionnement

PR SM

Application DMSP : conclusion et résultats

Usage sur le terrain de nos technologies

Moteur SGBDR embarqué

Nouveau modèle de contrôle d’accès orienté évènements (EBAC)

Pilote JDBC embarqué implanté en Javacard

Algorithme de synchronisation asynchrone

Expérimentation terrain: 40 patients, 80 professionnels

Audit du DMSP (ARS & CG78) en vue d’une généralisation

34

2008

2015

Application DMSP/EBAC: IJTA’08, CBMS’08,

IJHDRI’09, Book Chapter 09, Cahiers du CRID 09

Démos: Javaone’09, RII’11, RII’14, FeS’13…

Audition de SMIS à l’Assemblée

Expérimentation terrain

PR SM

Au-delà de DMSP

Une Plateforme pour le Web Personnel Sécurisé

Conception d’un nouveau dispositif matériel

Carte à puce

Microcontrôleur

Carte microSD

Lecteur d’empreinte

Microphone

Interface USB et Bluetooth

Fabrication par n’importe

quel assembleur

Intégration de nos algorithmes

(en cours)

35

SD card

Bluetooth

Fingerprint

reader

Smartcard

(gestion de

données)

(secrets)

(données)

MCU

USB

PR SM

Dynamique de dissémination autour de la plateforme

Logique open source et open hardware

Dissémination de la plateforme auprès des étudiants

Par l’enseignement : plateforme ENSIIE, INSA Lyon, INSA Bourges

Au travers du FabLab de l’Université de Versailles

Ouverture vers d’autres communautés scientifiques

Dans l’ISN (économistes, juristes) et le PEPS ‘PAIP’

Ouverture vers des applications sociétales

Avec le LIRIMA : solution médicale/édu. sans infrastructure

Avec le RITM (et SILLAGE) : plateforme pour l’eco. expé. (& MOOC)

Avec la FING et CozyCloud : "Blue Button" à la Française

Collaboration avec des acteurs industriels du Web Personnel

Collaboration avec CozyCloud : coupler CozyCloud et PlugDB

36

PR SM

Conclusion générale

Bilan scientifique

Architectures: Serveur personnel, Cellules de confiance, Folk-IS

Algorithmes de gestion de données embarquées : stockage,

indexation, interrogation, atomicité, croisement de données

publiques/privées

Modèles: contrôle d’accès basé événements, dégradation progressive

de données, exposition minimum

Prototypes et expérimentations

Travaux futurs auxquels j’aimerais me consacrer

Sécuriser de nouveaux modèles de données / contrôles d’accès

Contrôle d’usage : sécuriser des traitements de données complexes

Gestion de données sans infrastructure

37

PR SM

Sécuriser de nouveaux modèles de données et de

contrôles d’accès Transposition en embarqué de modèles orientés documents

Recherche sur le contenu et contrôle d’accès basé tags/attributs (S. Lallali)

Généralisation des principes de design à d’autres structures d’indexation

Motivation

User Desktop pour le Web Personnel Sécurisé (moteur de recherche)

Droits des applications fonction de tags apposés sur les fichiers

Etat de l’art

RI classiques: index inversé arborescent, calcul tf-idf avec beaucoup de RAM

RI embarqués: pas de passage à l’échelle, ni suppression, ni contrôles d’accès

Microsearch [TECS’10], capteurs photos [SenSys08], MAX [TOSN’08], Snoogle [TPDS10]…

Approche

(1) index inversé composé de partitions séquentielles (jamais modifiées)

(2) Coût de la recherche sur N partitions ~ coût sur une structure optimale

(3) fusions successives des partitions sans générer d’écriture aléatoire

38

PR SM

Contrôle d’usage

Traitement de données complexes : étendre la sphère de sécurité

Brassent de grands volumes de données, mais ne peuvent être embarquées

Ex. calculs de profils, recommandations, désagrégation de séries temporelles

Contrôle d’usage : limiter la fuite d’information d’un traitement de données externe

En collaboration avec P. Bonnet

Challenge

Limiter les effets de bord d’un traitement externe (code potentiellement corrompu)

Scénario d’application : désagrégation de trace énergétique

Solution Cloud : transmission de toutes les données à un service de désagrégation

Sécurisation limitée à certaines primitives (facturation, statistiques anonymes)

Approche

L’association d’un environnement d’exécution sécurisé

avec un environnement non sécurisé mais isolé (sandboxing)

et déposable (sans mémoire d’une exécution à l’autre)

Et des techniques de vérification du résultat avant déclassification

39

PR SM

Gestion de données sans infrastructure : Folk-IS

Services orientés données à bas coût dans les pays les moins avancés

Facteur de développement économique, dans l’éducation, la santé, la finance, etc.

Solutions génériques « lourdes »: Loon (Google), Internet.org (Facebook)

Solutions ad-hoc légères (échanges de SMS) : chaîne du froid, agriculture, e-admin

Un serveur personnel sécurisé sans écran ni clavier

Des terminaux partagés sur lesquels tournent les applications

De nombreux challenges BD liés au manque d’infrastructure

Ex. Requêtes globales sans infrastructures

Techniques BD distribuées ou P2P? Connaissance de la localisation des nœuds

Notre approche Hypothèse de monde ouvert: admettre la possibilité de résultats approchés,

terminer les requêtes

Identifier les sources adaptées sans surcharger le réseau (conditions spatiales)

Router les requêtes et les réponses (protocoles géographiques, profile de mobilité,

principe de « l’ étranger familier »)…

40

Questions ?

Documents

Gestion de données personnelles respectueuse de la vie privéepetrus.inria.fr › ~anciaux › HDR_NA.pdfDes services sont calibrés selon ces données Ex. collecte par formulaire