Connect to GDPR terminology #166

Activity

1. megoth commented on May 8, 2019

   

   megoth

   on May 8, 2019

   More actions

   Any suggestion on how this could be inserted into the specification? Perhaps as an appendix, or should it be more integrated into the specification itself?
2. RubenVerborgh commented on May 8, 2019

   

   RubenVerborgh

   on May 8, 2019

   Contributor

   More actions

   Not in spec; the spec is a technical matter.

   We can/should definitely document elsewhere though.

   👍React with 👍2Reacted by Arne Hassel and Kjetil Kjernsmo
3. Mitzi-Laszlo commented on May 14, 2019

   

   Mitzi-Laszlo

   on May 14, 2019

   Last edited by Mitzi-Laszlo

   Author

   More actions

   How about we try plotting the options and considerations to get multiple perspectives, feel free to add to this liberally.

   Route Forward	Pros to Consider	Cons to Consider
   Include an appendix explaining how the Solid spec terminology links to GDPR terminology	1. keeps the Solid spec purely technical	1. gives the impression that personal data control is an afterthought (few people read appendices)
   Include a diagram at the start of the Solid spec explaining the players and how the interact followed by a short paragraph explaining how the Solid spec terminology links to GDPR terminology	1. introduces personal data control as a core value from the get go rather than an afterthought 2. shows a sign that bridging to GDPR is considered important 3. connects engineers to lawyers who work towards a common goal	(suggest cons)
4. RubenVerborgh commented on May 14, 2019

   

   RubenVerborgh

   on May 14, 2019

   Last edited by RubenVerborgh

   Contributor

   More actions

   Cons:

   • GDPR is not universal law, so text will not be meaningful to non-EU citizens
   • GDPR and law can evolve; the technical spec should not
   • We would be introducing a substantial dependency in a technical specification (not something desirable in general) to a legal document (even less desirable, because then the audience becomes restricted to intersection of tech+law)

   There is also no precedent to such a move.

   So I very strongly object; GDPR is not a technical matter and does not belong in the technical spec.

   Happy to think about a separate note (with a EU focus) that ties the technical spec to GDPR.

   gives the impression that personal data control is an afterthought

   Not necessarily, this can be the motivating section of the spec, without a GDPR mention.

   introduces personal data control as a core value from the get go rather than an afterthought

   We can still do this.

   shows a sign that bridging to GDPR is considered important

   We probably should not do this (it's a political statement)

   3. connects engineers to lawyers who work towards a common goal

   A separate note could do that. On that topic, I have this one forthcoming actually:

   Verborgh R., Wrigley S. & Ballardini R.M., "Decentralizing the Web and the Industrial Internet: an Alternative Solution to Data Control" in Ballardini, R.M., Pitkänen, O. & Kuoppamäki, P., Regulating Industrial Internet through IPR, Data Protection and Competition Law, Kluwer Law Int. (Accepted; Forthcoming in 2019)
5. RubenVerborgh commented on May 14, 2019

   

   RubenVerborgh

   on May 14, 2019

   Contributor

   More actions

   Another important objection:

   Solid can be used to address GDPR. But the Web can also be used to address GDPR.
   That does not mean that any Solid solution is automatically GDPR-compliant. This is very new and uncertain legal territory; it is doubtful that we can make any meaningful GDPR claims about Solid in general (only for specific cases).