- gdpr-discuss - earth.li

Might the product be unwanted?
by tka00＠hotmail.com 25 Dec '23

25 Dec '23

I do not know if this is the right place for this. My intentions with this post is to share some very specific information. What you conclude from it is not for me. I share it as a way of letting it go for me personally (it is out of my hands now). It is documents from the EU about AI among other things. https://drive.google.com/drive/folders/1EnDpyEFXrMVBbulF3yd6A2v0ObIxdva9?us…

1 0

[article] GDPR: Biggest pain points, now and later
by VM Brasseur 28 May '18

28 May '18

https://enterprisersproject.com/article/2018/5/gdpr-biggest-pain-points-now…

5 13

Git and the Right for Rectification
by Jonas Wielicki 26 May '18

26 May '18

On Montag, 21. Mai 2018 17:57:42 CEST Winfried Tilanus wrote: > Git has the pressing need of > maintaining code integrity and traceability. The final decision will be > up to a judge, but my bets are on the need of maintaining the code. > Something similar will be the case with Bugzilla. So I was wondering about Git and the Right for Rectification. In contrast to the Right to be Forgotten, the Right for Rectification, does not have any exceptions I am aware of. Now what if somebody commits code to a Git repository (so the commit includes their name and email address) and they change for example email addresses. In that case, from my understanding, the Right for Rectification would trigger and the controller of the Git repository may be forced to rectify the information. This would require re-writing all history since that commit, which is a huge issue. One argument against that which I heard that: - The email address was valid at the time the commit was made and is thus an accurate representation of the history at the time the commit was made (which is timestamped) and thus doesn’t need to be rectified. - It is expected that the user would provide accurate information and if they, for example, have a typo in e.g. their name in the commit metadata, it is kind of their fault and this does not need to be corrected. Do these counter-arguments make sense or is this a real threat to Git? kind regards, Jonas

14 27

Summary of GDPR Concepts For FOSS Communities
by Michael Dolan 25 May '18

25 May '18

(If you're on this list, I assume you're already well beyond the basics, but...) Since we've spent 6+ months of time investment getting ready for GDPR at The Linux Foundation, it is apparent other FOSS communities may benefit from a summary of key principles of GDPR and covering some FAQs. At the last hour before GDPR takes effect, we tried to put together a summary and included lessons learned as we went through various scenarios and examples. I thought someone may find this helpful or make it easier to share with communities that have less knowledge on the subject so they can get up to a basic understanding. https://www.linuxfoundation.org/wp-content/uploads/2018/05/lf_gdpr_052418.p… Please feel free to pass along. Thanks, Mike

2 1

GDPR abuse ?
by TJ 11 May '18

11 May '18

Thinking ahead, services could suffer Denial of Resources/Services attacks via: 1. Repeated join, post, 'request deletion' from individual or multiple data subjects acting in concert. 2. Individual data subjects may join, post, 'request deletion' to multiple services simultaneously. Because the 'deletion' data is PII that should make it possible to identify these activities either by single services or services sharing intelligence. That brings up an interesting issue. In order to operate effective anti-spam measures to deal with this, data controllers/processors would need to retain some PII. That retention would likely come under the heading of 'needed to operate the service'. Hashing the identity items individually (email address, nick-name, real-name, telephone, etc.) would mean the anti-spam data was anonymous. The only time it could be linked to an identity would be when the data subject tries to join a service or request deletion using the same data. Which brings up the other difficult issue with casual pseudonymous services: verifying the requester is the data subject.

2 1

Undeleteable data
by Daniel Stone 11 May '18

11 May '18

Hi, We've been looking into GDPR compliance for fd.o, which has been ... fun. The biggest stumbling block for us is probably Bugzilla and Mailman. Deleting messages and profiles from those just isn't practical for us, especially at any kind of scale. We could write a script to censor those, but once it has been posted to either, then it's all over the public internet anyway. We don't control distribution once messages hit Mailman - it's forwarded raw to a potentially unlimited distribution list - and deleting messages from Mailman is also a manual nightmare. Rebuilding the archives is out since it breaks URLs. Hand-editing it all sucks beyond belief. And then people have quoted it in replies anyway ... Does anyone know if there's some kind of GDPR 'out' for, 'by posting here you agree that everything is going to be made public, so as there's nothing we can do about its distribution, it's not useful or practical for us to undo that'? And are there any kind of credible Bugzilla/Mailman deletion tools? Cheers, Daniel

7 14

impact on volunteer services
by Peter Saint-Andre 24 Apr '18

24 Apr '18

Has anyone here looked into the impact of GDPR on volunteer services like the Chaos Computer Club or small teams (not legal organizations) running decentralized communication instances? Peter

4 7

GPDR on the BadVoltage podcast
by Chris Lamb 19 Apr '18

19 Apr '18

Hi GPDR-discuss, The latest episode of the Bad Voltage[0] podcast discusses the GPDR from about 43m37s. A direct YouTube link to the whole section is at [1]. It is obviously not lawyer-level wrangling (!) but perhaps interesting -- and light-hearted -- enough to share. [0] https://www.badvoltage.org/ [1] https://www.youtube.com/watch?v=n35jUI12rTo&t=2554 Best wishes, -- ,''`. : :' : Chris Lamb, Debian Project Leader `. `'` lamby(a)debian.org / chris-lamb.co.uk `-

1 0

Deletion of Data
by Ben Cooksley 15 Apr '18

15 Apr '18

Hi all, Sorry for starting a new thread on this one, but I thought it would be a good idea to gather the methods for deleting data we know of as something separate from the current "undeleteable data" thread. The following is what i'm aware of that we do at KDE: Bugzilla: We merge the account to be deleted into an single anonymous account (null(a)kde.org). This erases all the PII collected from the user (name, email address, etc) as the data from the anonymous account takes it's place. The history also gets merged in with the anonymous account (and thus mixed in with that of every other account which we've removed). The only thing which does get kept are the posts made by that user, which are as far as I am aware outside the scope of GDPR. There is already a script shipped with Bugzilla, contrib/merge-users.pl for this. Mediawiki: We merge accounts here as well, same thing happens as Bugzilla. The edits stay behind but the user's details are erased forever. You can use the UserMerge extension for this. Only place we might fall short are User: namespace pages if they've used these - while these can be purged using RevisionDelete I don't think this actually destroys the information (just hides it from everyone except those with revisiondelete permissions) phpBB: It has functionality to allow accounts to be deleted, so you rename the account to something like "AnonymousAnimal" then delete the account, ticking the option to keep posts. It's an included part of it's functionality. The only "identifying" thing left behind is the name of the account (hence the rename before you pull the delete trigger) Drupal: It has integrated functionality to let you cancel accounts - as part of this process you are given the option to transfer the content it created to the "Anonymous" user then delete the account (effectively equivalent what we do for Bugzilla) Wordpress: Same situation as Drupal, it's account deletion option let's you transfer the content it created to another user. Nextcloud: Lets you delete accounts freely from the web interface if you are a Super Administrator. Destroys everything owned by the account for good measure. Traces of information in shared files they'd worked on would be the only concern here, for which we'd have to manually check everything they had access to (given the myriad forms data can come in, manual checks are the only way to do this in reality as automatic mechanisms are bound to miss support for one or more types of file). Phabricator: Unfortunately it does not support merging of user accounts, and upstream strongly warn you against deleting data (they don't support it). There is a tool to do it for data including user accounts however this isn't really a solution because the history of actions taken by that account can still be reconstructed from the transaction logs kept by Phabricator (which can be freely accessed by anyone with an account via it's Conduit API) At the moment we deal with these requests by changing the username to something anonymous and removing all other profile details which are personally identifying. This does leave the users activity history, but is otherwise a fairly complete removal and doesn't run the risk of breaking parts of Phabricator. I'd be interested to know folks thoughts on user account merging as a solution to the problem - and whether they think any of the above aren't sufficient for compliance. Historically we haven't seen any user profile information survive account merges. Cheers, Ben

1 0

impact on anonymous services
by Peter Saint-Andre 13 Apr '18

13 Apr '18

Some online services enable completely anonymous communication and don't know where their users come from (e.g., swissjabber.ch operates this way). Do we know if the GDPR applies to such services? Peter

2 2

2024

2023

2022

2021

2020

2019

2018

gdpr-discuss