Re: [Sks-devel] Implications of GDPR
On Sun, 29 Apr 2018, 19:04 Ari Trachtenberg, wrote: > > On Apr 29, 2018, at 12:20 PM, Moritz Wirth wrote: > > > The last thing is about data protection - I am pretty sure the data in the > reconciliation process is not encrypted (which would be useless for public > data) but may also be required for data exchanges by GDPR - the same goes > for retrieval over https (which is tbh not really supported) > > > I don’t remember whether sks uses a single-stage or two-stage process for > reconciliation … in a single-stage > process, data is directly encoded as evaluations of a rational function, > so only another peer with similar > data will be able to decode it. > > In a two-stage process, the initial phase is done on hashes, and a second > stage transfers the data corresponding > to differing hashes. It should be possible for the second stage can be > sent over an encrypted tunnel without > too much effort. > And then the data is requested over HTTP unencrypted by the pgp-client or web interface > best, > -Ari > > > Sent from my iPhone > > Am 29.04.2018 um 17:08 schrieb robots.txt fan >: > > Moritz Wirth wrote: > > Given the fact that it is not possible to delete data from a keyserver > > > Of course this is possible. You can delete key by using the "sks drop > " command. Now, if I understand it correctly the key will immediately > be re-added because of gossiping keyservers. However, it would not be > impossible to extend SKS to have a keyserver reject keys from a blacklist > that each server admin would maintain, or possibly gossip. (If this does > not exist already.) > > I imagine this would be a useful instrument for more use-cases than this > one. I imagine a server admin based in Germany would get in trouble if > someone submitted a key with the user-id "The owner of this server denies > the Holocaust", an action that is illegal in Germany. The server admin > could get out of the trouble by adding the hash of that key to the > blacklist. > > I know I am suggesting censorship but it's not like SKS was ever meant to > be a secure or reliable channel. > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > > > --- > Prof. Ari TrachtenbergECE, Boston University > trach...@bu.eduhttp://people.bu.edu/trachten > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
> On Apr 29, 2018, at 12:20 PM, Moritz Wirth wrote: > The last thing is about data protection - I am pretty sure the data in the > reconciliation process is not encrypted (which would be useless for public > data) but may also be required for data exchanges by GDPR - the same goes > for retrieval over https (which is tbh not really supported) I don’t remember whether sks uses a single-stage or two-stage process for reconciliation … in a single-stage process, data is directly encoded as evaluations of a rational function, so only another peer with similar data will be able to decode it. In a two-stage process, the initial phase is done on hashes, and a second stage transfers the data corresponding to differing hashes. It should be possible for the second stage can be sent over an encrypted tunnel without too much effort. best, -Ari > > Sent from my iPhone > >> Am 29.04.2018 um 17:08 schrieb robots.txt fan : >> >> Moritz Wirth wrote: >>> Given the fact that it is not possible to delete data from a keyserver >> >> Of course this is possible. You can delete key by using the "sks drop >> " command. Now, if I understand it correctly the key will immediately >> be re-added because of gossiping keyservers. However, it would not be >> impossible to extend SKS to have a keyserver reject keys from a blacklist >> that each server admin would maintain, or possibly gossip. (If this does not >> exist already.) >> >> I imagine this would be a useful instrument for more use-cases than this >> one. I imagine a server admin based in Germany would get in trouble if >> someone submitted a key with the user-id "The owner of this server denies >> the Holocaust", an action that is illegal in Germany. The server admin >> could get out of the trouble by adding the hash of that key to the blacklist. >> >> I know I am suggesting censorship but it's not like SKS was ever meant to be >> a secure or reliable channel. >> >> ___ >> Sks-devel mailing list >> Sks-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/sks-devel > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel --- Prof. Ari TrachtenbergECE, Boston University trach...@bu.eduhttp://people.bu.edu/trachten signature.asc Description: Message signed with OpenPGP ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
That does not solve the problem with the data deletion - the key id can be tracked to a person and would be therefore considered as personal Information so you would be still required to delete the key id itself. The other big problem is the data sharing over reconciliation and other methods - you need the agreement by the user and all peering partners to do this - so you have to tell the user that you store his data regardless if he uses the website ( which would be easy) or the pgp client and it might be possible that you need the possibility to opt out of the reconprocess The last thing is about data protection - I am pretty sure the data in the reconciliation process is not encrypted (which would be useless for public data) but may also be required for data exchanges by GDPR - the same goes for retrieval over https (which is tbh not really supported) Sent from my iPhone > Am 29.04.2018 um 17:08 schrieb robots.txt fan : > > Moritz Wirth wrote: >> Given the fact that it is not possible to delete data from a keyserver > > Of course this is possible. You can delete key by using the "sks drop " > command. Now, if I understand it correctly the key will immediately be > re-added because of gossiping keyservers. However, it would not be impossible > to extend SKS to have a keyserver reject keys from a blacklist that each > server admin would maintain, or possibly gossip. (If this does not exist > already.) > > I imagine this would be a useful instrument for more use-cases than this one. > I imagine a server admin based in Germany would get in trouble if someone > submitted a key with the user-id "The owner of this server denies the > Holocaust", an action that is illegal in Germany. The server admin could get > out of the trouble by adding the hash of that key to the blacklist. > > I know I am suggesting censorship but it's not like SKS was ever meant to be > a secure or reliable channel. > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
Moritz Wirth wrote: > Given the fact that it is not possible to delete data from a keyserver Of course this is possible. You can delete key by using the "sks drop " command. Now, if I understand it correctly the key will immediately be re-added because of gossiping keyservers. However, it would not be impossible to extend SKS to have a keyserver reject keys from a blacklist that each server admin would maintain, or possibly gossip. (If this does not exist already.) I imagine this would be a useful instrument for more use-cases than this one. I imagine a server admin based in Germany would get in trouble if someone submitted a key with the user-id "The owner of this server denies the Holocaust", an action that is illegal in Germany. The server admin could get out of the trouble by adding the hash of that key to the blacklist. I know I am suggesting censorship but it's not like SKS was ever meant to be a secure or reliable channel. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
Hi Moritz, My understanding is that the section you quoted on the "right to be forgotten" refers to the controller's (i.e. your) obligation to inform _other_ controllers processing the data (in this case: other keyserver operators who, through gossip, have a "copy or replication" of the personal data) about the data subject's request for deletion. "Technical measures" in this context would, for instance, be a way to automatically propagate the deletion to other servers; as this is not possible, you only have to take "reasonable steps" to inform others, like sending an email to your peers. If somebody wants you to delete their data, you will definitely have to delete it, regardless of how difficult this is to achieve with SKS. A whole different issue is how you would get a data subject's permission to process their data in the first place, and how you would notify them about the fact that you are processing their data, both of which are required by the GDPR. Regards Klaus-Uwe On 2018-04-29 13:02, Moritz Wirth wrote: > Hi Fabian, > > first of all, I am not a lawyer so you should not rely on my response as > it may be wrong :) > > - The GDPR applies to all persons and companies who are located in the > EU or offering goods, services or who monitor the behavior of EU data > subjects - this means that all keyservers are affected regardless where > they are physically located. (https://www.eugdpr.org/gdpr-faqs.html) > > - Personal Data includes Names, Photos, social posts, IP-Addresses.. (so > it seems that everything that can be connected to a person is included > here). > > - The Right to be forgotten: People have the right to get their data > deleted if it is no longer necessary in relation to the purpose they > were collected. I think this means that if someone wants to have their > data deleted, you have to delete it - given the fact above that some > keys include personal name or even photos, you would be required to > delete them (even if you are in the USA). However, I am not sure - the > text says "the controller, taking account of available technology and > the cost of implementation, shall take reasonable steps, including > technical measures, to inform controllers which are processing the > personal data that the data subject has requested the erasure by such > controllers of any links to, or copy or replication of, those personal > data." <-- Given the fact that it is not possible to delete data from a > keyserver, I am not sure how this would be handled. (Same applies to for > reasons of public interest in the area of public health in accordance > with points (h) and (i) of Article 9(2) as well as Article 9(3) but I > didnt check on that). (https://gdpr-info.eu/art-17-gdpr/) > > - I heard that you must sign (physical) contracts with data processing > companies (this may also include Google and Google Analytics, I am not > sure about Google Fonts etc but since Google gets your IP...) if you > share the data of your user with them (e.g using GA on your site). > ("Controller will need to have in place an appropriate contract with any > other Controller that it jointly shares data with if that Controller > particularly is outside the EU."). Should not really matter (except for > Google Fonts) - at the end the use of Tracking services is up to the > keyserver admin itself > (https://www.netskope.com/blog/gdpr-data-processing-agreements/) > > The first thing I would do is to include a checkbox in the webtemplate > that every person who queries or uploads a key via the webinterface > agrees to your data policy - in the data policy you should explain what > happens when a key is uploaded, that it is distributed to other > keyservers, (IPs are collected whatever you do) and that it is not > possible to delete keys once they are uploaded. > > If someone has more information on this or something to correct feel > free to do so :) > > Best regards, > > Moritz > > > Am 29.04.18 um 12:24 schrieb Fabian A. Santiago: >> So, >> >> As I understand it, GDPR concerns all EU citizen users of a site, regardless >> of where the site is hosted. How does this affect keyservers? I've seen at >> least one server going offline due to it. Should I be concerned as an >> American keyserver host? >> -- >> >> Fabian A. Santiago >> >> OpenPGP: >> >> 0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key) >> 0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked) >> >> ___ >> Sks-devel mailing list >> Sks-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/sks-devel > > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel -- Klaus-Uwe Mitterer Email: email@kumi.email XMPP: kumitte...@kumi.zone Twitter: @kumitterer Threema: PEBXP4H3 Telegram: @kumitterer Skype: kumitterer Mobile: +43 660 6340166 *** DISCLAIMER *** This document is only inten
Re: [Sks-devel] Implications of GDPR
My short response to all of that is: "meh". Less briefly: Technically, I think you're right. The whole keyserver system doesn't appear to work at all against GDPR. But equally, a _system_ like ours doesn't seem a very likely target of any regulators. The law was mostly envisioned to keep *companies* in line - not a disparate collection of individuals running a service as a hobby. After all, most European countries already had existing individual privacy laws that the keyservers were theoretically already in breach of. I'll personally risk it - but as you note - I'm not a lawyer either. 😉 Regards, Chris -Original Message- From: Sks-devel [mailto:sks-devel-bounces+chris=funderburg...@nongnu.org] On Behalf Of Moritz Wirth Sent: 29 April 2018 12:03 To: Fabian A. Santiago ; sks-devel Subject: Re: [Sks-devel] Implications of GDPR Hi Fabian, first of all, I am not a lawyer so you should not rely on my response as it may be wrong :) - The GDPR applies to all persons and companies who are located in the EU or offering goods, services or who monitor the behavior of EU data subjects - this means that all keyservers are affected regardless where they are physically located. (https://www.eugdpr.org/gdpr-faqs.html) - Personal Data includes Names, Photos, social posts, IP-Addresses.. (so it seems that everything that can be connected to a person is included here). - The Right to be forgotten: People have the right to get their data deleted if it is no longer necessary in relation to the purpose they were collected. I think this means that if someone wants to have their data deleted, you have to delete it - given the fact above that some keys include personal name or even photos, you would be required to delete them (even if you are in the USA). However, I am not sure - the text says "the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data." <-- Given the fact that it is not possible to delete data from a keyserver, I am not sure how this would be handled. (Same applies to for reasons of public interest in the area of public health in accordance with points (h) and (i) of Article 9(2) as well as Article 9(3) but I didnt check on that). (https://gdpr-info.eu/art-17-gdpr/) - I heard that you must sign (physical) contracts with data processing companies (this may also include Google and Google Analytics, I am not sure about Google Fonts etc but since Google gets your IP...) if you share the data of your user with them (e.g using GA on your site). ("Controller will need to have in place an appropriate contract with any other Controller that it jointly shares data with if that Controller particularly is outside the EU."). Should not really matter (except for Google Fonts) - at the end the use of Tracking services is up to the keyserver admin itself (https://www.netskope.com/blog/gdpr-data-processing-agreements/) The first thing I would do is to include a checkbox in the webtemplate that every person who queries or uploads a key via the webinterface agrees to your data policy - in the data policy you should explain what happens when a key is uploaded, that it is distributed to other keyservers, (IPs are collected whatever you do) and that it is not possible to delete keys once they are uploaded. If someone has more information on this or something to correct feel free to do so :) Best regards, Moritz Am 29.04.18 um 12:24 schrieb Fabian A. Santiago: > So, > > As I understand it, GDPR concerns all EU citizen users of a site, regardless > of where the site is hosted. How does this affect keyservers? I've seen at > least one server going offline due to it. Should I be concerned as an > American keyserver host? > -- > > Fabian A. Santiago > > OpenPGP: > > 0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key) > 0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked) > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Implications of GDPR
Hi Fabian, first of all, I am not a lawyer so you should not rely on my response as it may be wrong :) - The GDPR applies to all persons and companies who are located in the EU or offering goods, services or who monitor the behavior of EU data subjects - this means that all keyservers are affected regardless where they are physically located. (https://www.eugdpr.org/gdpr-faqs.html) - Personal Data includes Names, Photos, social posts, IP-Addresses.. (so it seems that everything that can be connected to a person is included here). - The Right to be forgotten: People have the right to get their data deleted if it is no longer necessary in relation to the purpose they were collected. I think this means that if someone wants to have their data deleted, you have to delete it - given the fact above that some keys include personal name or even photos, you would be required to delete them (even if you are in the USA). However, I am not sure - the text says "the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data." <-- Given the fact that it is not possible to delete data from a keyserver, I am not sure how this would be handled. (Same applies to for reasons of public interest in the area of public health in accordance with points (h) and (i) of Article 9(2) as well as Article 9(3) but I didnt check on that). (https://gdpr-info.eu/art-17-gdpr/) - I heard that you must sign (physical) contracts with data processing companies (this may also include Google and Google Analytics, I am not sure about Google Fonts etc but since Google gets your IP...) if you share the data of your user with them (e.g using GA on your site). ("Controller will need to have in place an appropriate contract with any other Controller that it jointly shares data with if that Controller particularly is outside the EU."). Should not really matter (except for Google Fonts) - at the end the use of Tracking services is up to the keyserver admin itself (https://www.netskope.com/blog/gdpr-data-processing-agreements/) The first thing I would do is to include a checkbox in the webtemplate that every person who queries or uploads a key via the webinterface agrees to your data policy - in the data policy you should explain what happens when a key is uploaded, that it is distributed to other keyservers, (IPs are collected whatever you do) and that it is not possible to delete keys once they are uploaded. If someone has more information on this or something to correct feel free to do so :) Best regards, Moritz Am 29.04.18 um 12:24 schrieb Fabian A. Santiago: > So, > > As I understand it, GDPR concerns all EU citizen users of a site, regardless > of where the site is hosted. How does this affect keyservers? I've seen at > least one server going offline due to it. Should I be concerned as an > American keyserver host? > -- > > Fabian A. Santiago > > OpenPGP: > > 0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key) > 0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked) > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Implications of GDPR
So, As I understand it, GDPR concerns all EU citizen users of a site, regardless of where the site is hosted. How does this affect keyservers? I've seen at least one server going offline due to it. Should I be concerned as an American keyserver host? -- Fabian A. Santiago OpenPGP: 0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key) 0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel