search

MbinOrg / mbin

Mbin: a federated content aggregator, voting, discussion and microblogging platform (By the community, for the community)
https://joinmbin.org
GNU Affero General Public License v3.0
220 stars 17 forks source link

Like activity ID is not dereferencable #772

Open silverpill opened 4 months ago

silverpill commented 4 months ago

Describe the bug

Like activities have IDs, but these IDs can not be dereferenced. Mbin server returns an empty JSON object.

On which Mbin instance did you find the bug?

https://moist.catsweat.com and others

Which Mbin version was running on the instance?

1.5.3

To Reproduce

curl -H "Accept: application/activity+json" https://moist.catsweat.com/f/object/b808046e-41f2-43e6-ab98-56888a09cf0d

Expected behavior

Server should return the entire Like activity.

Additional context

When I receive an Announce(X) activity in my inbox, I want to verify that X activity is real and the group actor didn't make it up. If Announce.actor and X.actor belong to the same server, I can assume that activity is valid. However, when actors are on different servers, I need to verify the authenticity of X activity by fetching it from the server of origin. Otherwise the server of the group actor could impersonate actors on other servers.

You might not consider it a security risk, but I would appreciate if you make activity IDs dereferencable.

Currently I'm working only with announced Like activities, but other activities such as Create and Delete may also have this problem - I haven't verified that.

BentiGorlich commented 4 months ago

You are absoultely right and it is the case for all activities that we generate. We do not have the activities saved in the DB and I do not know what a good way to save those would be. If we just save the json it will take up a lot of space, but would be easy to implement. If we'd save the referenced actor and object and payload etc it would take up less space, but would need a lot of logic to be implemented properly

silverpill commented 4 months ago

Perhaps you can generate activities on the fly, when they are requested? Or, alternatively, save them as JSON, and automatically delete after some time. I think in practice activities need to be dereferencable only for the brief moment when the Group actor announces them (and subscribers attempt to fetch them).

BentiGorlich commented 4 months ago

@e-five256 @nobodyatroot @melroy89 @asdfzdfj what do you think? I don't know if I'd want to delete activities again... But to save DB space it might be unavoidable...

asdfzdfj commented 4 months ago

Perhaps you can generate activities on the fly, when they are requested? Or, alternatively, save them as JSON, and automatically delete after some time. I think in practice activities need to be dereferencable only for the brief moment when the Group actor announces them (and subscribers attempt to fetch them).

imo a mix of both is probably needed, if you really want this

for the kind of activity that creates stuff e.g. Create, Like, it should be possible to "synthesize" these activity from existing data/state in the db upon request, though the path to activity object will need to change so it could be accessed properly (beats storing the uuid it just made up alongside the activity it referenced)

for the kind of activity that negates/removes stuff e.g. Delete, Undo, then caching the delivered activity for a period of time and then return those when being deref'd should be more feasible since at that point we most likely no longer have the object in question to synthesize activity for (or we would have to store those activities or its target object tombstones/sentinel values for all time which would be an absolute nightmare in more ways than one) this does put some pressure on storage/memory but statistically (from what I could see, anyway) this should happen way less often compared to the amount of creation activities enough to be feasible (and delegating this to cache with ttls should help with cleaning up old activities)

github-actions[bot] commented 3 months ago

This issue is stale because it has been open 50 days with no activity. Remove stale label or comment or this will be closed in 6 days.

silverpill commented 2 months ago

Still relevant.

I solved a similar problem in my own software by caching all outgoing activities (they are automatically removed after several days).

BentiGorlich commented 2 months ago

It's still on my radar, but I don't want to implement a temporary fix, I want to solve it properly but that takes time. I have a lot of items I am currently working on, but this is not yet on that list. You should be able to see the dashboard with things we are working on here: https://github.com/orgs/MbinOrg/projects/5/views/1 (note: atm not a lot of us use the board, but I do)

silverpill commented 2 months ago

Sure, this is not urgent. I just wanted to prevent stale bot from closing the issue

ghost commented 2 months ago

Sure, this is not urgent. I just wanted to prevent stale bot from closing the issue

fyi, we neutered stale bot from closing any issues. it'll say it's going to close it in x number of days, but not anymore. we don't have anyone dedicated to working on Mbin full-time, so it can be a slow process at times with work/personal schedules taking priority.