Remote (OWA) interaction with post items

2024-07-23 10:59:14

development@hubzilla.org

Mario Vavti wrote the following post Tue, 23 Jul 2024 10:59:26 +0200

Remote (OWA) interaction with post items

OWA is great for many things. No doubt about this. However, if we interact with a post item on a remote site, technically the interactions can not be federated. The remote site can not sign the HTTP request with your key.

This behavior is somehow inconsistent since most people will expect the messages to be federated.

Should we keep this feature ore better remove it?

show all 20 comments

2024-07-23 11:32:06

Harald Eilertsen

harald@hub.volse.no

I wasn't aware of this, but it makes sense in many ways. It should definitely be documented if we keep it as is.

2024-07-23 11:47:02

Mario Vavti

mario@hub.somaton.com

Not sure if @Mike Macgirvin 🖥️'s conversation containers solve this issue. But i guess if at all only for platforms that support this model...

2024-07-23 12:15:51

Harald Eilertsen

harald@hub.volse.no

@Mario Vavti Probably worth exploring. I don't have the required detailed knowledge about how the protocol stuff works yet to be able to provide much input. I've been following his work though, and like the way it progresses. When more mature it would be interesting if we could adopt it.

2024-11-23 22:31:52

Mario Vavti

mario@hub.somaton.com

Some late night thoughts on this... fep-171b suggest that if an Add activity actor origin differs from its object actor origin and there is no proof available, the object should be fetched from its origin.
We know we can trust the actor because the actor is authenticated via OWA. Now, if we can make sure the remote comment is first delivered to its author location and only later to everybody else, we should be in the shop in regard to activitypub :thinking_face:

Of course this is all theoretically since in practice no AP project supports fep-171b so far...

2024-11-24 05:53:25

Scott M. Stolz

scott@loves.tech

All of my projects in development heavily depend on OWA to work. It would be a disaster for me if this was removed. It is one of my primary reasons for using Hubzilla.

2024-11-24 05:55:26

Scott M. Stolz

scott@loves.tech

The remote site can not sign the HTTP request with your key.

Couldn't we use the same process we use for ActivityPub posts?

When you reply to something on a remote site, the remote site sends a copy to the author's server. The author's server could send out the signed message. At least as a backup option.

Of course, since we are the first ones implementing it, we get to suggest changes to the FEP that would make it compatible with OWA.

2024-11-24 07:52:23

Mario Vavti

mario@hub.somaton.com

@Scott M. Stolz i think you misunderstand something. Nobody is trying to remove OWA. It is about reacting on federated content via OWA.

2024-11-24 07:57:41

Mario Vavti

mario@hub.somaton.com

@Scott M. Stolz zot does not have this problem because there we do not care about the author.
The sender is who we have a connection with and it's his responsibility to verify that the authors content is okay...

2024-11-24 08:11:18

Scott M. Stolz

scott@loves.tech

@Mario Vavti

Now, if we can make sure the remote comment is first delivered to its author location and only later to everybody else, we should be in the shop in regard to activitypub :thinking_face:

That sounds like it may work.

Would that mean a delay if the author's node is unreachable? For example, we verify delivery to the author's hub, and once verified, we add it to the outgoing delivery queue on the server where the comment was posted on. Something like that?

2024-11-24 08:48:40

Mario Vavti

mario@hub.somaton.com

@Scott M. Stolz

Would that mean a delay if the author's node is unreachable?

Well, it is unlikely that the hub is down if somebody just authenticated via OWA but of course not impossible as always in a networking scenario...

2024-11-24 08:52:40

Mario Vavti

mario@hub.somaton.com

But as mentioned... Current situation is they wont even consider fetching content if there is no signature and sender and object.actor are not from the same origin. So everything is quite hypothetical...

2024-11-24 08:54:11

Scott M. Stolz

scott@loves.tech

@Mario Vavti What if we update the FEP so that it can handle OWA situations?

2024-11-24 10:59:52

Harald Eilertsen

harald@hub.volse.no

@Mario Vavti Not sure if this is related to the original problem of signing the request or not? However, as for the signing part, could OWA itself be utilized for that?

I.e. when I add an activity while signed into your site, it will be passed back to my site via an OWA "sign this" request, which gets back a signature as if the activity originated from my site.

Not sure if that would make any difference at all :)

One problem I see with this approach is: how can my site be absolutely certain the content that is asked to be signed is from me. Iow, we need to be sure random remote sites can't sign random content with your signature.

2024-11-24 17:48:55

Mario Vavti

mario@hub.somaton.com

Basically i see no big problem by trusting the sender. Eventually the sender will be made accountable if sending rubbish right?
Any server owner could already send spoofed messages even with signatures for any profile on their server if they wanted to. Don't see that happening a lot though...

2024-11-24 17:59:23

Harald Eilertsen

harald@hub.volse.no

@Mario Vavti I don't think it's wise to rely on "nobody's done it yet" as a security strategy. We ahould assume an adversarial network, and design the protocols to operate safely in that environment.

That's no easy task, though.

2024-11-25 09:15:20

Mario Vavti

mario@hub.somaton.com

@Harald Eilertsen well, in that case i think we should probably ditch reacting on remote federated content when authenticated via OWA. I do not really see a possibility how to sign the content in this scenario if we do not want to trust the sender.

2024-11-25 10:38:36

Harald Eilertsen

harald@hub.volse.no

@Mario Vavti It really depends on how strong the authentication via OWA is. I haven't looked at it yet, so don't have an opinion on that. I just think it's worth thinking through this properly so we don't open for abuse.

There's also some middle ground between "nobody's done it yet" and "this is impossible to forge" that probably is acceptable :)

2024-11-25 11:05:47

Mario Vavti

mario@hub.somaton.com

@Harald Eilertsen

There's also some middle ground between "nobody's done it yet" and "this is impossible to forge" that probably is acceptable :)

It is out of question that an admin in this case could produce and relay forged content for not only the channels of its own server but also for any other channel.
In your proposal of the reversed OWA lookup we would still require to trust the other ends claim that we are actually authenticated there.

2024-11-25 11:47:56

Harald Eilertsen

harald@hub.volse.no

@Mario Vavti I'm just thinking out loud, don't think I've proposed anything yet. You know the protocol way better than me, so it may be that my thoughts don't make much sense.

I've been meaning to go through the entire OWA flow with an adversarial look on each part to see if I can find ways to abuse it. But that's a lot of work, so I've been putting it off.

2024-11-25 13:21:18

Scott M. Stolz

scott@loves.tech

Is there a reason why ActivityPub can't use a similar method as Zot6 & OWA for verifying identity?