1 Interactions between law and computer science: privacy and liability Daniel Le Métayer
2 Multidisciplinary approach Growing intermingling of legal and technological issues: privacy, DRM, liability, electronic contracts, forensics, e-justice, etc. Complex issues which cannot be treated exclusively by legal or technological means Need for a true multidisciplinary research approach LICIT action: Legal Issues in Communication and Information Technologies
3 In this talk: Focus on privacy issues A word on ongoing work on liability issues
Privacy: new issues raised by new technologies 4 - Multiplicity of actors (pairs) Data controllers can be any individual - New forms of personal data (geographical, physical, etc.) and multiplicity of exchanges of tiny pieces of (harmless looking) data Virtually any data can be considered as potentially personal - Invisible devices and interactions (anywhere, anytime) Unambiguous consent of the data subject impossible to implement on a case by case basis
5 Why not computer assisted consent? Philosophy: increased automation from the invasion side, why not also using automation to improve the position of the defense?
6 PRIAM Architecture Subject Agent Controller Agent Auditor Agent
7 Legal requirements - Consent should be free, specific, informed and unambiguous - Mistakes can make the consent null and void - Consent is a unilateral act rather than a contract between the subject and the controller
8 Our proposal 1. Global architecture (actors and responsibilities) 2. Restricted natural language for declarations (SIMPL) 3. Formal model based on execution traces 4. Translation of declarations (consent of the subject and declaration of the controller) into the formal model 5. Link between the formal model and software agent implementations NB: links with the formal models are necessarily partial (some aspects are not amenable to logic and need to be checked manually)
Formal model as a link between technology and law 9 Refinement Formal Model Correspondence Implementation Natural language Proof of properties
10 SIMPL : a SIMple Privacy Language - Pattern-based language used to define disclosure policies (Subject) and collection policies (Controller) - The interface of the Software Agent provides a way for the user to define his privacy policy (disclosure or collection) and displays the policy to the user before signature (e.g. validation using a PIN) - NB: proof of concept language rather than definite solution
11 SIMple Grammar (excerpt for Subjects) Consent I consent to disclose data of category Category to a third party only if Condition-D Condition-D Party-OK [and State-OK] State-OK Var is [less than more than] Val [and State-OK] Category String Var String Val String Purposes List Categories List
12 SIMple Grammar Party-OK this third party has provided the following pieces of information pursuant to this disclosure of data: 1. His identity [with certificate from Privacy Certification Authority in List] [and such identity belongs to List.] 2. His verification level [with certificate from Privacy Certification Authority in List] [and such verification level is at least Number (see definitions below).] 3.
13 SIMple Grammar 3. His privacy policy with respect to this category of data and this policy includes the following commitments : Use only this data for the following purpose(s): Purposes. [Delete this data within a delay of Number Unit.] [Not transfer or disclose this data to any other third party. Transfer this data always accompanied with the present privacy and only to third parties ] [Ensure that any Valid Request from my side to access, erase or modify such data will be satisfied [within a delay of Number Unit.]]
14 Formal Model Semantics of a Software Agent : set of pairs of compliant execution traces : - State trace S 1,, S n - Event trace E 1,, E n State: Variables Values Variables include : - Private data space: MyData (function of type Categories Values) - Imported data space: MyImport (function of type (Identities, Categories) (Times, Values, Sticky-policies)) - Context variables: MyTime, MyLoc (localization), etc. - Policy parameters: MyDPolicy, MyCPolicy, MyIdentity, MyLevel, MyDelay, etc. Event: internal or external
15 Examples of Subject Agent events Disclosure-request (Identity 1, Identity 2, Category, Verification, Commitments) Disclosure-refusal (Identity 1, Identity 2, Category) Data-disclosure (Identity 1, Identity 2, Category, Value, Data-policy) Access-request (Identity 1, Identity 2, Category) Access-reply (Identity 1, Identity 2, Category, Value) Deletion-request (Identity 1, Identity 2, Category)
16 Compliance properties for Subject Agents Data Disclosure: i, E i = Data-disclosure(Id 1, Id 2, Ca, Va, Po) j < i, E j = Disclosure-request (Id 2, Id 1, Ca, Ve 2, Co 2 ) and k, j < k < i E k Data-disclosure(Id 1, Id 2, Ca, *, *) and S i (MyIdentity) = Id 1 and S i (MyData)(Ca) = Va and S i (MyDPolicy)(Ca) = Po = (Id, Ve, Co 2, Cx) and Id 2 Id and Ve 2 Ve and S i Cx
17 Global semantics Global semantics of a system: compliant sets of pairs of (event and state) execution traces Local compliance properties of each execution trace (as defined before for each agent) Global compliance property: each external event in an event execution trace matches with the same event in another event execution trace
18 Global correctness properties Authorization to keep personal data: If the value of a subject is in the data space of a controller with identity Id, then this value is associated with a sticky policy P and the subject has defined at some stage a privacy policy allowing a controller with this identity to receive this data with this sticky policy P. Σ compliant set of traces (E, S) Σ and i, S i (MyImport)(Id 2,Ca) = (*, *, Po) (E, S ) Σ, j, S j (MyIdentity) = Id 2 and S j (MyDPolicy)(Ca) = Po = (Id, *, *, *) and S i (MyIdentity) Id
19 Verification of global compliance properties Modular framework: Global correctness properties can be derived from compliance properties Proof structure: by recurrence on the length of execution traces
20 Additional verifications Non emptiness: Detection of empty disclosure or collection policies (warning) Legal compliance: Consistency between authorized purposes, categories, retention delays No disclosure of sensitive data without previous (interaction based) acceptance from the subject
21 Back to the legal analysis Consent should be - Unambiguous: simple natural language with a well defined mathematical semantics - Specific: hierarchies of categories, of purposes, context, time - Free: separation of issues - Informed: once for all definition of the privacy policy, possibly with legal counsel To reduce the risk of error, combination of - A priori verifications (static and dynamic): prevention and enforcement - A posteriori verifications: deterrence
22 Global architecture - Commitments of the Controllers: - Use the Software Agents faithfully (no access to personal data other than through the Software Agent, no execution traces tampering, etc.) - Ensure compliance with his declarations - Ensure the security of personal data - Roles and commitments of the Software Agent Providers : - Deliver and warrant Software Agents (consistency with Formal Model) through an agreement with their customer (Subject or Controller) - Possibly: submit Software Agents for certification - Roles of the Personal Data Authority (optional) : - Certify the meaning of the natural language for declarations - Certify specific Software Agents or approve independent evaluation centers for the certification of Software Agents
23 Further work Privacy: - Towards a privacy certification process (inspiration from the Common Criteria for IT security) - Privacy in organizations (ANR FLUOR) - Further legal issues: new notion of personal data (data mining, profiles, etc), focus on use of data rather than its collection: transparency, non discrimination Beyond privacy: Formal model of software liability (ANR LISE) More than ever: Strong interactions between technical and legal issues
24 Formal model of software liability Motivations: - The development and exploitation of IT systems involve many different actors (providers, operators, users, etc.) - The commitments of the respective parties and associated liabilities are more and more complex to define and become the source of legal uncertainties - Stakes can be high and liability issues are crucial for business actors Objectives: Provide a technical and legal framework allowing the parties : - to define liabilities in a precise and unambiguous way and - to establish such liabilities in case of claim
25 The LISE Framework Technical issues: - Definition of expected properties of software components - Systematic derivation of the set of errors (negation, mutation) - Definition of the set of claims covered by the agreement (discrepancies between the views of different actors) - Definition of the liability function : Liability : Claims x Logs x P(Externals) P (Parties) - Implementation of the log infrastructure and log analyser Link with the legal framework: - Compatibility with regulations and case law (liability disclaimers, consumer rights, validity of digital evidence, etc.) - Tight integration of the technical and legal parts of the agreement - Iterative process
26 Partners PRIAM: Privacy issues in ambient intelligence (ARC INRIA, 2007-2008) INRIA (ACES, AMAZONES, LICIT), Faculté de droit de Saint-Etienne, Université de Twente LISE: Liability issues in software engineering : (ANR, 2008-2011) INRIA (AMAZONES, LICIT), Faculté de droit de Versailles Saint-Quentin, Faculté de droit de Caen, VERIMAG, SUPELEC FLUOR: Contrôle de flux et d usage dans les organisations (ANR, 2008-2011) ENSTB, CNRS (IODE), INRIA (LICIT), LIUPPA (Université de Pau), SWID, Université de le Polynésie Française