i wonder if there’s any prior art on breaking the same-origin assumption— like if there’s a way to signal that a URI subpath is being served by a different application than whichever server is handling requests for that hostname?
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
this is why http sigs are fundamentally broken the way fedi uses them. it’s security theater. every actor typically has its own key, but in reality that key proves nothing because all the keys are controlled by the application which is controlled by the sysadmin. just like a self signed cert proves nothing.
it’s why signed fetch is so easily circumvented, because you can just stick a key on any domain you control and no one would be any wiser.
we need a root of trust for fedi
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice more or less trying to derive a security model for fedi from first principles
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh the problem with those is that they're just another smaller theater
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice well yeah but at least when you yell “fire” then less people get hurt
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh ive thought about the Central Registry solution to location and authentication a lot and tbh, i still prefer a more isolated fedi where ppl compare public keys out of band. if the cryptography involved was actually useful and e2e, that is, atm we have about none anyway. reinventing the PKI and its authorities doesnt feel worth the effort for all the flaws it still leaves us
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice passing around bearer/capability tokens out of band
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh this is an invite link
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice an invite link is generally used to sign up for something, not to authorize requests (“you need a valid token to POST to my inbox or GET any of my posts”)
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh i mean the typical invite link is basically a cap token that you share out of band, that will authorize one request (an account creation) and we should definitely use this already good idea in other ways. but im just not sure of exactly what you were hinting at there. generally i wish activitypub already had capabilities instead of http signatures yea
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice some kind of mechanism for issuing and keeping track of tokens would be way better than this http sig mess that’s basically the same as using self-signed tls certs
-
alice@gts.void.dogreplied to trwnh@mastodon.social last edited by
@trwnh yea but it seems a bit heavier. bc you have to keep track of tokens and i imagine there would be a lot more of those than statuses. practically speaking as someone who's worried for database server. of course you can cheat a little by making your tokens around a signed bit of a special little capability dsl but god all of that just to post jokes on the internet. and the key rolling oh
-
trwnh@mastodon.socialreplied to alice@gts.void.dog last edited by
@alice i mean if you wanna just post jokes on the internet i don't see what http sigs bring to the table either. just put them on one site and then relay/aggregate them across other sites. or use something like websub. most of fedi is just web browsers but shittier anyway