Does the instance actor have special privileges?

Erin 💽✨ @38C3

@trwnh @julian @silverpill @thisismissem fundamentally trust lies in the server here; if you're not using LD signatures (and maybe even then?) I'm pretty sure you'd actually be fine to use one public key for every user

But what matters is the authorisation identity, not so much the key itself; in the fully general case it is impossible for a server to know everyone who should have access to a third party object (b/c BTo/BCC + implementation defined features), so when a user explicitly requests a resource then the server should use their identity

infinite love ⴳ

@erincandescent @julian @thisismissem @silverpill it matters that the key claims to be owned by an actor, and that the actor claims to own that key. the actual cryptography is merely a formality to link the http request to the public key through the private key. a “fancy password” like julian said.

infinite love ⴳ

@erincandescent @julian @thisismissem @silverpill also trust lies in the server application but there’s no way to identify a server separately from the hostname(s) it’s running on. hence why/how gleason was able to circumvent signed fetches by simply using a different hostname

Erin 💽✨ @38C3

@trwnh @julian @thisismissem @silverpill In any case I don’t think “origin based authentication” for fetches is a good idea for the simple reason that its not, to my knowledge, what implementations do today and it strongly risks leaking private posts. Certainly what the ActivityPub spec heavily implies if not outright says is that anything fetchable via a given identity should be visible to that identity, and I’m generally iffy on the idea of trying to make implementations execute potentially complicated ACLs on behalf of each other; that way is certainly a security disaster.

So that then leaves us with the question: is leaking the identity of the actor who has pasted a post’s URL into their instance’s search bar a real issue?

Erin 💽✨ @38C3

@trwnh @julian @silverpill @thisismissem To some degree my opinion is of course coloured “no, its not an issue” here by the fact that I run a single user instance; whether it came from [email protected] or [email protected] there is little ambiguity as to whether it was me.

Erin 💽✨ @38C3

@julian @silverpill @thisismissem @trwnh this is the part of the conversation where if she were still involved in things Christine would bust in and start shouting “OCapPub!!!!” at us all

infinite love ⴳ

@erincandescent @julian @thisismissem @silverpill yeah i think proxying your request has less value the less users you have, but it’s a nonzero value for any server with more than one user. but also users should have a checkbox in ui to say “try this request as me”.

Jenniferplusplus

@erincandescent @julian @thisismissem @trwnh @silverpill
I don't think it is a real problem. Especially when you balance the reader's desire for anonymity with the author's desire to know who they're talking to.

My larger concern is there's no good way to sustain this restriction over time. Once the server has those posts, it has no reliable way to restrict authorization on them, and no way at all to check authorization with the origin other than to fetch them all over again with a new key.

Erin 💽✨ @38C3

@jenniferplusplus @julian @thisismissem @trwnh @silverpill

All of the following asssumes you are caching the remote object:

In the common case, the people who can view it are listed directly in the recipients or are in a collection where the server can know all local users who are members (e.g. a followers collection). You can just drive your decisions off of the straightforward ACLs in the message.

For “undisclosed” recipients (delivered directly to the actor’s inbox but no addressing property, or fetched by this actor), you can maintain a private list of additional recipients who are allowed to view the post

In the case that an actor who is not in either the in-post recipient lists or your “known extra recipients” list tries to access the post, you must send a request to the origin to find out if they have access permission. You can optimise this by sending the usual HTTP caching headers (If-None-Match, etc) alongside your authorization header(s). If the remote permits them, you addt hem to the list.

django

@julian @jdp23 @crepels if the server hasn't seen (wasn't sent) the post, why do you think it should?

julian

@[email protected] if you have no user context, then it makes sense... but in the two use cases I mentioned, you do.

Resolving via search bar, user initiated.
Retrieving inReplyTo, user can be assumed from leaf node to or cc (although whether that's a wise assumption is up for debate)