Dynamic Privacy Management In Services Based Interactions

interpretation. A composition system CS is defined with a list of process definitions P̄ , a list of Web service interface definitions S̄, and a main expression e (Fig. 5.8). A process definition gives the process a unique name P and defines it’s constituent services as well as activities between those services and the variables that they exchange. A Web service definition gives 115 the service a unique name S and defines its operations and input and output variables and their types. The analysis starts with a root expression eroot that explicitly instantiates the root process Proot (the action associated with createInstance=”yes”). The analysis starts by creating the process instance Proot from the main process definition then it abstractly interprets eroot in the context of Proot. First, the process creates all global channels that will be used by the participating processes. In our running example, a client initiates a process, which creates five channels with fresh names ( GenomWS,PharmaWS, DrugWS, ClinicWS, DemoWS), sends the variable g along GenomWS, waits for response on GenomWS, then passes the output over to DrugWS, and so on. The abstraction function maps each concrete expression e to an element in LPA. A composition lattice in our case is a tuple lattice, and it is the set of all maps from variables to LPA. 1 vPA 2 iff 8u 2 V ar 1(u) vPA 2(u). Also, 1 tPA 2 = {u 7! 1(u) tPA 2(u)|u 2 V ar}. For example, for the two tuple lattice values [u 7! H, i 7!MH] and [u 7!MH, i 7! L]: [u 7! H, i 7!MH] 6v [u 7!MH, i 7! L] [u 7! H, i 7!MH] t [u 7!MH, i 7! L] = [u 7!MH, i 7!MH] In our case, the abstraction function derives abstract values from the privacy preferences attached to the data. Flow (transfer) Functions then compute dataflow information after executing an expression e from the dataflow information before executing that expression. Formally, we map a lattice element and a control flow graph (CFG) node corresponding to a process node to a new lattice element (i.e., fPA( , [e]) = 0), where is the old lattice, e is the expression that we are transferring over, and 0 is the new lattice. The intuition behind building a CFG is to connect nodes in order of operation defined by the language. For example, in a BPEL4WS conditional we evaluate the condition first. We employ Killdal’s worklist algorithm [55], which keeps track of nodes (expressions) to which we need to propagate dataflow information. The algorithm computes a results array, which keeps track of the dataflow value for each node i in the system. The algorithm initialize the lattice values for all nodes to the bottom element in LPA. For the first expression to be executed in the process the results will be whatever the initial information is. We assume that initially any of the variables 116 Algorithm 9 Worklist Algorithm 1: worklist = new Set(); 2: for all node indexes i do 3: results[i] = ?PA; 4: end for 5: results[entry] = >PA //MH; 6: worklist.add(all nodes); 7: while (!worklist.isEmpty()) do 8: i = worklist.pop(); 9: before = tk2pred(i) results[k]; 10: after = fPA(before, node(i)); 11: if (!(after v results[i])) then 12: results[i] = after; 13: for all k 2 succ(i) do 14: worklist.add(k); 15: end for 16: end if 17: end while could be highly private (i.e., may be, may be not). Next, the algorithm takes each node off the list and takes the join of the lattice values for all its predecessors. For instance, if it reaches the end of a conditional, the algorithm does a join on the lattice information obtained from the then branch and the else branch. So, if the privacy level type on a variable was H in one branch, and L in the other, the algorithm assumes that it is MH. This provides the results for the lattice information obtained before executing a node. The algorithm then applies the transfer function fPA to that before information, and the node that is at position i and computes the after lattice information based on that. Next, the algorithm determines how this information propagates in the system. If the results remain the same as they were before, it stops analyzing that particular node. However, if a change is indicated, it needs to add all the successors of this node to the worklist since they need to be analyzed with the new information. If the results got worse from before (i.e, they are not at least as precise as they were before), the algorithm updates the results array based on the newly computed after value, then it pushes all successors onto the worklist. The analysis terminates if all nodes are visited and the values do not change any more. 117 Table 5.3: Results of running the worklist algorithm (Listing 9) on the sample process execution in Listing 5.2 position worklist channels tuples/variables c S1 S2 S3 S4 S5 g d gd a m n 0 1 MH MH MH MH MH MH MH MH MH MH MH MH 1 2 MH MH MH MH MH MH MH MH MH MH MH MH 2 3 MH MH MH MH MH MH MH MH MH MH MH MH 3 4,5,9,10,11,12 MH MH MH MH MH MH MH MH MH MH MH MH 4 5,9,10,11,12 MH MH MH MH MH MH L MH MH MH MH MH 5 6,7,8,9,10,11,12 MH MH MH MH MH MH L MH MH MH MH MH 6 7,8,9,10,11,12 MH L MH MH MH MH L MH L MH MH MH 7 8,9,10,11,12 MH L H MH MH MH MH H L MH H MH 8 9,10,11,12 MH L H MH H MH MH H MH H H MH 9 10,11,12 MH L H H H MH MH H MH H H MH 10 11,12 MH L H H H MH MH H MH H H MH 11 12 MH L H H H H MH H MH H H H 12 H L H H H H MH H MH H H H 5.5.4 Working Example We simulate the privacy flow analysis execution on the sample composition in Listing. 5.2. The labels 1,2,3,4,5,6,7,8,9,10,11,12 correspond to positions in the process execution. Table 5.3 shows the results of running the worklist algorithm (Listing 9) on a sample process execution (Fig. 5.1). First, we assume that all variables may have a high privacy level (MH). expressions 1 and 2 have no impact on the composition lattice since they are only declaration expressions. Expression 3 is a sequence activity, so it leaves the lattice as is. Next, the algorithm pushes all nested actions of that sequence on the worklist (i.e., expressions 4, 5, 9, 10, 11, and 12). Next, expression 4 initializes the gene variable g (assume that the client sent the value GRIK2 which has a low privacy level), so the algorithm changes it’s lattice value to L. Expression 5 is a flow activity, so it leaves the lattice as is, and all it’s nested expressions get pushed onto the worklist (i.e., 6,7,8). The next expression to be analyzed is the invoke expression at position 6, which takes g:L as input. Since the invoke is on S1, which is instance of GenomWS, the analysis propagates the privacy level type L to the subsequent operation invocations inside GenomWS (if any). Since S1 is the receiver of this invocation, it also gets assigned a privacy level type L. Also, the output variable gd gets assigned that value. Listing 5.2: Example composition [Partners Client c,GenoWS S1,DrugWS S2,ClinicWS S3,PharmWS S4, DemoWS S5]1 [Variables g,d,gd,a,m,n]2