This also happens on the mailing lists. Here’s a recent example.
This is a good example. Even if you would somehow moderate the thread
away on groups.google.com it would still be visible for all times at qubes-users
It would be nice to have a unified deletion policy across all Qubes
venues. That way we can document it and simply link to that
documentation whenever anyone asks.
That would mean agreeing on a policy that can actually be implemented on
all venues. This includes
mailing lists
qubes-devel
qubes-project
qubes-users
this forum
twitter
reddit
facebook
linkedin
The most restrictive of all those should be the mailing list, where it
is impossible to delete posts other than in the groups.google.com
archive (all other archives will be unaffected).
Equally with the forum (mailing list mode).
In cases of code of conduct violations we will of course use all methods
available on each platform to remove the posts as much as possible.
I must say from the moderation perspective this is the ideal. From the user perspective, let’s see how it plays out. No suggestions from my side.
Checked the settings. New users (tl0 and tl1) can edit up to 24h, all others can edit up to 30 days.
Does this change anything? Should we increase it?
Currently the edit history of the post is public, which would defeat a bit users who would want to “hide” something. This is something we can also tweak (edit history visible to public)
I’m inclined to say we should make the edit history private. As for the time limit, 30 days is pretty long, but unlimited would work better in terms of user self-service.
Checked the settings. New users can edit up to 24h, all others can
edit up to 30 days.
I’d prefer the user not being able to edit at all.
If there is a code of conduct violation the user is unlikely to
correct that themselves anyway and it’s a case for the moderators.
Any other edit muddies the water, since it may change the original
meaning and already made replies may seem out of context.
Keep in mind that edits are invisible to everyone using the
mailing list mode. We see the original post, but no edits.
It’s easy to see that those wishing to avoid the above would then start
to quote the original post in its entirety to bypass eventual subsequent
edits. That would degrade the readability for forum users though, I suspect.
Currently the edit history of the post is public, which would defeat
a bit users who would want to “hide” something. This is something we
can also tweak (edit history visible to public)
If this would be adopted, we would have made the life of the mods easier
but not addressed the central points made by unman, Raphael and myself.
I’m not too fond of the idea of disabling edits. They can be pretty useful and are generally very minor. Github issues also allows users to reply by email as well as editing their posts.
This is not the use case for the edits. Giving the users the power to edit is for them to avoid having to ask moderators for something. This example of yours would instead fall under the moderators’ responsibility do deal with.
I think is a rather extreme case. Most likely people will just be fixing stuff on the messages. And you can always quote the person and that will not be affected by the edit.
Edits are really useful. Typos, adding disclaimers in the OP, small corrections, etc. This is how github issues works as well. In general, small stuff that wouldn’t be too critical if someone were to miss.
And this critique of yours also affects forum users, although a bit less. When they go back to a topic the don’t see it from the top. Instead, they see it from where they last were. If someone edits the first post, they will likely miss the change as well.
Maybe this edit or not to edit should have its own discussion?
edit: Also, emails of posts only ship 5 mins after they are posted so any changes done until then will be included in the email.This last paragraph is one such example
For what it’s worth, I think edits should be enabled for contributing users, but disabled for new users.
On another Discourse forum I admin, we have a lot of spam, and disabling TL0 and TL1 edits makes it much more manageable. (as well as disabling the allowance of TL0 posting links)
I don’t tend to see people going through and wiping their posts with edits, nor with deletes. Our only requests tend to be GDPR related account removal requests, where a simple anon is not acceptable to the user. However, we license all user contributions (threads, comments, images) under Creative Commons to the LLC that hosts the forum, so there’s a different story there. Might be worth looking into that to avoid potential issues with GDPR.
Lastly, to clarify what the “anonymize user” button in the admin panel does; the following actions are taken:
new username is assigned to the account such as anon123456 (I suggest making a staff note of the user’s former name prior to pressing the button)
Mentions are updated
Quotes are updated
All Posts are updated
Email, Name, DOB, Avatar removed
Profile removed
All API keys revoked
All authentication mechanisms removed
The following information is retained:
IP history
Likes
Posts and post contents
Link clicks
Post “read” status
Badges
Staff Notes
DMs and contents (although, only DM participants and Admins can read those messages)
I realize now that this is slightly off topic, but I thought I’d address it considering there seemed to be a bit of uncertainty surrounding it.
That sounds terrible. IANAL, so I don’t quite understand how the GDPR works here in practice. If a user requests deletion, and we simply reply with our non-deletion policy, what happens? The Qubes OS Project is globally distributed and not headquartered in any one country.
They’re usually complaining in bad faith or have serious paranoia, so it’s frustrating.
It’s complicated and I don’t fully understand it’s global implications. I’m not a lawyer either, but everything I say from here on is my understanding from speaking with a US based lawyer. I’m skimming the emails from our discussion back in 2018 while writing this.
The GDPR Article 17 that we’re concerned with, “right to be forgotten”, provides individuals, or “data subjects” with the right to request erasure of data relating to them. Controllers (as in data holders, like Discourse forum administrators) are required to erase personal data “where the subject objects to legitimate interest-based processing and the controller does not have an overriding legitimate interest.” Which doesn’t clear anything up at all. What is an “overriding legitimate interest” and can we make use of it? Nobody really knows, even still.
There’s a 3 clause test that can be applied to the “legitimate interest” clause:
Purpose test – is there a legitimate interest behind the processing?
Necessity test – is the processing necessary for that purpose?
Balancing test – is the legitimate interest overridden by the individual’s interests, rights or freedoms?
So, let’s run through the test against my user, for example:
What is the purpose behind keeping metalspork’s data?
Keeping knowledge that was previously shared with the public, for the benefit of the public Is metalspork’s data necessary for this?
Yes, without metalspork’s contributions, people would not understand the context of some threads. Is the interest of public education overridden by metalspork’s interests, rights or freedoms?
Ask the judge?
It seems that the first two clauses are in the favor of a forum keeping a users posts. The last clause seems to be very much up to the presiding legal authority as to which way it swings. Considering the anonymization feature removes all PII, it seems that unless the user voluntarily gave their personal information, (for example “My Name is Boris Johnson, I live at 10 Downing Street, London”) that the forum would hold any other identifying information.
All that said, Paragraph 3 states:
Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:
(a) for exercising the right of freedom of expression and information
Which could mean that if someone is sharing knowledge on a forum, the right to be forgotten is null and void, but I am not a lawyer. This is just plebeian interpretation.
It seems that Paragraph 3 tries to lay out some examples of how the final clause in the test should be interpreted. However I’m not certain what counts as “freedom of information”
As an aside, the forum I administer has threads where people post lots of pictures. Some cameras include GPS tags and other metadata that could be considered PII. There’s a setting in the admin panel called “strip image metadata” that we’ve enabled both to protect us and our users. This doesn’t stop someone from uploading a picture of their face though.
At the end of the day, a non-EU based organization is not subject to GDPR, but they might wind up having issues if they try to do business in the EU and are non-compliant, so there is definitely incentive to put a good-faith effort towards compliance.
In my quite frank opinion, GDPR was designed with good intentions but the way it’s written, it’s almost entirely unenforceable without taking every company in existance to task for violations. Unfortunately, no matter what you do, discourse will have logs of data. If you’re hosting on a next-gen filesystem like ZFS/BTRFS, you’ll have snapshots. If you’re taking normal backups, you’ll have users data in there. Basically, GDPR is counter to sysadmin best-practices and it causes me a lot of headache on my day-to-day even though I don’t reside in the EU or work for an Europe-based company.
If you’re concerned about being fully GDPR compliant, you might want to reach out to an open-source friendly organization like the EFF for their advice. If the EFF can’t provide advice, they might be able to point you in the right direction.
As you can see, there’s a lot of questions still. My current policy is to act in good faith, and if users want PII removed, I’m more than happy to do so. If users want something embarrassing removed, I usually don’t do that, unless they make a good argument as to how it can effect material harm to them. (ie: one user had an employer find his account and didn’t hire him due to being a bit of a troll. I don’t think goofing around on the internet should mean you can’t get a job)
I can play a bit fast and loose with the rules since the LLC our forum belongs to has no holdings and does little to no business in the EU, but that’s where I stand after talking to a lawyer.
We’re sorry, but your email message to [“qubes_os+2c41aa683581096843a5a5f6282fe073@discoursemail.com”] (titled Re: [Qubes Forum] Setup with Custom LUKS Configuration: Boot Loader Install Failed [User Support]) didn’t work.
The topic you are replying to no longer exists – perhaps it was deleted? If you believe this is an error, contact a staff member.
Now this is just the sort of example where deletion is bad, besides
the fact that the Forum has missed out on yet more words of wisdom from
me.
A user had a problem, presumably solved it, and then deleted the post. I think they didnt follow the instructions carefully, but maybe not. But
it could have led to a discussion about how to boot from encrypted
/boot, alternative boot strategies, and so on.
I’m not EU based, but we work significantly there.
An individual has the right to have their personal data erased if it is
no longer necessary for the purpose for which it was originally
collected or processed.
But this relates to personal data - and that is set out in the
regulations - posts to a forum/emails are not included in any category I
can see, and unless “metalspork” is a given name (which is, frankly,
enough to identify you uniquely, though metalspork Sr might disagree),
there’s no problem here.
Of course, if users started to post in the forums with sigs containing
name, Address, LinkedIn profile etc, that would be a different issue.
But being able to edit them. (e.g. keeping the current 24h for new users and 30 days for new users?)
Hidden edit history
If this is the consensus, I’m opposed - I don’t use the Forum, but have
seen similar - if users can EDIT content , as opposed to ADD edit
comments, imo they become far less helpful.
Example:
Post -
Debian templates don’t have packages, and are unusable in Qubes.
Long discussion follows about reasons for this, and benefits of having a
small fingerprint, how you install packages, and so on.
Edit -
Debian templates are amazing, and the best thing in Qubes.
Now anyone who looks at a Debian qube and is puzzled, will likely not
pursue that thread, will they? Although it will address many of the
issues they are likely having.
If I don’t understand how the forum works for Web users, I’ll edit this
comment so as not to appear an idiot - after all, I don’t want to be
embarrassed. /s
This policy makes sense. It’s important to note that TL4 and Moderator/Admin can see edit history, and Moderator+ can roll back edits if needed, by default settings.
I haven’t seen much of that either here or on my forum.
I would recommend making that sort of edit a forum policy violation and maybe give the user either an official warning (mods can do this through DM, then check the box that says “official warning”) or issue a temporary suspension for such violations?
I know that simply making something against the rules doesn’t stop the frowned-upon action, but it will make people who want to actively participate in the community think twice.
Ok, I’ve been persuaded against the edit history being private. I’m fine with public edit histories and a short edit window. I’m also fine with disabling edits for new users.
I share unman’s concerns completely and would very much prefer if there
is no edit and no delete and we can all talk like adults and not go back
on our words.
I am glad we all agree on disallowing delete: that’s a good step to
restore sanity (no more disappearing threads).
When it comes to edits I see great harms on the one side (see unmans and
my previews explanations) and a minor convenience on the other (ability
to correct spelling essentially, any other edit is harmful to the
discussion).
Other than spelling corrections I see no case that would better be
served by a reply to the original post.
Code of conduct violations (intentionally or accidental) are a case for
the moderators.