Making Sense of Solid for Data Governance and GDPR

Round 1

Reviewer 1 Report

Abstract and introduction are excellent.

This is a really fascinating paper. The concept of Solid is new to me, in all honesty. Conformity to the law (in this case GDPR) must be a must if Solid is going to acceptable to use for so-called personal ‘control’ of data. IT as an industry has always falsely assumed that it drives new law or changes in existing law by placing technology in the market that is beyond the current legislation and can therefore determine legislative changes that suit the business of IT. This is morally wrong but this is what IT companies do. With GDPR, it is pretty clear where technology must stand and that is it must comply with the law if those companies who—in this case deploy Solid—wish to operate successfully in markets where GDPR or equivalent is enforced.

Section 2. L102 Spelling Ambitious

Section 2 is very brief and I wonder whether the paper is of value now that so many issues around GDPR have already been explored. It is always the response the ‘further investigation is needed’ and mostly this stems from academics wanting to maintain an inflow of industry money either directly or via grants, and the industry itself wanting to keep one step or more ahead of the legislation and become so entrenched in the marketplace that it might simply be easier to change the legislation to suit the product. Of course, as stated this is morally wrong but this is what happens. What more does this paper bring beyond that which is briefly outlined in section 2?

Section 3. Cloud. Basically, cloud is servers on the ground at a server farm somewhere in the world storing data. The fact that apps may temporarily store data at their interface does not change the fact that cloud is simply offsite or offshore storage of data managed by someone else. Processor agreements will be in place that must comply with GDPR if storage is within a GDPR-controlled country or the data originates and is manipulated in such a country.

How is a stacked Pod (see fig 2) relevant to GDPR? GDPR is much more generic in applicability to cover a range of storage mechanisms without explicitly stating data architecture must be x but not y. I am not sure why you need to argue or even if you argue compliance with GDPR in this case?

Section 4. This is a straightforward description of the components of the architecture of a Solid pod. I think this is ok as an explanation of such components if the reader is uncertain of what a Pod is (as I was prior to reading this very good paper).

Section 5. Use Cases.

These are descriptions of possible use cases. The descriptions are reasonable. Are they tested?

5.2.4 l898 missing reference number to the Flanders use case?

Section 6. Applying GDPR

Just a comment: Art 5. ‘transparent’ manner only upon inspection? Data storage and usage is not transparent to the average user.

The section is a very good discussion of GDPR and aspects of Solid such as the role of the Data Controller.

How is GDPR relevant to the use cases in section 5?

7. Issues

Dark patterns, assumption of consent and consent walls are all too common unfortunately and becoming the modus operandi of mainstream companies on the internet.

A really good discussion in this section.

Section 8 is also a good discussion. It does mention use cases once, I think. I wonder the value of the use cases in this paper?

Author Response

Hi. Thank you for your review and suggestions. The changes from this and other reviews are highlighted visually in the revised article, and are summarised below:

Reviewer: Section 2. L102 Spelling Ambitious - fixed.

Reviewer: Section 2 is very brief and I wonder whether the paper is of value now that so many issues around GDPR have already been explored. It is always the response the ‘further investigation is needed’ and mostly this stems from academics wanting to maintain an inflow of industry money either directly or via grants, and the industry itself wanting to keep one step or more ahead of the legislation and become so entrenched in the marketplace that it might simply be easier to change the legislation to suit the product. Of course, as stated this is morally wrong but this is what happens. What more does this paper bring beyond that which is briefly outlined in section 2?

Solid represents significant changes to how GDPR is interpreted and applied because the presumption is that the companies manage data centrally and thus retain all the responsibility - which Solid changes to users having direct control over data. Authorities have mentioned Solid as a future technology of interest based on uncertainty of how to fit it with GDPR. The value of the paper is therefore threefold: it provides an approach to express Solid in terms that help apply GDPR which will help start investigations, it lists what existing issues from GDPR are also applicable to Solid as well as new ones so we can better understand how to assess compliance, and it provides directions to fix issues which will help improve Solid as well as other similar technologies. This has been added in the paper in Section.2 and Section.6.

Reviewer: Section 3. Cloud. Basically, cloud is servers on the ground at a server farm somewhere in the world storing data. The fact that apps may temporarily store data at their interface does not change the fact that cloud is simply offsite or offshore storage of data managed by someone else. Processor agreements will be in place that must comply with GDPR if storage is within a GDPR-controlled country or the data originates and is manipulated in such a country.

With Solid, the assumption is that users get a Pod and have control over it. However, as Section 5 shows this is not true, and there can be several different arrangements which include some where users don't have the promised control. In addition, GDPR compliance depends highly on who has what control over which resource. Therefore the paper provides different scenarios that show that Cloud and Processors used by companies as processors don't necessarily also apply to Solid and users. A paragraph describing differences between Solid and conventional Cloud is added to Section 2.

Reviewer: How is a stacked Pod (see fig 2) relevant to GDPR? GDPR is much more generic in applicability to cover a range of storage mechanisms without explicitly stating data architecture must be x but not y. I am not sure why you need to argue or even if you argue compliance with GDPR in this case?

The contributions of the paper are to provide a direction for how to apply GDPR to Solid, and the role of the figure is to highlight the different ways cloud technologies and resources can be associated with a Pod. This is then used to show different arrangements in Section 5 use-cases, and then applying GDPR's requirements in Section 6. This shows that merely having storage or access control is not enough and there are other considerations that must be addressed for GDPR.

Reviewer: Section 5. Use Cases. These are descriptions of possible use cases. The descriptions are reasonable. Are they tested?

Assuming tested in the sense of being implemented or being evaluated for GDPR - no, because Solid is a new technology that is growing now. However, each use-case is based on existing models such as smartphone app stores, or different software installation repositories. Therefore, the intention is to reuse approaches of GDPR compliance from those areas to such use-cases e.g. which actor controls data and/or apps.

Reviewer: 5.2.4 l898 missing reference number to the Flanders use case? - fixed

Reviewer: How is GDPR relevant to the use cases in section 5?

Reviewer: Section 8 is also a good discussion. It does mention use cases once, I think. I wonder the value of the use cases in this paper?

The use-cases show different actors can have control over the resources, which is important for GDPR's compliance e.g. determination of purpose, technical and organisational measures, and most importantly determining who is the controller. Paragraphs have been added clarifying this in Sections. 6 and 8.

 

Reviewer 2 Report

This is an interesting paper that investigates GDPR in Solid paradigm. 

The paper can be improved by taking into account the following considerations:

1- This paper is limited to only a particular tool (Solid). How the integration of GDPR can be further discussed within similar cloud-based tools?

2- The paper should technically provide some implementation hints for realizing GDPR in Solid and their similar developments. 

3- The paper should improve its novelty by comparing the proposed models and contributions with existing approaches that make use of blockchain and container to meet GDPR requirements in cloud ecosystems.

Author Response

Hi. Thank you for your review and suggestions. The changes from this and other reviews are highlighted visually in the revised article, and are summarised below:

1- This paper is limited to only a particular tool (Solid). How the integration of GDPR can be further discussed within similar cloud-based tools?

The paper cites relevant standards and GDPR guidelines for Cloud which are sources in general presumed to be used by companies. However, Solid is about decentralised data storage under the control of the user - which is a special use of cloud which is not well explored for GDPR. If there are other similar uses of Cloud, the paper's arguments and contributions can be used to also investigate and apply GDPR in such use-cases.

2- The paper should technically provide some implementation hints for realizing GDPR in Solid and their similar developments. 

In addition to Section 6 discussing how GDPR is interpreted for Solid, and Section 7 pointing GDPR issues applicable, Section 8 provides specific directions for what should be implemented technically and organisationally in Solid specifications. These have been communicated to the community (e.g. via GitHub issues) as well as sharing the drafts of this article.

3- The paper should improve its novelty by comparing the proposed models and contributions with existing approaches that make use of blockchain and container to meet GDPR requirements in cloud ecosystems.

Due to the scope being restricted only to Solid and size limits of the article, this is not feasible in this article. It is an interesting suggestion and will be taken into consideration for future work.

Reviewer 3 Report

The topic 'Solid' and its relevance to GDPR is quite timely and required. The paper presents a comprehensive overview of the domain. Though I would have appreciated a systematic approach to identifying existing literature and content on the topic, in its current form the paper could be interesting to the audience, particularly the ones new to the topic.

I would suggest extensive proof-reading before submitting the final version of the paper.

Author Response

Hi. Thank you for your review and suggestions. The changes from this and other reviews are highlighted visually in the revised article, and are summarised below:

Reviewer: The topic 'Solid' and its relevance to GDPR is quite timely and required. The paper presents a comprehensive overview of the domain. Though I would have appreciated a systematic approach to identifying existing literature and content on the topic, in its current form the paper could be interesting to the audience, particularly the ones new to the topic.

There is not a lot of literature on this topic, which is why the section of relevant literature is rather short. However, with the arguments raised in the article e.g. GDPR compliance of cloud technologies, app stores (Section 5 use-cases) as well as existing issues (Section 6, 7) - this provides a connection framework for applying literature in these domains to Solid and finding gaps and/or future directions.

Reviewer: I would suggest extensive proof-reading before submitting the final version of the paper. - thank you, grammatical changes have been made in the revised article.

Round 2

Reviewer 2 Report

The previous comments have been resolved.