This issue proposes adding a new security label to ActivityPub alongside as:Public called as:Authenticated.
The as:Authenticated security label would behave like as:Public but, in a compliant implementation, only allows any authenticated user to view the object.
The as:Authenticated security label would be represented over the wire as https://www.w3.org/ns/activitystreams#Authenticated.
Motivation
Recently there have been a few high profile incidents involving wholesale archival of fediverse instances. This has lead to many users expressing unhappiness as they had "buyer's remorse" considering their decision to label posts as as:Public.
Discussion frequently reveals that users commonly fall back to as:Public instead of sending to their followers collection due to motivations of reaching a wider audience of fediverse participants, but do not consider the possibility of permanent archival.
By introducing a new security label, as:Authenticated we introduce an alternative to as:Public for users who wish to make posts that any fediverse participant may interact with which excludes unauthenticated guest users.
The Fediverse is an open world network built on top of the ActivityPub and related standards. Accordingly, an implementation may choose to be intentionally non-compliant with certain aspects of the protocol, such as not enforcing security labels or limiting access to specified collections. This threat is not changed by this proposal, but a compliant server would ideally provide a way to make trust assertions about it's peers which includes limiting what objects are shared with those peers.
Authenticated Fetches
When as:Authenticated objects are Announced through the network, they should be referenced by their id. The recipient of the Announce MUST make an authenticated fetch using HTTP Signatures using a key belonging to an actor on the server. The server would ideally use a server-specific actor's key instead of a user's key if one is present.
The server which hosts the as:Authenticated object being fetched SHOULD verify that the signature belongs to a key which belongs to an instance that is authorized to fetch the object. The specific logic for determining whether an authenticated fetch is allowed is unspecified and implementation dependent.
Description
This issue proposes adding a new security label to ActivityPub alongside
as:Public
calledas:Authenticated
.The
as:Authenticated
security label would behave likeas:Public
but, in a compliant implementation, only allows any authenticated user to view the object.The
as:Authenticated
security label would be represented over the wire ashttps://www.w3.org/ns/activitystreams#Authenticated
.Motivation
Recently there have been a few high profile incidents involving wholesale archival of fediverse instances. This has lead to many users expressing unhappiness as they had "buyer's remorse" considering their decision to label posts as
as:Public
.Discussion frequently reveals that users commonly fall back to
as:Public
instead of sending to their followers collection due to motivations of reaching a wider audience of fediverse participants, but do not consider the possibility of permanent archival.By introducing a new security label,
as:Authenticated
we introduce an alternative toas:Public
for users who wish to make posts that any fediverse participant may interact with which excludes unauthenticated guest users.JSON-LD Context
Security Considerations
Rogue Implementations
This section is non-normative.
The Fediverse is an open world network built on top of the ActivityPub and related standards. Accordingly, an implementation may choose to be intentionally non-compliant with certain aspects of the protocol, such as not enforcing security labels or limiting access to specified collections. This threat is not changed by this proposal, but a compliant server would ideally provide a way to make trust assertions about it's peers which includes limiting what objects are shared with those peers.
Authenticated Fetches
When
as:Authenticated
objects areAnnounced
through the network, they should be referenced by theirid
. The recipient of theAnnounce
MUST make an authenticated fetch using HTTP Signatures using a key belonging to an actor on the server. The server would ideally use a server-specific actor's key instead of a user's key if one is present.The server which hosts the
as:Authenticated
object being fetched SHOULD verify that the signature belongs to a key which belongs to an instance that is authorized to fetch the object. The specific logic for determining whether an authenticated fetch is allowed is unspecified and implementation dependent.