Flag Activity
Technical Discussion
2
Posts
2
Posters
0
Views
-
Is there any information anywhere on how the Flag activity is used in practice?
As ever, the spec only tells me that it exists; it doesn't say anything about what it contains, where it gets delivered to, how the recipient processes it, etc.
Maybe I could find out more by setting up some test instances and experimenting with it, or by trying to trawl through various repositories to find the relevant source code - but it seems a lot quicker to just ask.
#ActivityPub #ActivityPubDev #FediDev #FediDevs -
Is there any information anywhere on how the Flag activity is used in practice?
As ever, the spec only tells me that it exists; it doesn't say anything about what it contains, where it gets delivered to, how the recipient processes it, etc.
Maybe I could find out more by setting up some test instances and experimenting with it, or by trying to trawl through various repositories to find the relevant source code - but it seems a lot quicker to just ask.
#ActivityPub #ActivityPubDev #FediDev #FediDevsYou asked this here: https://activitypub.space/topic/fd53b73d-bf92-4e81-a5ae-5a681e4aacd4/flag-activity?_=1768647932631
There has been no changes in status from what I last said, because I get almost zero time to work on AP T&S. I can probably explain Flag activities better in a call or something than quickly in text.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@evan said in ActivityPub API Client Reputation:
> @thisismissem said in ActivityPub API Client Reputation:
>
> > I'm not actively working on any Mastodon features at the moment because they can't give credit where credit is due, which means it's not financially viable for me to contribute. I also just opened that ticket explaining the problem. CIMDs would fix.
>
> Oof. Let's hope they get around to it before the bad guys do. I'd rather we all don't learn a lesson about security the hard way.One could hope, but they weren't willing to back the huge amount of work to deprecate non-expiring access tokens, so that'll probably be exploited first, since there's quite literally millions of non-revoked access tokens out there.
I tried to do the work to fix it on my own, but it's literally months of work to implement correctly with enough test coverage. Without them either paying me or promoting/acknowledging my work, I ran out of my own budget to be able fix their problems.
> > You can't Flag a non-activitypub JSON document.
>
> I think you can, if you use the Link type.
>
> json > { > "@context": "https://www.w3.org/ns/activitystreams", > "type": "Flag", > "id": "https://social.example/activity/flag/1", > "actor": "https://social.example/user/3", > "object": { > "type": "Link", > "mediaType": "application/json", > "href": "https://client.dev/oauth/metadata.json" > }, > "content": "This is an example Flag activity for a CIMD document." > } >That'll flag it at this point in time, and the contents can change. And software in the fediverse is unlikely to be able to understand receiving a flag like that.
> At the very least, manual moderation is important. "This app isn't allowed on this server." That depends on human judgement, CVE reports, whatever.
Yeah, requires folks to actually build moderation tools for that and ensure moderating against an application revokes its access completely. Revoking access tokens doesn't prevent usage of data already harvested or whatever, but does prevent ongoing abuse
-
@thisismissem said in ActivityPub API Client Reputation:
> I'm not actively working on any Mastodon features at the moment because they can't give credit where credit is due, which means it's not financially viable for me to contribute. I also just opened that ticket explaining the problem. CIMDs would fix.
Oof. Let's hope they get around to it before the bad guys do. I'd rather we all don't learn a lesson about security the hard way.
> You can't Flag a non-activitypub JSON document.
I think you can, if you use the Link type.
{ "@context": "https://www.w3.org/ns/activitystreams", "type": "Flag", "id": "https://social.example/activity/flag/1", "actor": "https://social.example/user/3", "object": { "type": "Link", "mediaType": "application/json", "href": "https://client.dev/oauth/metadata.json" }, "content": "This is an example Flag activity for a CIMD document." }A reputation system doesn't have to be perfect to be useful. And it's much more important to collect and share negative signals than positive ones.
I understand that you don't trust app store reviews or ratings but literally billions of other people do. When I go to download an app and it's got a 2.8/5 score, it gives me pause, and I read the reviews to see what the problem is. Sometimes I'll google the app by name. I am unlikely to install it, unless it's really the only software out there that does what I need it to do.
At the very least, manual moderation is important. "This app isn't allowed on this server." That depends on human judgement, CVE reports, whatever.
I think I understand the use of the content hash, thanks!
-
@evan said in ActivityPub API Client Reputation:
> the ticket you're working on for moderating OAuth clients for Mastodon is a really big deal.I'm not actively working on any Mastodon features at the moment because they can't give credit where credit is due, which means it's not financially viable for me to contribute. I also just opened that ticket explaining the problem. CIMDs would fix.
> > That's why we wrote the CIMD spec.
>
> Yes! Using the same identifier for clients in a verifiable way is a big help in having a reputation for using on a single server or multiple servers.You cannot rely on the contents of a CIMD not changing though, for that you'd need to calculate like the CBOR CID of the JSON (that's what I do in https://cimd-service.fly.dev)
> > But OAuth security and trust models are complex and generally proprietary
>
> I think you could get to some pretty useful metrics pretty quickly, though. Some good ones to use might be:You'd be surprised, but no. Whilst I was on the hachyderm infra team, I ran a tonne of queries for research on the data they have for registered OAuth clients, and there's really not a lot of great insight, besides "this app was added a lot to accounts", which isn't really a good score of trust (see: Cambridge Analytica).
> - How many people on this server (or other servers) have authorized the client
Meaning number, overall. The top registered client on Hachyderm was actually a dead research project if memory serves (found that out after reaching out to the author, and promptly revoked all 200k access token it had left on our servers unrevoked)
> - What the average rating has been (but you need a way to rate clients!)
Not something 99.9% of people will do meaningfully, see appstore ratings and bridgading of apps to tank their scores.
> - How many Flag activities have been submitted for this client (you need a way to report clients)
You can't Flag a non-activitypub JSON document. The majority of fediverse software doesn't support multi-modal moderation reports, Pixelfed is one of the few that does.
> - Reviews of the client (you need a way to write a review of a client)
See prior note on App Stores.
> That data could be local to the server, or could be shared from other trusted servers. A trusted intermediary like IFTAS could be helpful.
Sure, maybe, but it needs to reference a CIMD at a specific content-hash. Otherwise I can attack that system by changing my metadata to gain more access
-
You asked this here: https://activitypub.space/topic/fd53b73d-bf92-4e81-a5ae-5a681e4aacd4/flag-activity?_=1768647932631
There has been no changes in status from what I last said, because I get almost zero time to work on AP T&S. I can probably explain Flag activities better in a call or something than quickly in text.
-
@julian @pfefferle ActivityPub spec says IDs are URIs, I think that means non-ascii characters should always be encoded.
Mitra rejects IDs that are not URIs, most of the time this doesn't cause any issues (WordPress was the only notable exception).
-
@pfefferle@mastodon.social I'm frankly surprised I ran into a side effect of this so soon after you updated the site :laughing:
Either the PR is to be reverted or perhaps WP should handle requests to the URL encoded address :shrug:
But after briefing myself on the root cause, it does seem weird that there exist actors with unicode in their ID. Might be if that is the case you should disregard them as non-compliant, who knows.
-
@julian should work again :(
-
@julian that is why:
* https://github.com/Automattic/wordpress-activitypub/issues/763
* https://github.com/Automattic/wordpress-activitypub/pull/2757seems that I have to revert a PR!?
