@julian @silverpill @erincandescent @thisismissem Security-wise all bets are off if you want to establish anything other than “the signature claims to be from this key, and the key claims to be owned by this actor, and the actor links back to the same ...
-
@julian @silverpill @erincandescent @thisismissem Security-wise all bets are off if you want to establish anything other than “the signature claims to be from this key, and the key claims to be owned by this actor, and the actor links back to the same key, so we can assume the actor’s controller is the signing party”
note that i said “actor’s controller” and not just “actor”. this is an important distinction. just like web keys are custodial, web actors are custodial too
-
erincandescent@akko.erincandescent.netreplied to trwnh@mastodon.social last edited by@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 -
trwnh@mastodon.socialreplied to erincandescent@akko.erincandescent.net 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.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social 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
-
erincandescent@akko.erincandescent.netreplied to trwnh@mastodon.social 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?
-
erincandescent@akko.erincandescent.netreplied to erincandescent@akko.erincandescent.net last edited by
@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
internal.fetch@erincandescent.net
orerincandescent@erincandescent.net
there is little ambiguity as to whether it was me. -
erincandescent@akko.erincandescent.netreplied to erincandescent@akko.erincandescent.net last edited by
@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
-
trwnh@mastodon.socialreplied to erincandescent@akko.erincandescent.net 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”.