Does the instance actor have special privileges?
-
Just something I noticed while testing non-public posts... when I try to message @jdp23@blahaj.zone, sharkey tries to grab the
inReplyTo
, but it attempts to do so with the instance actor, which obviously doesn't have access to the chat.Feels like a Sharkey bug, but I also noticed this behaviour when I tried to use @crepels@mastodon.social's activitypub.academy... using the search bar (and the explorer) caused the request to be made with the instance actor.
So now I'm not even sure what to think.
-
silverpill@mitra.socialreplied to julian@community.nodebb.org last edited by
@julian @crepels @jdp23 @jdp23 It is not special, but it has same origin as person-actor. If you accept origin-based security model, there is little practical difference, and you can grant access to an instance actor or to any other actor on that server.
-
julian@community.nodebb.orgreplied to silverpill@mitra.social last edited by
@silverpill@mitra.social @trwnh@mastodon.social hmm, I don't think I like that for this use case.
Especially within the context of limited visibility objects that are scoped to specific users, allowing just anybody from the same origin to access that object seems like a security violation.
I can see the case for allowing the instance actor access to it, but even then it gives me pause.
cc @thisismissem@hachyderm.io for her thoughts.
-
thisismissem@hachyderm.ioreplied to julian@community.nodebb.org last edited by
@julian @silverpill @trwnh I think instance-actor based fetching only really makes sense for public objects?
AP does indeed rely on a same-origin security model though, afaik, because they didn't wanna get into ACLs (which solid eventuality ended up with two of: WebACL and ACP)
-
erincandescent@akko.erincandescent.netreplied to thisismissem@hachyderm.io last edited by@thisismissem @julian @silverpill @trwnh I believe that Mastodon implemented this for privacy reasons, but I honestly think using the users actual actor here would be preferable. How else do you establish visibility?
-
erincandescent@akko.erincandescent.netreplied to erincandescent@akko.erincandescent.net last edited by@thisismissem @julian @silverpill @trwnh it feels like one of those things where a poorly thought out privacy feature creates a functionality problem to me
-
erincandescent@akko.erincandescent.netreplied to erincandescent@akko.erincandescent.net last edited by
@julian @silverpill @thisismissem @trwnh anyway given everyone does authorisation based upon exact actor match (the only really reasonable approach) I think the only reasonable approach is to use the authenticated user for fetches so they can see the posts they’re supposed to be able to
-
@julian @trwnh @thisismissem Server operators can read all private messages. Strict ID check is not completely useless, because it might prevent leaks in case of a software bug, but it doesn't provide any additional security guarantees
-
trwnh@mastodon.socialreplied to erincandescent@akko.erincandescent.net last edited by
@erincandescent @julian @thisismissem @silverpill WWW-Authenticate + Authorization?
-
trwnh@mastodon.socialreplied to erincandescent@akko.erincandescent.net last edited by
@erincandescent @julian @thisismissem @silverpill Mastodon I think considered the idea of trying first with the instance proxy key and then if that failed try again with your key.
This makes it better from a usability perspective but the security qualities are just as lacking as before. The server could theoretically try with any/every user’s key. You end up having to put a lot of trust in the server anyway, so you fall back to having origin-based security anyway…
-
trwnh@mastodon.socialreplied to silverpill@mitra.social last edited by
@silverpill @thisismissem @julian Yeah, it raises the bar very slightly to say that instead of any key on a domain, you need to use a specific key id on the domain. But it could be the same key material, and that wouldn’t even hurt security meaningfully.