Does the instance actor have special privileges?
-
infinite love ⴳreplied to Erin 💽✨ @38C3 on last edited by
@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 ⴳreplied to infinite love ⴳ on last edited by
@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 💽✨ @38C3replied to infinite love ⴳ on last edited by
@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?
-
@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. -
@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 ⴳreplied to Erin 💽✨ @38C3 on last edited by
@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”.
-
Jenniferplusplusreplied to Erin 💽✨ @38C3 on last edited by
@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 💽✨ @38C3replied to Jenniferplusplus on last edited by
@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.
-
-
@[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 nodetoorcc(although whether that's a wise assumption is up for debate)
