The rapid changing of mind

The problem of rapid changing of mind occurs when the data subject decides to change their consent choices so quickly that the system is not able to implement the first change before the action for the next change occurs. Thus, there is a risk that the former action might not be implemented (or it could be implemented later than the second action) and the final result could be different from what the data subject expects.

For example, suppose the data subject decides data to be shared with third parties but regrets it soon after and decides to revoke that action by deleting data from the third parties. If the decision to delete data is so rapid that the second action in the system occurs before the sharing of data is implemented by the system, then in the final state of the system, the third parties will possess data from the data subject (in essence the sequence of the actions is reversed).

To avoid such issues a concurrency model that will highlight which sequence of actions could create problematic situations must be defined and a resolution policy should be provided. What safely can be argued is that:

• All grant actions could run in parallel. The pre-conditions of the actions are disjoint and the post conditions are compatible (i.e. do not interact).

• All revocation actions could run in parallel for the same reason that the grant actions run in parallel.

as they affect different rights and Φ restrictions. However, two of the same kind cannot.

Since the consent and revocation logic is designed based on a user-centric per- spective, the actions that derive from the data subject will always have the highest priority. The obligations that occur from the data subject’s wishes have the second highest priority, whereas the actions that are triggered by the data controller have the lowest priority. No actions can be triggered by third parties that could influence the state of the data controller’s system.

Based on the above rationale and looking the system from a global view (i.e. someone who can see everything), the concurrency model is as follows:

• When the grant, notify, change and update actions are triggered in parallel (denoted by the∥symbol) then the grant action is executed first and then the other actions are all executed simultaneously.

– grant(a,b,δ)

– notify ∥ change ∥ update

– If the grant action is triggered by the data controller and the other actions are triggered by the data subject, then the priority is reversed.

∗ notify ∥ update ∥ change ∗ grant(b,c,δ)

• When the revoke, notify, change and update actions are triggered in parallel then the revoke action is executed first and then the other actions are all executed simultaneously.

– revoke(a,b,δ)

– notify ∥ change ∥ update

– If the revoke action is an obligation, triggered by the data controller and the other actions are triggered by the data subject, then the priority is reversed.

∗ notify ∥ update ∥ change ∗ revoke(b,c,δ)

• When the actions revoke, grant update, change and notify are triggered to- gether then:

– The actions with the highest priority are the “grant′′ and “revoke′′ ac- tions. The actions then are ordered by using a time stamp and are processed sequentially. The action with the least recent time stamp will be triggered first, followed upon completion from the second action. – The second action is triggered (either grant or revoke).

– All the other actions are triggered simultaneously.

– If a revoke action is an obligation, then the obligation is triggered first, the update, notify and change actions next and the last action to be triggered is the grant action.

– Based on the same rationale, if the grant action is triggered by the data controller, the revoke action has the highest priority. The grant action will be triggered first, then the revoke action is triggered and the last actions to be executed are the update, notify and change actions.

– If the grant action is triggered by the data controller and the revoke action is an obligation, then the update, change and notify actions have the highest priority. Thus, the first action to be triggered is the grant action by the data controller, the second should be the obligation to revoke and the last actions are the update, change and notify actions. • In the case where grant, revoke, change, update and notify actions are trig-

gered by the data subject, revocation, change, update and notify actions are triggered by obligations and grant and revoke actions are triggered by the data controller, then the priority is:

1. Resolve the time issue between the grant and the revoke actions that were triggered by the data controller and trigger the first action.

2. Resolve the time issue between the grant and the revoke actions that were triggered by the data controller and trigger the second action. 3. Resolve the time issue between the revocation or grant action that is

triggered by an obligation and trigger the first action.

4. Resolve the time issue between the revocation or grant action that is triggered by an obligation and trigger the second action.

5. The actions update ∥ notify ∥change triggered by an obligation.

6. Resolve the time issue between the grant and revoke actions triggered by the data subject and trigger the first action.

7. Resolve the time issue between the grant and revoke actions triggered by the data subject and trigger the second action.

8. The actions update ∥ notify ∥change triggered by the data subject.