Skip to content

Optional http-equiv for objects, to express user opt outs and/or preferences #403

Closed
@dmarti

Description

@dmarti

Some users have concerns about how their content or personal info is used. For example, some users do not want the content they created to be used for training generative AI systems, and some users do not want to have their personal information shared or sold.

In centralized systems, a user can indicate preferences and/or opt outs with an HTTP header on their own client, or apply settings to their own account on a server to have the HTTP header set by that server. However, in ActivityPub a user's content is federated across servers, so an HTTP header set by the user or on their home instance would be visible only in the original session.

Another problem with trying to standardize a set of preferences and opt outs for ActivityPub would be keeping a list up to date with all the available possible choices for all users. It's hard to know in advance what options a user will choose to exercise.

One possible way to make it work would be to extend section 3.1 of the spec, to allow information equivalent to HTTP headers to travel along with an object.

An object MAY have an http-equiv property, which is a list of header name-value pairs. A server MUST process that object as if it had been received over an HTTP connection with that header name set to that value.

For example, a user who chose to express a preference that their content not be used for AI training, and that their information not be shared or sold, could send something like this:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "Don't surveil me bro",
  "http-equiv": [{"X-Robots-Tag": "noai"}, {"Sec-GPC": 1}]
}

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions