Closed dclements closed 3 months ago
Your reading is incorrect, this is not the intent of the requirement or the spec. Public activities should be available publicly, without needing authentication or authorization.
"Viewing this activity requires login but no special authorization" is a proposal that has come up before, but it would require a new method of signaling it, I don't think the Public URI is suitable for this purpose.
@nightpool I expect you're right about the spec itself, but it is worth noting the fediverse's broad deviation from this in the wild with authenticated fetch aka secure mode. Not all fediverse servers require valid HTTP Sigs to fetch objects, but many do, which means that to interop, servers need to either sign all fetches or introspect every server they talk to to determine whether it's enforcing secure mode. Afaik there's no standard way to a server to advertise this, so realistically the only safe way to ensure interop is to always sign all fetches.
We should probably add something about this to https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization !
@snarfed This isn't really true—even for servers using "authenticated fetch", the post itself is still publicly available on the internet to anonymous users (in HTML form). It's only "well-behaved actors" (i.e., those using JSON-LD) that are restricted / impacted by secure mode. Personally, I find this kind of misleading for users, although it has undeniable technical benefit.
That said I agree putting this down in the auth&auth document is probably a good idea
@nightpool True! I was thinking of AP itself specifically. If you're an AP server implementing S2S, in practice right now you can't consistently fetch objects/activities across the fediverse without auth, despite this language in the spec.
I guess I don't know whether users in accessible to all users, without authentication refers to end users or S2S implementations, though. End users may be more likely. If so, you're right, less relevant here.
My reading is exactly correct, you are disagreeing with the proposal, but my reading of what is and is not allowed under the spec is exactly what the spec says today.
Simply: I dispute that "Public" should be forced to be available to the whole of the internet under any circumstances. Plenty of services have "public" activities that are not visible to users who are not logged in.
you said "I think this should read 'without authorization'". The spec says "without authentication". The spec on balance, probably means what it says—"without authentication". Saying that the spec clearly means "without authorization" just because you want it to say "without authorization" is an incorrect reading of the spec.
The only thing being misread here is your misreading of my statement.
"I think this should read" as in "I think that this should be changed to read" or, to add some context as to why I think that, "I think that in practice it is being interpreted this way, it should be interpreted this way because the current spec is nonsense on this point, and thus the spec should align with the practice."
It's understandable that you wouldn't parse it that way—I didn't spell that out, after all—but you should stop arguing with and trying to correct me about what I meant.
Hello! So, I think we have several questions here. I'll try to address them separately.
I'm going to break out that third item into its own issue, since it needs some clarification. I will add the first two to the auth-auth page in the primer.
I updated the authc/authz primer page to call out this issue.
https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization#Public_access
Hopefully this meets the clarification needs of the original poster.
Thanks Evan!
Another interesting conclusion this morning: "accessible to all users, without authentication" seems to be independent of fetch mechanism, ie it applies to both human users viewing HTML posts in a browser and AP S2S. Given that, authorized fetch may technically not comply with the current AP spec.
However, it does also seem to be a reasonable, useful feature, eg for preventing abusive or otherwise unwanted requests, and it has broad precedent in many/most APIs. So, it could be a candidate part of the spec for us to revise in the future and allow.
In section 5.6 on Public Addressing it includes this line:
I think this should read "without authorization," not without authentication.
In short: it should be possible to say "only users may access this (public) resource, but there should not be limits within the pool of users for a public resource."