FEP-7502: Limiting visibility to authenticated actors

Standards Fediverse Enhancement Proposals
, ,
1

Hello!

This is a discussion thread for the proposed FEP-7502: Limiting visibility to authenticated actors.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

Some servers require authentication for all requests made via ActivityPub, even for GET requests on public objects addressed to as:Public. This violates the requirement that anything addressed to as:Public is made available without requiring authentication. This FEP proposes an alternative addressing that may be used in such scenarios, signaling that the object is not fully public but is otherwise available to any actor.

2

one potential change to this FEP is dependent on how Revisit the `https://www.w3.org/ns/activitystreams#Public` == `as:Public` == `Public` equivalence and guidance · Issue #404 · w3c/activitypub · GitHub gets resolved. if the addressing properties (to/cc/bto/bcc/audience) get changed from @type: @id to @type: @vocab, then this FEP might adopt a context document to map Authenticated and/or AuthenticatedAgent to the full IRI http://www.w3.org/ns/auth/acl#AuthenticatedAgent. or it might not. i’m not sure which is best yet.

  • if this change is not made:
    • …then the full IRI is the only valid representation (since any term defined will not be expanded properly)
  • if this change is made:
    • if no shorthand term is defined:
      • …then the full IRI is the only valid representation (since there is no shorthand term defined)
    • if a shorthand term is defined:
      • if the context is used:
        • …then the compacted document will use the shorthand term (since the change was made and there is a shorthand term in the context used)
      • if the context is not used:
        • …then the compacted document will use the full IRI (since even though the change was made and the shorthand term was defined, that context was not used)

so it seems like in most cases you would essentially only have to check for the full IRI, but in the event that the change is made + a term is defined + that context is used, plain JSON consumers will have to check for either/both the full IRI and also the shorthand term. for this reason i’m hesitant to define a term / make a context document asset for this FEP. it would be simpler/easier not to, and in some ways it would be replicating what is very likely a mistake or regretful approach of the current spec in regards to how it handles the Public mapping. doubtless the whole issue of Public == as:Public == https://www.w3.org/ns/activitystreams#Public would simply not exist had it never been tried – just check for the full IRI and nothing else, and you’re done.

3

I think of using a special key in the recipients to show properties as Public or Public- (= only fetchable by authenticated users) fails being appropriately extendable.

For example as @jenniferplusplus points out in this reply to indexable, one should be able to indicate on a per post basis if a post is indexable.

This would add the next special URI https://indexable.example. Next, maybe I want posts one is not allowed to share, so I add the special URI https://notshareable.example, and so on…

Conclusion: We combined two things, for no obvious benefit, but a clear detriment: Creating another aspect of ActivityPub parsing that is non trivial. As I already consider parsing ActivityPub objects too complicated, I would prefer another approach.

4

it wouldn’t.

the reasoning for using the addressing properties is that 1) it will trigger certain heuristics like mastodon marking the status as “limited visibility”, 2) i’m not sure replacing Public addressing with a different mechanism is worth it. we could for example try to replace Public with something like Web Access Control but that would require a lot more buy-in.

as for parsing, you would just ignore any addressees that don’t resolve, no?