Publishers may wish to mark certain content as "sensitive". This can be because the publisher recognizes the content as benefiting from a discretionary warning, or as a courtesy to their audience and their sensitivities regarding certain topics that may be triggering if viewed without a warning. Marking the content as "sensitive" typically hides the content behind a content warning, blurs or collapses media attachments, and requires click-through consent before viewing the content.
This approach currently lacks a formally defined processing model for specifying which properties are considered "sensitive" or "content". This document aims to define such a processing model and provide guidance on how sensitive content is handled by publishers and consumers of Activity Streams 2.0 documents, particularly in the fediverse.
For more details on the status of this document, see the following GitHub issues:
A history of content warnings as a feature is described in [[[onCW]]]:
Blackle's CW design was incredibly simple. It was universally agreed upon by everyone involved in mastodon development at the time that this simple design was what made sense. There is a button in the compose box labeled "CW." Click on it and a box appears. Type anything in the box and now your post is collapsed like a forums-style spoiler box, with your content warning on top. Now you can post anything you want and allow others to opt into seeing it after having received an adequate warning.
Shel Raphen, [[onCW]], "Mastodon and Content Warnings"
The history of certain terms being unofficially included in the official activitystreams namespace is described in [[[miscellany]]]:
The first software packages that implemented [ActivityPub] began to appear in 2018 [...] Some terms were proposed for inclusion in the ActivityPub specification, but weren't included because of time constraints [...] In the absence of a clear extensions process, those terms were not given their own namespace or context document, but instead were defined in the default namespace for Activity Streams 2.0 [...] Newer [vendor-specific] extensions have been defined in [vendors'] own [namespaces]. The first few terms, though, remain undocumented in a formal specification.
Evan Prodromou, [[[miscellany]]], 1. Introduction
One such unofficial term is `sensitive` (`https://www.w3.org/ns/activitystreams#sensitive`), which is defined in [[[miscellany]]] as follows:
The sensitive property (a boolean) on an object indicates that some users may wish to apply discretion about viewing its content, whether due to nudity, violence, or any other likely aspects that viewers may be sensitive to. This is comparable to what is popularly called "NSFW" (Not Safe For Work) or "trigger warning" in some systems. Implementations may choose to hide content flagged with this property by default, exposed at user discretion. Original discussion in [[[[originalIssue]]]].
When content is marked as sensitive, applications SHOULD prompt readers for consent prior to viewing the collapsed content (`content` at minimum). Applications MAY show information deemed non-sensitive to help readers decide whether they want to consent to viewing the content (by expanding the content). Applications SHOULD also allow readers to collapse content again after expanding it.
When a `Link` is marked as sensitive, applications SHOULD prompt readers for consent prior to visiting the link target (`href`). Applications MAY show information deemed non-sensitive to help readers decide whether they want to consent to visiting the link target.
The text of this section is based on a preliminary survey and is not final.
When the sensitive property is set to `true`, the following properties are generally unsafe to show:
However, some implementations consider other properties to be similarly in scope of the sensitive property. For example, Mastodon considers the following properties to also be sensitive:
It is generally possible to mark individual attachments as sensitive (and in general, any object property node can contain the sensitive property), although currently some consumers might not understand this scoping. Where possible, publishers SHOULD scope the sensitive property to the parts of the document that are actually sensitive, and consumers SHOULD process only those parts of the document as sensitive as described in .
Additionally, Mastodon considers the following properties to be safe to show:
It can be worth defining an explicit signal for which properties are sensitive or not, so that there is no ambiguity on the publishing or consuming side.
Currently, there are no broadly agreed-upon approaches for this explicit signaling, but potential approaches include:
{
"@context": "https://www.w3.org/ns/activitystreams",
"as:sensitive": true,
"https://vocab.example/sensitiveProperties": [
{"id": "as:content"},
{"id": "as:attachment"}
]
}
{
"@context": [
{
"sensitive": "https://www.w3.org/ns/activitystreams#sensitive",
"sensitiveProperties": {
"@id": "https://vocab.example/sensitiveProperties",
"@type": "@vocab"
}
},
"https://www.w3.org/ns/activitystreams"
],
"sensitive": true,
"sensitiveProperties": [
"content",
"attachment"
]
}
For object properties (those whose `@type` declares them as referencing an object `@id` instead of having a literal `@value`), it is possible to mark the object as sensitive; in these cases, it would be preferable to signal the objects as sensitive instead of signaling the property as sensitive.
{
"@context": [
{
"sensitive": "https://www.w3.org/ns/activitystreams#sensitive"
},
"https://www.w3.org/ns/activitystreams"
],
"sensitive": true,
"preview": {
"sensitive": false
},
"attachment": [
{"sensitive": true},
{"sensitive": false},
{"sensitive": true}
]
}
From [[[onCW]]]:
The first CW discourse came when people inevitably used CWs to make jokes. Your CW was the set-up, and the post body was the punchline, creating that comedic timing. Sometimes people made jokes using false content warnings, labeling their delicious hoagie as "lewd" for instance. This led to discourse about if it is disrespectful to people with PTSD to use CWs so frivolously and if unreliable CWs meant people would start opening CWs expecting something to not actually be what's on the tin, and then being shocked anyway.
People find it so difficult to not click the button that shows the post that eventually filtering was implemented that hides the post entirely rather than spoilering it.
There were complaints that Mastodon users were so liberal with the CWs that people had to click to open every single post. Some users responded to this by saying that CWs should be treated as "the subject line to an email" and that we should probably just CW every single post by default.
Being able to CW posts lead to an increased sense of freedom to discuss things others might not want to see, but it also led to pressure to avoid upsetting potentially anyone.
From [[[onCW]]]:
When you are a person who experiences racism in your daily life, it's quite challenging to tag all mentions of politics. Your life is politicized. White lives are safe for general audiences, but Black lives need to be given a mature content rating in case it upsets a white person to read about racism. These labels aren't neutral. A value statement is implied by their labeling.
From [[[onCW]]]:
Mastodon's intense CW culture, where everyone constantly argued about what should and should not be hidden behind a content warning, resulted in the "meta" tag for posts about mastodon or which were a part of site wide discourse [...] People began to fight endlessly about if white people should CW racism too or if only BIPOC were exempt from CWing racism. Was it perhaps actually valorous and important to forcibly expose people to certain posts instead of using CWs? The arguing was exhausting and never stopped.
After all, Mastodon is decentralized. Different instances had different rules around what needed a content warning and when those instances interacted you would get inter-communal conflicts debating if they should defederate because their CW practices were incompatible. New people and instances were always joining Mastodon and every time it would reignite every single CW discourse topic over and over again.
Years into this, the consensus among Mastodon early adopters was that we had messed up. Our original CW design was backwards. We imported our Twitter workaround and turned it into a feature without substantial modification. It was the onus of the poster to filter out what every stranger might now want to see, instead of the onus of the reader to filter out what only they did not want to see. We discussed how tumblr did this correctly. Posts should have tags at the bottom, and users should opt into filtering those tags, rather than opting into seeing them.