Add public minutes for June 2025 MGM (#137)

Author: TheDaemoness

content/_minutes/2025-06-27-public.md

@@ -0,0 +1,64 @@
+---
+title: Monthly General Meeting, June 2025
+author: She
+excerpt: Internal policy about when to use the spamfilter,
+spamfilter upgrades, and guidelines on "security" status for staff.
+---
+
+## Propositions and Motions
+
+There were no propositions or motions for this meeting.
+
+## Other Questions
+
+### Spamfilter usage and features
+
+Libera.Chat has a spam filter module that is loaded on all IRC servers.
+It is possible to opt out of spam filtration with channel mode `u`
+for messages sent to channels and user mode `u` for messages received as PMs.
+Additionally, the spam filter can only inform staff of which user tripped the
+filter, not the contents or target of the message that was filtered.
+
+Spam filtration inherently comes with a risk of false positives, especially
+given that users might quote spam after it gets added to the filter.
+Therefore, it was generally understood that items should only be added to the
+spam filter when nothing else is effective at mitigation, and only with
+strong informal agreement from other members of staff.
+However, prior to this meeting, there was no explicit internal policy for
+when to add entries to the spamfilter. This meeting agreed to create an
+internal policy document for spam filter usage.
+
+This meeting also discussed the possibility of having spam filter
+patterns that cannot be opted out of. Following internal discussions outside
+of general meetings, it was agreed that a `superdrop` flag type should be
+implemented that causes messages to be discarded even when the target
+is `+u`. It was decided that `+u` should still allow the sender to not trigger
+any behaviour that notifies staff of the filtered message.
+As before, private messages to staff would still bypass the filter.
+
+It was also discussed how we should handle client-side exploits in the context
+of spam filtration, such as denial of service attacks exploiting overeager
+antivirus software or remote code execution on scriptable clients.
+It was agreed that both classes of exploits should be filtered, but only
+remote code execution exploit mitigation should use the `superdrop` flag.
+
+### Guidelines around the "security" status for staff
+
+There exists an internal "security" status in our service management system
+that can be applied by the operations team in case of a security breach.
+When applied to a staffer, they are stripped of most of their privileges
+except for their reduced IRC connection limits, their email account,
+and access to a shell account on an internal server.
+
+There hasn't been a need for this status to be applied so far, but
+an item was added to the agenda to draft internal policy for its use.
+It was quickly agreed that no explicit internal policy for using this status
+is necessary at this time. It was, however, suggested that if the operations
+team uses this status, they must notify the board.
+
+It was also mentioned that applying the status as-is could potentially
+violate bylaws, as members with the security status are still members of the
+organization but would not have access to the mailing list through which
+general meeting invites are sent. It was agreed that those under this status
+should be able to keep their access to the mailing list, as the operations
+team can simply remove their email access if it is being abused.