I think Etherpad Lite is not GDPR compliant

[devnull4242]

I think Etherpad Lite is not GDPR compliant because of:

Individuals have an absolute right to have their data deleted (right to be forgotten)

Please add the possibility to delete all old entries of an etherpad. Thanks.

[SamTV12345]

You can delete Etherpads via the admin panel for this. There is also the possibility to move a pad to one revision. Is there anything else we could do to improve the GDPR compliance?

[devnull4242]

I think the user must have the possibilty itself. I think that is not possible.

I also don't know why such a basic function is not simply built in. When I have finished working on my Etherpad with a few people, the result and the way there is nobody's business. And if I really need it, I can also export it. And if I don't want to delete it, I don't need to delete it.

[SamTV12345]

I think the user must have the possibilty itself. I think that is not possible.

I also don't know why such a basic function is not simply built in. When I have finished working on my Etherpad with a few people, the result and the way there is nobody's business. And if I really need it, I can also export it. And if I don't want to delete it, I don't need to delete it.

So you'd like to delete the Etherpad yourself. Who should be able to do that? The one that created the pad? If we allow anybody you could have trolls on the public instances that just delete all pads over and over again.

[matthias-mader]

For GDPR-compliance it's not necessary that the user is allowed to delete their own data. Art. 17 provides you the right to demand the deletion of your (personal) data, but doesn't require that you're able to do it yourself.

[SamTV12345]

For GDPR-compliance it's not necessary that the user is allowed to delete their own data. Art. 17 provides you the right to demand the deletion of your (personal) data, but doesn't require that you're able to do it yourself.

So as long as the user hands the pads he worked on to the pad admin they can be safely deleted.

[devnull4242]

So you'd like to delete the Etherpad yourself. Who should be able to do that? The one that created the pad? If we allow anybody you could have trolls on the public instances that just delete all pads over and over again.

I don't think anyone can guess Etherpad names unless you take "test" or "12345".

Conversely, I once created an Etherpad https://etherpad.wikimedia.org/p/6701. Of course, only those who know it write there. However, I think it is completely unrealistic to contact. For Wikimedia you can use https://phabricator.wikimedia.org/maniphest/task/edit/form/75/ but you must register with e-mail first. But what about other etherpads? It is also the case that you usually edit in a group and when you are finished, the content is really nobody's business anymore. Also not for trolls. ;-)

At https://yopad.eu "The authorisation must be clearly proven and justified by the user, for example in the case of violations of human dignity or personal rights." That's not correct. According to the GDPR, everyone has the right to be forgotten.

Individuals have an absolute right to have their data deleted (right to be forgotten)

In the end, of course, the question is how to interpret GDPR and perhaps it will also be fulfilled in theory ... theoretically.

I don't understand why this function can't or won't be built in. Only someone who has access to the pad and can edit it will delete the pad including the history.

I will probably continue to use "Nextcloud Text". Both self-hosted and on a managed Nextcloud. There, the user can delete their data themselves. However, I find Etherpad e.g. Etherpad Lite far better in terms of function.

[dcht00]

First of all, I am not a lawyer, so everything I write here is only my understanding.

This seems false:

Individuals have an absolute right to have their data deleted (right to be forgotten)

Simply put "personal data" in GDPR is not data by person, but about a person. Furthermore, this data needs to be processed in some way to fall under GDPR.

https://gdpr.eu/eu-gdpr-personal-data/

GDPR does not at all regulate Bob's right to have his (let alone others'!) contributions to some generic pad deleted.

[dcht00]

I guess the situation changes if some pad would include identifiable information about Bob. Written by either him or anyone else.
Say, a subscriber list with Bob's email, questionnaire with his full name, or some sort of a phonebook on a pad.

In this case, the GDPR rights (to be forgotten, to update inaccurate/incomplete information, etc), would probably apply.
The question is, whom should carry them. If I am running a public pad server, does it apply to me, or to the pad "administrator"?

I suppose this depend on the specific instance.
A) If the pad (and the authors) can be associated with the pad instance directly, I can imagine it's the instance's responsibility.
B) Otherwise, if this is a public instance, it should be the primary responsibility of the initiator of the pad's. The instance should simply offer an email address to handle disputes.

In the case of A, it's not so complicated — technically, you could settle it with an info banner either upon opening the pad, or possibly somewhere outside of it.
↓↓↓
I propose a simple way to put up a welcome banner (through settings.json), and to draft something GDPR-legit.

In the case of B, it could be a bit more complicated, and additional Etherpad functionality could be needed.
↓↓↓
A possible solution would be to somehow define the role of a pad owner, which would have the responsibility to uphold GDPR for that specific document.
Through:

• ability to delete the whole pad,
• nuke the version history,
• and also transfer/share pad ownership.
• this could be done simplest with a key, acquired on creation.

I think this could be implemented through the Etherpad's new API token way, or the old "group" part of the API. But I don't know much about either.

---

If going forward with this, I would try figuring out how Google Docs does it. I've looked a bit at it, and talked to ChatGPT about it. I agree drafting some sort of a guideline could be helpful, though personally it just feels weird to poke at this too much.

[devnull4242]

Thank you for your answers. Maybe I am using Etherpads completely wrong, unlike other people.

I see Etherpads as a collaborative platform for several people. If I now create an Etherpad (most with a complicated name), exactly those people will work on it to whom I have given this name.

Overall, the Etherpad has a lifetime. Today you can specify when this Etherpad is deleted, e.g. after a day, month or year. However, I think that when the collaborative work is finished, you should also be able to delete the pad manually. I also see no reason why anyone who has previously received the name of the pad should not be able to do this.

Manual deletion can also be useful if confidential data has been copied in by mistake or the name of the pad has become known to third parties, e.g. through an incorrectly sent email to the wrong person. But of course. Of course, you can also bide your time or hope that you reach an administrator.

[q2apro]

nuke the version history

+1 👍 for this

Today you can specify when this Etherpad is deleted, e.g. after a day

What version and where is the setting? I am still running Etherpad docker 1.9.6 and there is not such an option to find.

[n-bux]

nuke the version history

+1 👍 for this

Today you can specify when this Etherpad is deleted, e.g. after a day

What version and where is the setting? I am still running Etherpad docker 1.9.6 and there is not such an option to find.

https://github.com/ether/etherpad-lite/releases/tag/v2.2.6

[SamTV12345]

It should nuke the complete pad all messages, text, complete history.

[SamTV12345]

It should nuke the complete pad all messages, text, complete history.

[n-bux]

as asked on Discord:

Hi, I am just testing the new v2.2.6 with the delete pad option. Does the check if a user is the creator of pad (and thus allowed to delete pad) rely only on the cookie set in the same session of creating the pad? or is there/will there be the possibility to link it to a authenticated user?

because if only cookie, no user will be able to delete a pad once the cookie is gone/user has no access to device she created the pad on.

[devnull4242]

Thanks for the the change from the program. But i think it is not finally ok.

Issue: #6730
some code (e.g. line 230ff): https://github.com/ether/etherpad-lite/blob/master/src/node/handler/PadMessageHandler.ts

I don't know exactly how the creator of the pad is saved (cookie?). But I would prefer it if anyone who has access to the pad could delete it.

I would justify this by saying that every person who has received the link has read and write access to the content. In my opinion, this also includes deleting all history.

This function will lead to complex names being used in a similar way to Nextcloud shares (https://cloud.server.tld/s/abcdefghijklmno) and these only being shared with the people who actually need access (nowbody guesses abcdefghijklmno) . In addition, simple pads with the name test (compare https://cloud.server.tld/s/test) would then no longer be used for actual productive work, as anyone could delete them at any time.

I think it's good that the option has been built in. However, I would be pleased if the deletion function were reconsidered.

[n-bux]

I see your point, and agree with it in some usecases for Etherpad. But consider the usecase were a teacher uses the pad with his/her students. Especially students in younger age can be pretty trolly, and could easily destroy the work of the whole class/preparation of the teacher.

Second: users also do mistakes (click on the wrong button).

So maybe it could be an option in the settings: allow deletion by all users: true/false, so the admin can decide for her instance of Etherpad

[devnull4242]

I can partly understand the problem of the school class. Although this is certainly not always the case and not every risk can be eliminated in IT.

So maybe it could be an option in the settings: allow deletion by all users: true/false, so the admin can decide for her instance of Etherpad

I find the proposal to allow or prohibit the possibility of deletion by all users for each instance problematic, as the decision may be difficult to make common for all pads of the instance.

Perhaps deletion could take place via a password that is only visible the first time the corresponding menu item is called up. This would avoid the problem with cookies, as by default only the creator has the option to delete them and can also pass the option (password) on to other people.

[q2apro]

+1 for only pad creator can delete the etherpad, not somebody else. Via an initial password is a good idea.