Mastodon: Submit ActivityPub implementation report

[cwebber]

Sorry for abusing the issue tracker on this a bit, but ActivityPub is coming out of the last steps and it would really really really help to get Mastodon on the implementation reports page. Luckily, this is very easy to do!

All you have to do is run Mastodon through the test suite and it will generate a report for you which you can submit to the ActivityPub issue tracker.

In the future the test suite will be fully automated; currently it is only automated for the client-to-server protocol. However it will ask you some questions and ask you to observe behavior and verify output. Anyway, you just need to do that and check some boxes and horray! You have something to submit.

Thank you thank you thank you!

[nightpool]

I'll do this probably today or soon.

[nightpool]

Preliminary implementation at https://github.com/w3c/activitypub/issues/271. there are a couple issues I'd like to highlight here before the report gets closed:

Servers MUST deduplicate the final recipient list.

Currently, we send duplicate statuses to mentioned users if they're also followers. This is what the spec says:

Servers MUST de-duplicate the final recipient list. Servers MUST also exclude actors from the list which are the same as the actor of the Activity being notified about. That is, actors shouldn't have their own activities delivered to themselves.

I don't know how much this really applies to us, but we do the latter (except maybe for the reply-forwarding feature) and not the former. Servers who have users that are mentioned in a status that are also following the actor in question get sent the activity twice.

MUST: Forwards incoming activities to the values of to, bto, cc, bcc, audience [if and only if criteria in 7.1.2 are met.]

• This is the first time the server has seen this Activity.
• The values of to, bto, cc, bcc, and/or audience contain a Collection owned by the server.
• The values of inReplyTo, object, target and/or tag are objects owned by the server. The server SHOULD recurse through these values to look for linked objects owned by the server, and SHOULD set a maximum limit for recursion (ie. the point at which the thread is so deep the recipients followers may not mind if they are no longer getting updates that don't directly involve the recipient). The server MUST only target the values of to, bto, cc, bcc, and/or audience on the original object being forwarded, and not pick up any new addressees whilst recursing through the linked objects (in case these addressees were purposefully amended by or via the client).

Current we violate this both ways: We do send things that aren't covered by the criteria (replies to users are sent to all of those users followers without any explicit addressing) and we don't send things that are covered by the criteria.

I think we're fine not doing the whole recursion and forwarding thing, since that barely if ever applies to us, but we should add some extra addressing to replies to indicate that we want and should forward them to the followers of the replied_to status. This would be something like cc << status.thread.user.followers_url if status.thread? in tag manager.

Misc security concerns

The ActivityPub spec highlights three security concerns we currently violate:

• By default, implementation does not make HTTP requests to localhost when delivering Activities fixed
• Implementation applies a whitelist of allowed URI protocols before issuing requests, e.g. for inbox delivery fixed
  
  
  
  • Server filters incoming content both by local untrusted users and any remote users through some sort of spam filter
  
  

We should fix at least the first two, they seem like no-brainers. (EDIT: done) The third one is probably not a concern for us.

[nightpool]

Oh, and this wasn't really covered by the impl report, but Thibg brought up that we currently decide the privacy of DM/private statuses by the mentions in a note's tags, not the addressing. We can fix this pretty easily by only generating mentions records for users that are also included in the to or cc fields.

This is a pretty simple fix since we currently gate mention notification on audience_includes?(account), so we just need to change the process_mention method in create.rb to check that as a predicate.

EDIT: this has been resolved properly as of #8950