Review Comment:
This paper is a survey of semantic technological approaches to the handling of consent - specifically, consent for data processing in the context of the GDPR - covering representation, management, and visualisation of consent processes.
Thank you for the survey, it's a very clear introduction to the topic, which is important and timely, and likely to be useful and interesting to a wide audience, in the Semantic Web community and hopefully beyond. It appears to be comprehensive and balanced, with a few caveats that I think could be improved in terms of clarity and presentation and consistency.
The point that jumped out at me most is the presence of the sections on incentivisation. These are in stark contrast to the rest of the paper and go rather against the primary topic. It's very jarring to read, on the one hand, a sensible design principle about avoiding 'dark patterns' intended to draw or manipulate users into making choices the designers want, and then on the other hand to read a section on the use of incentivisation "to change one’s mind regarding an action, and to make one perform an action we want" presented uncritically. The latter is clearly precisely the kind of dark pattern the authors have recommended against. I could understand a discussion of the use of incentivisation to encourage users to engage fully with the informed consent process - in a sense, to delay the giving of consent until they have fully explored the implications - but that doesn't seem to be the topic. I'm not sure, as is, how this topic contributes to the discussion of consent and I suggest removing it.
I also take some issue with the claim made (relatively late in the paper: p21, second column) that there's no need to visualise data processing for end users. What's done in data processing is an important part of a user understanding the consequences of data sharing; dismissing users as a potential audience for visualisations of processing could get in the way of this. It's also quite a stretch to imply that data processors and controllers have legal experience that an end-user doesn't - pretty much anyone can legally be a data processor or controller, there's no expectation of any particular legal experience. Again, a little odd to see in a review that otherwise takes the interests of data subjects very seriously.
The competency questions in Table 1 play an unclear role in the paper. How were they derived? It looks as if they're based on requirements in the GDPR itself but if they're important for the paper, it would be good to know for sure, and have an idea of coverage/comprehensiveness with regard to their source. It's not, however, clear how important they are to the paper. Perhaps I misunderstood, but I don't know what role they play in the survey or how they have been used. It would be good to clarify their purpose and use explicitly. To some extent, the same goes for the simplified model of consent presented in Figure 1. I like the idea of having it as a framing structure for the survey, but it didn't clearly come across as being used in the rest of the paper - perhaps this could be made clearer?
I'd welcome a little more depth in the discussion in some places - for example, quite a lot of 3.3 reads as very uncertain about what these systems do and how with regard to consent itself - we could live without knowing that D3.js is used for visualisation and MongoDB for data storage if the space were instead used to say what's unique or interesting about each when it comes to the actual tasks of consent management and user/institution experiences of them, or some insight into how consent can be imposed using cryptography technology.
I enjoyed reading the paper, and I would find it useful as a source - I don't necessarily think it would need significant revisions to address these points. Thank you for writing it.
Some more specific comments below:
p2 c2 l9-10: "technology"->"technologies" (referred to as "them" later in the sentence)
p2 c2 l24: Just "Research" not "Another research" ("research" is a mass noun)
p2 c2 l42-44: "the" before "development and ontology engineering processes" and "relationship of"
p3 c1 l4: "investigations into whether"
p3 c2 l33: Simplified model of the consent lifecycle - what is it simplified from? (And might this model itself incorporate presuppositions about the semantics of consent? If it does, is it a problem?)
p3 Figure 1. Withdraw, Expire, Invalidate, and Refuse should surely either go to Request, or should exit the cycle?
p5 c1 l25-36: duplication of previous paragraph
p6 c2 l39: Presumably this is "for achieving compliance with the GDPR"?
p7 c1 l35: "ConsentAssertion" (not "ConsentAssertation") is the SPL term
p7 c2 l2: "ApplicationFunctioning" (ColPri)
p7 c2: Given their relationship, do SPL and DPV share any structure/contents? DPV is also not mentioned in the summary in 3.1.9.
p9 c1 l46: "user's"->"users"
p10 c1 l17: I'd either separate CoRe and CURE into different entries, if their differences are as big as it sounds, or, if keeping them in one entry, make it explicit in the first paragraph of 3.2.3 that you're looking at two things, one an evolution of the other. Otherwise, the jump to talking about CURE was a bit confusing.
p10 c1 l26: Missing text for footnote 23 (AngularJS), and missing verb phrase after "PostgreSQL".
p11 c1: I'm not sure I really understand what EnCoRe is and does. For example, this reads as if EnCoRe keeps a central record of user data on consent preferences - that seems unlikely but problematic if it does.
p11 c2: It's a bit surprising to read about a consent management platform which uses blockchain without seeing any discussion of how it manages the link between any blockchain records and any personal data - if there's a way to recover or link personal data from a blockchain record, this is widely agreed to be incompatible with the GDPR. There are of course safe ways that platforms like this can operate, but I'd have expected to see it addressed, given in particular how central the GDPR is to this survey.
p12 c1 l3-17: Maybe it's not avoidable, but there are 10 all-caps instances of the word "SPECIAL" in a 15 line paragraph - any way to rephrase to reduce these? As I say, maybe it's not doable, it just stands out a lot.
p12-13: Section 3.3.6 Same question about blockchains and personal data as for ADvoCate.
p13 c2 l48: Even with only hashes on the blockchain, there can still be a GDPR risk (e.g., can a user be identified by the pattern of blockchain transactions belonging to an individual account, which could open an attack vector on hashes?)
p15 c2 l36-37: Maybe worth making explicit that the EU examples like Austria and Germany aren't automatically identical to the GDPR when it comes to data protection laws - there is scope for member state variation, largely, I believe, to allow member states potentially to have stronger restrictions.
p16 c1 l1: I might qualify this with "brought to light the concept of "informed consent" for data protection" - "informed consent" has thankfully been very high on the agenda in other spheres for a long time now. Not as long as it should have been, but a lot longer than for data protection.
p16 c2 l27: Strictly speaking, 'Model consent according to the GDPR' is too specific as a 'recommendation for modelling consent' - maybe 'according to the relevant legal context(s)'? (Of which the GDPR is obviously a very prominent example) Also, a semantic model for consent might want to have a wider net than data processing (clinical consent, for example).
p17 c1 l29-34: I don't understand the relevance of the example to the preceding sentence. Promoting feelings of trust and integrity isn't obviously relevant to a design being clean, simple, and colour-blind appropriate. (If anything, using colour to invoke feelings of trust sounds quite like a 'dark pattern', as described in the column directly adjacent.)
p18 c2 l39-44: Is there evidence you can cite for this claim?
p22 c1 l34-38: Common misconception that blockchain inherently means high computational costs - Bitcoin and (current) Ethereum do, certainly, but there are low computation forms of blockchain too.
|