I am working on Jejune, a personal ActivityPub server that has a featureset similar to Tumblr.
As part of this, Jejune Client is an ActivityPub C2S client which runs in the browser to allow the user to manage her instance, read posts in her inbox and publish new posts to her friends.
As part of this process, I have discovered that many AP servers do not consistently provide CORS headers when fetching ActivityPub objects.
For example, SocialHome does not provide any CORS headers when fetching ActivityStreams objects, which means that posts from SocialHome users do not appear in a correctly attributed way (as we can’t fetch the attributed actor), and Mastodon only provides CORS headers when fetching actors, but not posts and activities, which causes problems with building functionality where a user may want to examine a thread.
These can be mitigated by proxying the requests through the local AP server, but I don’t think this is a good design – if I can fetch something with curl on the commandline, I believe I should be able to fetch the same content with a browser.
So, I think it may be good to document the use of CORS headers when interacting with ActivityStreams/ActivityPub objects and endpoints over HTTP. What do people think?
Yep. Totally agree here.
CORS caused a lot of headache already at the watertower hackathon with Chris for an IPFS example with my minimal server (by that time) and the conduit “realworld” UI. However:
CORS was on my list for last SocialCG. I had proposed the topic for last meeting.
Wanted to speak about how we can document a kind of reference for a generic server which anyone could implement in the sense of interconnection.
There was “no time anymore” … … …
While I can see the point of setting CORS headers for public AS objects and activities, I’m wary of clients being able to sign their requests.
Indeed, if a browser-based software can sign their request, it means the end-user has access to the signing keys. This is fine for domains serving a single user, but it becomes an issue with domains serving multiple users as there would then be no way of guaranteeing two users of the same domain aren’t using the same identifiers for their objects.
For instance, if users a@foo.com and b@foo.com both have access to their private signing key, a@foo.com can create a Note with idhttps://foo.com/notes/12345 and b@foo.com could do the same, meaning a third-party instance bar.com may have different contents for https://foo.com/notes/12345 depending on who sent a Create activity first to bar.com.
Therefore, I’d advise against allowing the Signature header for such queries to objects, as well as disallowing queries to inboxes.
In the end, that would mean CORS is useful for public posts, but not private posts, nor instances requiring signed fetches.
Yeah, I agree with everything Claire is saying here, and for this and other reasons I don’t think it’s feasible to have any serious C2S server that doesn’t come with an authenticated proxy server for AP requests. Toy c2s apps for now can use one of the many numerous open CORS proxies that can be found on the internet (I’ve been using https://github.com/Freeboard/thingproxy and its public instances), but those toy apps are going to run into issues with Mastodon Secure Mode / Pleroma’s as:authenticated objects.
There are also open issues in the mastodon issue tracker.
It would be very nice if m. users and the other implementors would know about the opinions.
The last feature request is https://github.com/tootsuite/mastodon/issues/10400
Since the vast majority of people seem to use CORS (also e.g. peertube since 2.2.0 or pixelfed) and specs like remotestorage or SOLID make it mandatory:
Maybe I should write a comparison.
We will document CORS use for redaktor too.
As far as I remember, the author of geopub pukkamustard wanted to talk about CORS to, so maybe we can inform him when we documented.