Sensitive content warnings
This is a bit of a prickly issue at best, but a consensus was reached with discussion on the fediverse for my proposed system to make spoilered/CWd/whatever messages read as follows:
This text is shown to everyone #nsfw (or #cw) This text is shown only to people who click through the spoiler (or those who have spoilers disabled)
This degrades very gracefully compared to existing systems since the text and content warning itself are preserved in full.
This can also be expanded, by allowing a user to select a hashtag or hashtags that are automatically spoilered for them, by putting them in a list in their profile settings.
Server tagging is also an idea we discussed that we can further expand upon once this baseline feature is added.
Hi! I have made a design proposal for how to implement this feature, including mockups.
I have two understandings of your idea, and I'm going to make mockups for both and weigh pros and cons. To start, here is a mockup for the user-facing end regardless of whether you implement A or B.
Having a user think to manually make a linebreak, write a hashtag, and then another linebreak, is not entirely easy to communicate to a new user. It could also easily be triggered accidentally.
Presently, the post you send looks something like this on non-user facing end.
<status> <text>Howdy!</text> <truncated>false</truncated>[...] </status>
If I add linebreaks it is sent like this:
<status> <text>Howdy! <br> I'm Shel</text> <truncated>false</truncated>[...] </status>
So if you send a status with a sensitive content warning, with your current plan, the status sent to other servers is
<status> <text>Warning <br>#cw<br> I'm Shel</text> <truncated>false</truncated>[...] </status>
So the plan, then, is that on the user-facing side, some sort of reg-ex would recognize
<br>#cw<br>and replace it with the "Show more" button and a collapse.
Given that users are not manually typing
<br>or shown that either, it stands to reason that other elements can be inserted into the xml object without a user seeing it when they compose the post.
This design piece is essentially lifted from Mastodon. Blacklemon did a good job designing the UX for it so I don't see an issue taking a note from her book.
User clicks "CW", extra box appears to type in their content warning. The xml object has the warning marker inserted into it without the user having to think about what that looks like to others, since we know that it looks fine.
Here is where you have an A and a B direction, each with its own pros and cons. B has a B.1 and a B.2 option as well.
Option A: Essentially Mastodon (but inter-operable)
In option A, the element in the XML object representing the break for a content warning would not be a hashtag. Something like
---cw---would be inserted instead.
The user has written their warning in the top box, and a show more button will reveal the rest.
The only different between this and the Mastodon implementation is that in the XML object the content warning will display for users not on postActiv. It would be rendered as something like this.
The reasons to go for this option is that often users use CWs to hide context that is personal. At least in my experience on Mastodon, the most common CW users use is "mh" for "mental health." Meaning "this is me venting about my emotions." Using hashtags for content warnings would result in a curated timeline of users talking about their mental health and negative feelings. This is definitely a safety hazard and not an expected behavior of users who are using CWs to intentionally make their posts less visible. Likewise I could see harassment resulting from users making CW'd posts tagged things like "Gender feelings" "Dysphoria" "Racism" etc. and having those posts then curated for someone wishing to find everyone posting personal content which would otherwise be lost in a sea of posts.
Another reason to go for this option is that it is simple. Users have already written their warning before the cut. It's intuitive that you type your warning and that's it.
A reason against going with this option is that it is not as expandable. As you mentioned in your OP. Spoilering posts with hashtags would not be able to integrate with this option seamlessly.
Option B: Contextual Hashtag CWs
In this version, the string inserted into the XML object is a hashtag, rather than option A's
A user writes their message and adds a hashtag, or even just adds a hashtag. It can be rendered in one of two ways, with minor differences.
B.1 is "elegant" but it may not be entirely clear that it is a button to expand a post, rather than just hashtag highlighting. I'd lean towards B.2 myself.
Here is Option B expanded for a pA user
And here is how that shows up for someone not on pA
If a user does not include a hashtag in their CW box, then it should render to the pA user the same as Option A, with a "show more" button, and would render to the non-pA user like this
The reasons to go with option B is that it is expandable. Users are being encouraged to tag their posts, a la tumblr, which then easily facilitates a feature to spoiler certain hashtags/keywords automatically. It also tells non-pA instances what the sensitive content is, so that they can decide to deal with it however is appropriate in their software.
The reason not to go with option B are the aforementioned harassment concerns, making e.g. mental health posts easily searchable; and that both tagging a post and writing text before the cut is semi-redundant. "This is lewd,
#nsfw" is more work than most users would probably want to do and it would end up defaulting to option A most of the time anyway. It's also not the most intuitive to both describe and tag a post. This could result in both creating a safety concern but also effectively not implementing the advantageous parts of option B. Either users would not put tags in the CW field, and then they aren't tagging posts and the feature doesn't expand; or they do, and then they can be searched. It certainly gives choice and flexibility though.
Another minor difficulty is detecting whether a post is intended to spoilered. What is being looked for? Is it specifically a hashtag between two linebreaks? Will the XML object be marked in some way? With
---cw---it's going to only occur for one purpose. With a hashtag a user may just be tagging their post without an intention to spoiler it. For instance, I could easily imagine a post along the lines of
The hashtag is a joke, but if simply having linebreaks and hashtags triggers the spoiler, then it would spoiler out the word "Now", which is not expected behavior.
I'm not sure whether A or B is better, personally. A feels safer and more elegant, but it doesn't degrade as nicely since it doesn't tell other servers what the warning is. It also can't be expanded like B can. B is expandable and degradable, but my safety concerns weigh heavily against it.
I think that if #38 is implemented in a way which allows users to not have their posts show up in searches (such as Mastodon's "private" and "unlisted" scopes do) then it would be safe to implement option B, as users who do not wish to be searched can opt-out, and their
#mhposts wouldn't be showing up in searches. Option B does also give users the option to not use a hashtag, so rather than
#mhposts they'd just be
mhwritten untagged beforehand, which is better but still not as desirable as simply opting-out of being a searchable hashtag.
One thing to consider is interoperability with Mastodon. This system is more easily degradable than Mastodon's, but is also a competing system. pA users will continue to get uncensored NSFW/Sensitive content from Mastodon users, and vice versa. With #97 being slowly chugged along in both Mastodon and pA, there may be a need for standardization coming for some features, such as notice scopes. I know that Mastodon and pA don't often play nice but finding a way to read Mastodon's
<summary>tags (or is it
<content warning="">still?) and render it as pA CWs would be really useful. If there is an option to implement how Mastodon renders CWs in the XML object, but modified such that it better degrades to GNU Social and StatusNet, that would be ideal for simplified cross-compatibility. pA users would see Mastodon CWs and Mastodon users would see pA CWs, rather than each type of node sending un-spoilered NSFW content back and forth. This of course also requires Mastodon's cooperation, ideally implementing the same degradability modification and recognizing
#nsfwfrom GS and hiding those images. While Mastodon is not well known for being cooperative and caring about interoperability, Mastodon still makes up a significant chunk of the fediverse at this point, and may soon be one of the first types of nodes to implement ActivityPub on a large scale, which will set precedents for how things are done. Right now I'm aware that there has been a bit of an upheaval in Mastodon development and if it goes anywhere that stubborn-ness might change. A couple forks are also working on implementing interoperability fixes, which may be able to be merged back into Mastodon Prime, or may be adopted by many instances running those forks.
So then, A. Copy Mastodon's user-experience with a degradable implementation invisible to pA users? B. Implement an expandable new system with its own unique advantages and potential or C. Attempt to modify Masotdon's back-end implementation to be more interoperable
There's a few component thoughts to pick out here, so time for some headings I suppose!
Searchability of Tags
This is a pickle, honestly, but I think trying to solve this on the technical level is kind of the wrong approach. Allow me to expand, if we hide/suppress the hashtags that a CW uses, then people using hashtag filters as the "low-tech" solution to CW/content filtering get left out, and you're doing it because of bad actors. While we should try to keep tools away form bad actors as both a social and security concern, we aren't going to be able to stop them from searching for this data, since it needs to be exposed at a federation level. I think the proper approach here is for instances to moderate their userbase according to their social norms.
I do think it could be useful for admins to have something in the admin panel to see if a user is frequently searching given tags, though, this would help highlight abusive people, and seems a reasonable compromise.
Personally I think B.2 is the best way to go about this, and it allows us to have multiple CWs in a way that makes it evident they're all part of the overall content warning header.
The less I comment on mastodon specifically, the better I'm probably going to be, I think everyone and their dog and their dog's dog know that I have my personal grievances with Mastodon's development team, and Eugen specifically. That alone, however, is not a reason to break interop where we can.
However, I just don't like Mastodon's way of going about this. It isn't recognized by anyone and people on other instances are going to be confused by this - it just appears as a normal notice on our servers, and also on Hubzilla, et al, when I checked.
My thoughts on this are to have it one-way: we read the mastodon format for the CWs, but we convert it to our own format. This preserves our own advantages (degrading well) - and also has the advantage that if our version of the notice federates then it will degrade to a readable CW format.
While having a UI is a good idea for most people, I think being able to shorthand it as I originally describe is a good idea, because then we are accomodating another segment of the population as well. This is a consideration more the 'FOSSy' and 'infosec' part of the community - they like to think in scripts and formats. So if they can just plug something like this into a notice, and we automagically convert in the backend into our CW notice format, then this eases adoption for many of the people who have been resistant to adopting these practices, which I think is a plus.
Good idea from fl0wn from SLC/FZP to add:
It would probably be a good idea to have it so instance admins can auto-tag their instance under certain CWs. So for instance, a political-discussion instance could have all their posts tagged with a "politics" CW before they are sent to other servers. This would make it much easier for everyone involved: individual users don't have to tag their posts for every single post, and the wider fediverse gets their CW tags :)
Typically my design sensibility is to create systems which limit to capability for people to harass, so that we don't have to depend on some kind of agreeable definition of what constitutes good behavior. I also take into consideration behavior of users from outside communities, who we cannot expect to control the behavior of. My main concern is of lolcow forums [who have "voldemort bots" that keep you from saying their name w/o being targeted for harassment] who often specifically seek out users using heuristics. For instance, on tumblr users were tagging posts "cw sexual assault", but then lolcow-forum-users would search for "cw sexual assault" and find all of the sexual assault survivors on tumblr posting about their experiences and target them for harassment. Typically they wouldn't even interact with the user from tumblr, but instead would collect information on them and their general online presence which they would post in their forums, and eventually they would doxx them and they would receive harassment off-site. While a lot of us adults know how to protect ourselves better, a lot of people who get targeted are LGBT youth who don't know yet that these kinds of people exist. Ideally I want to protect them from having to learn the hard way what it's like to be Doxxed and targeted by lolcow forums.
On tumblr the way users started to get around this was to tag things "cw sexual assault //abc" which would break the tumblr URL format of "tumblr.com/tagged/cw-sexual-assault" by turning it into an invalid URL: "/tagged/cw-sexual-assault//abc" is not a page on tumblr. That kind of workaround is very specific to tumblr and it stopped working when they switched from /tagged to /search.
A simple ability to say "Don't show this post in hashtag searches" like Mastodon has absolutely removes this risk. However, users are pretty crafty and if this does become a problem they may find ways to get around it like they did on tumblr. So having some faith may be good.
I agree that one-way for now makes sense.
The UI simply inserts the tag into the XML object for the user. Since it's just a recognized string, a user could easily also just type it themselves. win-win!
The way an instance could auto-tag itself is very akin to the "cultural interoperability/translation" idea that twryst suggested recently for Mastodon. (Well, basically his idea was longer but included that feature.) I don't think his idea got kept track of but I think a fork might be working on it. I think it's a very good idea in general and pA implementing it would put it ahead of the pack. The other use-case for "cultural interoperability" which twryst suggested is for instances to be able to tag if a post is lolicon and instances which prohibit that could strip the attachment/block the post; without having the suspend the entire instance. If you're interested in is whole proposal I could try to find the log.
Commenting on the things that are points of further discussion, not meaning to dismiss things we seem to agree on :)
I share your concerns, but I don't think that hiding it from searches is the proper way to go here for a variety of reasons. It comes down to this: it is not hard to aggregate hashtags based on individual notices, and we already have a variety of ripper bots out there that have been scraping pages. I think a better idea here is a combination of rate limiting (which, by the way, we can easily make configurable here), and cultural norms/acceptability. Ultimately, I think any solution here is going to be complex - this isn't an easy problem with binary solutions. I do welcome thoughts.
My primary concern here as a developer is two-fold: first, I don't want to give the feeling of security where there is none, because people can still scrape and assemble hashtag listing pages and the scrapers I've already seen for mastodon are already of some significant complexity. Secondly, I don't want to get in a sort of arms race here. To a certain degree that's inevitable and unavoidable, but I think user education here could help a lot. If people have a culture whereby this sort of behaviour is not allowed, and it is rejected, this introduces not only the technical costs of doing this kind of targetted harassment, but also the social ones.
An ounce of prevention is worth a pound of cure, but I don't think we're going to be able to prevent this if people want to do this, and we already have in the fediverse a segment of technically-savvy people who are probably going to want to game this for their own amusement.
Well, I want to avoid scope creep here, but I do think this approach is very helpful. Most admin instances, even on the so-called "free speech zones", will try to be a good neighbour if they can do this without too much effort. The friction surface here is they aren't going to change their own community to do so. The self-tag/auto-tag idea for a instance allows us to preserve CW and their intention, without making entire populations tag with CWs. It also allows the administrators of instances where this could create its own mental health issue problems (for example, places with an appreciable amount of people with anxiety, to which this kind of thing is kryptonite) to protect their populations and still be a good neighbour, it's just a win-win IMO.
(If you want to split other ideas this person had into other issues for us to look at and discuss, that's fine, btw! I just don't want this particular discussion to go off the rails, this is an important topic IMO.)
I think there's a way to implement it to be both compatible with Mastodon and degrade well. Right now mastodon does the following for cw (html unescaped for readability):
<summary xml:lang="es">Which line of music does an MRA sing?</summary> <content type="html" xml:lang="es">m'lody</content>
This is of course not the best use of the summary field and loses information on display in GS. I'd suggest to implement it similarly, but like this:
<summary xml:lang="es">Which line of music does an MRA sing?</summary> <content type="html" xml:lang="es"><span data:type=cw>Which line of music does an MRA sing?</span> m'lody</content>
Instances that would understand it could strip out the cw in the content tag before displaying. This would show up completely on unmodified GS and also work correctly on Mastodon, just with a doubled cw text.
While this is a good idea, it's probably better pitched at Mastodon to adopt rather than here, none of us would have to worry about interop if they adopted it.
Great discussion. I very much agree with the one-way approach to Mastodon compatibility; it's always better not to be limited by the decisions of the first implementation! Conceptually I think there are several things bundled together in the Mastodon CW/NSFW functionality:
- conventions for warning people about spoilers, potentially-triggering, etc. content,
- a configurable “see more” tag. this is potentially used for things besides content warnings ("excerpts" fo longer posts on Dreamwidth and Wordpress)
- a display variant for embedded video content. currently tied to a hardcoded hashtag (#nsfw) but you could imagine people wanting this for CWs - and other hashtags as well ("stop showing me #puppies, it's too distracting!") a
- a convention for a site to warn other sites about content that might not adhere to "decency" standards in all communities (NSFW)
- potentially, a way of filtering out material that a user doesn't wont to see (it would be easy to implement settings for "CWs not to show" and a toggle on whether to show NSFW content)
It might work better to think about these orthogonally -- although I certainly agree that from a UX perspective they need to come together with a simple front end.
Auto-tagging (and manually tagging as well)
One way to look at this is that Mastodon currently allows only the person making the post to put on CWs or NSFW. Auto-tagging allows a bot (or a hard-coded implementation at the system level) to do it. It can also be useful to let other people add CWs as well.
Thanks for the thoughts @jdp23 - here's some salient points I picked up from it I had my own thoughts on:
- Not being tied to Mastodon's own implementation is just a good idea for many reasons, not the least of which is that we can then go ahead and implement our own great ideas on top of it.
- Being able to configure CW's being spoilered or not in the interface would be a good idea, then users can choose whether they want to engage in that system. Some people with anxiety issues don't. And that's fine, we can cater to them too.
- Embedded video content would be hard but it is doable assuming youtube tags content.
- Instance-level tagging is probably a good idea too, so for example a politics-based instance doesn't have to CW every post with "politics"
- PCRE-based filtering on a feed could probably be implemented to allow user-specific, non-tag-based filtering.
- User-suggested tagging is a decent idea, but I also see it being done automatically being a vector for abuse - people could silence someone they don't like just by putting despicable, widely-blocked tags on their content. I would suggest a compromise: a variant of the report tool, where they can instead send a suggestion to the site admin that a post contain a certain CW, and the admin can then add it if they agree.
Good points, @maiya.
- Great point about the youtube tags.
- On the user-suggested tagging, very true about having to look at it being a vector for abuse or silencing; but, there are approaches that can cut down those risks (for example only considering user-supplied CWs from people I follow).
- I like the idea of a "suggested tag" that could go to the admin (or a moderator, if and when that's a separate role), although it's hard to know how well it would scale.
Of course it doesn't all have to be implemented at once! Still I think taking this longer-term view can lead to a much cleaner refactoring for pA, and this is certainly an area that's ripe for innovation - where even Mastodon's imperfect first attempt is a lot better than Twitter, Facebook, Ello, Google+, or other sites that come to mind.
- Great point about the youtube tags.
I still think interop with Mastodon should be a priority. Mastodon users are 80% of the fediverse and 100% of the CW users. The scheme I described above would work with all existing implementations, so I don't see the downside. I'll also add it to the Mastodon trackers, so let's see what they say :)
@jdp23 With regards to the concept of auto-tagging, the concern here for many is bad actors - not wanting to see them, not wanting to see talk about difficult subjects, etc - and I want to avoid it being used as a tool to bully people. We could probably have it an additional configuration option to automatically allow suggestions from people you follow automatically applied rather than require intertvention though, that could be a good middle ground I think.
As far as scaling suggested tags, the same latches we end up using to scale the report function in general could be applied here, I think. I would probably consider it a "category" of reports. Maybe even with an individual permission that could be delegating with regards to handling it, for larger nodes to spread out the responsibilites.
Don't get me wrong with the Youtube thing, it is worth looking into, but I do not at the present time know how feasible it is, so I don't want to make any representations or promises.
@lambadalambda i agree that it's worth putting an effort to making things compatible with Mastodon and if there's a way for everybody to adopt semantics that degrade better, that sounds like a good thing to me. I only meant not to let compatibility be the primary driver of the design; instead, to think first about the desired long-term solution and then to fit compatibility in with that.
Yeah, I think the consensus here is one-way federation, read their stuff but don't speak it. This allows us much greater flexibility to be agile in moving forward with a variety of positive improvements to the CWs we have already. I think we can consider that part of things a closed discussion at this point.
@jdp23 I've looked into the YouTube situation and it kind of varies depending on the video, some authors tag and those are exposed, others don't and so there'd be nothing there. I think the best approach may be to rely on our users tagging content, but we COULD introduce video-specific CW based spoilering when tags exist that are on a server-configuration defined list of things to spoiler automatically? This wouldn't be too hard to do once the backend for this is in place, what do you think?