w3c
as:Authenticated proposal
Description
This issue proposes adding a new security label to ActivityPub alongside as:Public called as:Authenticated.
The as:Authenticated security label would behave like as:Public but, in a compliant implementation, only allows any authenticated user to view the object.
The as:Authenticated security label would be represented over the wire as https://www.w3.org/ns/activitystreams#Authenticated.
Motivation
Recently there have been a few high profile incidents involving wholesale archival of fediverse instances. This has lead to many users expressing unhappiness as they had "buyer's remorse" considering their decision to label posts as as:Public.
Discussion frequently reveals that users commonly fall back to as:Public instead of sending to their followers collection due to motivations of reaching a wider audience of fediverse participants, but do not consider the possibility of permanent archival.
By introducing a new security label, as:Authenticated we introduce an alternative to as:Public for users who wish to make posts that any fediverse participant may interact with which excludes unauthenticated guest users.
JSON-LD Context
{
"@context": [
{"as": "https://www.w3.org/ns/activitystreams"},
{"Authenticated": "as:Authenticated"}
]
}
Security Considerations
Rogue Implementations
This section is non-normative.
The Fediverse is an open world network built on top of the ActivityPub and related standards. Accordingly, an implementation may choose to be intentionally non-compliant with certain aspects of the protocol, such as not enforcing security labels or limiting access to specified collections. This threat is not changed by this proposal, but a compliant server would ideally provide a way to make trust assertions about it's peers which includes limiting what objects are shared with those peers.
Authenticated Fetches
When as:Authenticated objects are Announced through the network, they should be referenced by their id. The recipient of the Announce MUST make an authenticated fetch using HTTP Signatures using a key belonging to an actor on the server. The server would ideally use a server-specific actor's key instead of a user's key if one is present.
The server which hosts the as:Authenticated object being fetched SHOULD verify that the signature belongs to a key which belongs to an instance that is authorized to fetch the object. The specific logic for determining whether an authenticated fetch is allowed is unspecified and implementation dependent.
I saw a discussion about this on Mastodon and I have to admit, I don't really understand how this will prevent bots from scraping profiles. Bot operators will trivially spin up their own servers or register on a bot-friendly server and authenticate themselves to other servers though that.
I'm tentatively in favor of this although I think we need a more rigorous definition of what a "fediverse participant"/"authenticated user" is. An as2 client? an actor? a Person actor?
One might consider this proposal "kicking the can down the road" as far as archiving or other forms of public access goes—what happens when archival crawlers become as2 Services? It still leaves it up to the server host to handle restricting access by the appropriate actors, without explicit targeting from the user. (Something something Block...?)
Also, right now you have a MUST in a non-normative section, which is needlessly confusing. If that section is truly non-normative, it should probably be reworded to remove the MUST/SHOULD/etc language. If you consider that section normative, which it seems from the wording that you do, you should mark it as such and move it somewhere else.
@JonahAragon There's plenty of ways that ActivityPub privacy controls are suggestions - a bot operator could spin up their own instance or a followbot to capture followers only posts, and there's even some capture of direct messages that could be performed (IIRC there's one mobile client that sends everything it sees to its own search server). Fundamentally, you have to trust whoever you're federating with.
This proposal would at least let well-meaning bot operators know that a post is not intended to be archived publicly, reducing ambiguity.
Fundamentally, you have to trust whoever you're federating with.
This is kind of my point. I think users just need to understand that posts on a social media platform — especially posts marked as public — are indeed public, and should be prepared to deal with the consequences of that.
This proposal would at least let well-meaning bot operators know that a post is not intended to be archived publicly, reducing ambiguity.
I hadn't considered this and I suppose this may be true, but it seems like archive groups are generally undeterred by things like rate limits against their IPs/user agents/etc (which are also clear indicators that their efforts are not exactly welcome in my opinion), and I don't think it would stop them from running their bots through a compliant server to be properly "authenticated".
I can envision scenarios where this flag might be useful so I'd probably be in favor of adding it. I just think it's being proposed in response to a single incident, and I don't think this flag would prevent something like that happening again in the future. My main concern is that I think this proposal will provide a false sense of security/privacy to users because even if well-meaning bot operators complied with the flag in a way we evidently expect them to, there are probably plenty of operators who wouldn't, and nothing about this proposal would technically stop them.
To be clear, you can currently do the following:
- Do not sign objects for redistribution (so that they must be fetched when referenced)
- Have your software do access control to prevent unauthenticated fetches (so that incoming fetches must be authenticated)
What this proposal does is effectively two things:
- It formalizes this behavior
- It allows dropping
as:Publicfrom the audience/addressing
Of course there is nothing technically stopping you from republishing an email that you receive to your private inbox, either. But that still relies on you doing the republishing. This change would make AS2 objects less promiscuous and also generally auditable (since you can now log fetches by more than just IP address).
I'm tentatively in favor of this although I think we need a more rigorous definition of what a "fediverse participant"/"authenticated user" is. An as2 client? an actor? a
Personactor?
I think we should define it as an actor, or account associated with an actor. We need the proposal to be reasonably flexible while allowing users to control what shows up to guests on their profiles, etc.
One might consider this proposal "kicking the can down the road" as far as archiving or other forms of public access goes—what happens when archival crawlers become as2
Services? It still leaves it up to the server host to handle restricting access by the appropriate actors, without explicit targeting from the user. (Something somethingBlock...?)
Well, I think Mastodon and Pleroma both agree that Block activities exist in S2S. I think it is a reasonable interpretation that is not well reflected in the official spec, but we can grumble about it another time. However, I think that an instance admin should have mechanisms that allow for proactively blocking individual actors from fetching any objects, and due to the leakage that is inherently caused by multi-tenancy, an instance admin should be able to block entire instances deemed hostile. I'm not sure how to word that in the proposal though. Advice would certainly be welcomed.
Also, right now you have a
MUSTin a non-normative section, which is needlessly confusing. If that section is truly non-normative, it should probably be reworded to remove the MUST/SHOULD/etc language. If you consider that section normative, which it seems from the wording that you do, you should mark it as such and move it somewhere else.
I solved that by making the rogue instances section non-normative instead of the full security considerations section.
Fundamentally, you have to trust whoever you're federating with.
This is kind of my point. I think users just need to understand that posts on a social media platform — especially posts marked as public — are indeed public, and should be prepared to deal with the consequences of that.
The problem is that ActivityPub effectively only offers a formal binary: public or followers collection. Technically, the protocol can target any arbitrary collection, but in practice, this is how the implementations work. as:Authenticated solves this by introducing a second targetable security label which is backward compatibility with current implementations.
This proposal would at least let well-meaning bot operators know that a post is not intended to be archived publicly, reducing ambiguity.
This proposal is useful for bot operators, but ideally is meant to allow for exclusion of object visibility from unauthenticated scrapers. Authenticated scrapes can be handled in a different way on a software level and don't require an extension to ActivityPub.
I hadn't considered this and I suppose this may be true, but it seems like archive groups are generally undeterred by things like rate limits against their IPs/user agents/etc (which are also clear indicators that their efforts are not exactly welcome in my opinion), and I don't think it would stop them from running their bots through a compliant server to be properly "authenticated".
Right now Archive Team does not implement ActivityPub. It is my desire that Archive Team create an archival tool which does speak ActivityPub and appropriately respects as:Authenticated objects by, in their case, ignoring them. This would allow anyone who wants their posts to be archived to opt-in to such archival (and enable such archival in real time), while protecting the average user from posting things publicly. In Pleroma, it is already possible to stream only public objects to an archival instance of this nature.
However, Archive Team uses a web crawler called Warrior. Warrior is just a normal http client, and as:Authenticated does mitigate this situation as the labelled posts would not be included on any generated HTML pages scraped by the crawler.
With that said, you are right that this would not stop all cases. And also, it should be noted that nothing stops somebody from screenshotting posts and archiving that way. But a solution does not need to cover edge cases in order to be useful, and with the right kind of interaction with the archival community, we can probably get them to comply with the wishes of our own community.
I can envision scenarios where this flag might be useful so I'd probably be in favor of adding it. I just think it's being proposed in response to a single incident, and I don't think this flag would prevent something like that happening again in the future. My main concern is that I think this proposal will provide a false sense of security/privacy to users because even if well-meaning bot operators complied with the flag in a way we evidently expect them to, there are probably plenty of operators who wouldn't, and nothing about this proposal would technically stop them.
To be absolutely clear, as:Authenticated is not a flag, but a security label like as:Public. It refers to an implementation-defined collection of "authenticated users" (a more specific definition is being worked out still) that receive an activity. We do not expect hostile implementations to comply with this security label, but as it is a security label that refers to an implementation-defined collection of targets, the admin can choose to exclude hostile implementations they are aware of from that collection. To be absolutely clear though, this is not a flag, but a security label like as:Public. A message would look like this:
{
"@context": "https://www.w3.org/ns/activitystreams",
"to": ["https://www.w3.org/ns/activitystreams#Authenticated"],
"cc": ["https://example.com/users/foobar/followers"],
"id": "https://example.com/users/foobar/activities/2h3bhbr2bhj42hjb42b214b",
"type": "Create",
"object": {
"id": "https://example.com/users/foobar/notes/hello-world",
"type": "Note",
"content": "Hello world!"
}
}
To be absolutely clear, the purpose behind as:Authenticated is to make as:Public literally public again.
The intent is to allow users to choose a default of as:Authenticated or their own followers collection as their default target while allowing them to post things that they absolutely want to be public as as:Public.
Unfortunately, while I'm sympathetic to the problem, I don't think this is a good idea.
- As said earlier in the proposal, spinning up puppet accounts is too easy for this to be considered anti-abuse; it isn't.
- This proposal brings us more to "advisory policy" type stuff than we've ever been before. If that's the case, why pretend that authentication is even involved? Just have an http header that's like
X-I-Observe-Sharing-Levels: true, then add something like asharingLevelthat intentionally advises what level of sharing is allowed (this can be some enum whose values we can decide in this thread). Just don't serve the object to anyone who doesn't apply it, and it does "as much good" as authenticating would have anyway. This operates not too differently than Signal's "delete after X time" stuff or the (admittedly doomed) "do not track" http headers; on a protocol level, it can't be enforced, but it can ask well meaning participants to... participate well.
I'm open to alternative solutions to the problem, but this is something that requires a mitigation. Bluntly, the to and cc fields are 100% "advisory policy," but they exist in ActivityPub anyway. What do you propose we do? Again, users need the ability to restrict their audience somehow. If we can't restrict audiences in a cross-implementation compatible way that has low implementation cost (which is precisely what as:Authenticated does), then we're going to continue to have users shooting themselves in the foot.
the reason I like this better then some theoretical advisor flag X-I-Observe-Sharing-Levels that it ties scraping/activity to a specific activitypub actor that can be blocked/tracked/etc in the same way we already handle bot accounts. It brings a full class of behaviors into the network in a way that users are used to reasoning about.
However, i'll admit I'm not super sure what the UX for this should be from the Mastodon side of things—probably an account-wide checkbox, but people expect those to be retroactive, and activitypub payloads can't be.
On Mon, May 27, 2019 at 10:04 PM Christopher Lemmer Webber < [email protected]> wrote:
Unfortunately, while I'm sympathetic to the problem, I don't think this is a good idea.
- As said earlier in the proposal, spinning up puppet accounts is too easy for this to be considered anti-abuse; it isn't.
- This proposal brings us more to "advisory policy" type stuff than we've ever been before. If that's the case, why pretend that authentication is even involved? Just have an http header that's like X-I-Observe-Sharing-Levels: true, then add something like a sharingLevel that intentionally advises what level of sharing is allowed (this can be some enum whose values we can decide in this thread). Just don't serve the object to anyone who doesn't apply it, and it does "as much good" as authenticating would have anyway. This operates not too differently than Signal's "delete after X time" stuff or the (admittedly doomed) "do not track" http headers; on a protocol level, it can't be enforced, but it can ask well meaning participants to... participate well.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/339?email_source=notifications&email_token=AABZCV42TJOIXOENITFDXXDPXSHLNA5CNFSM4HP6T7E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWKYLOA#issuecomment-496338360, or mute the thread https://github.com/notifications/unsubscribe-auth/AABZCV24DQMRE3KCSRJHVYDPXSHLNANCNFSM4HP6T7EQ .
my suggestion on the mastodon side would be to make a new scope and set that as the default for users. it is possible that some users may truly want to post as:Public content once in a while.
why pretend that authentication is even involved?
Isn't it already possible to require authentication as a server-side software policy? Sure, it's purely "advisory policy" if fetching continues to be possible while unauthenticated. But aren't we in a situation where it's possible to have these access controls while not having a way to advertise these access controls?
Bluntly, the
toandccfields are 100% "advisory policy"
This is probably complicated by the existence of sharedInbox but AFAIK direct delivery via POSTing to an actor's inbox absolutely is not advisory in the slightest. It's no technical guarantee as long as your actor is hosted on someone else's server, of course, but from a purely spec-level view, only the actor should be able to view their own inbox.
At least for the outbox, barring the possibility of forwarding a message, you should be able to advertise what your server will do with GET requests.
why pretend that authentication is even involved?
Isn't it already possible to require authentication as a server-side software policy? Sure, it's purely "advisory policy" if fetching continues to be possible while unauthenticated. But aren't we in a situation where it's possible to have these access controls while not having a way to advertise these access controls?
Yes, it is possible, and as:Authenticated does not change this as it does not advertise that authenticated fetches are needed (unfortunately).
Bluntly, the
toandccfields are 100% "advisory policy"This is probably complicated by the existence of
sharedInboxbut AFAIK direct delivery via POSTing to an actor'sinboxabsolutely is not advisory in the slightest. It's no technical guarantee as long as your actor is hosted on someone else's server, of course, but from a purely spec-level view, only the actor should be able to view their own inbox.
From a purely spec view, to and cc are supposed to be respected. They can choose not to, but that makes their implementation non-compliant. Same thing with as:Authenticated. So, sharedInbox or not, it's advisory policy.
But more important than that, 2000+ LGBTQ teens just had their personal lives put at risk by the current design of ActivityPub forcing self-leaking. We must respond with a mitigation of some kind for this problem so that people stop self-leaking their posts just to allow them to be boosted.
If we want to refer to security labels as "advisory policy," then we should drop as:Public, as it's equally unworthy.
to be absolutely clear, I don't think anyone here is under any illusion that this isn't basically "as:Public, but please interpret me in a different way"
but our patient (the fediverse) is presently gushing blood all over the operating table and the heart monitor is going critical.
to be clear, OCAP is the solution we really need, but we need to stop this bleeding before we can even talk about how to make OCAP work. this is strictly about introducing a mitigation that allows users to stop self-leaking their posts to anybody who drops by, just so they can get boostable posts.
the reason I like this better then some theoretical advisor flag X-I-Observe-Sharing-Levels that it ties scraping/activity to a specific activitypub actor that can be blocked/tracked/etc in the same way we already handle bot accounts. It brings a full class of behaviors into the network in a way that users are used to reasoning about.
But not one that's safe or effective. It also removes private reading from the system and adds a whole new surveillance tool. People should have the right to read without being observed (writing is a different matter). That's extremely absurd when we're saying "oh no, privacy is being violated (in a public setting), the right way to fix this is to add a giant privacy problem"
to be clear, OCAP is the solution we really need, but we need to stop this bleeding before we can even talk about how to make OCAP work. this is strictly about introducing a mitigation that allows users to stop self-leaking their posts to anybody who drops by, just so they can get boostable posts.
My suggestion of sharingLevel wasn't ocap based, in this case. I agree it's a band-aid, and that ocap is the long term solution, but I'm suggesting an alternate band-aid.
Maybe I wasn't understood. My suggestion would look like the following:
{"@type": "SomethingSomething",
"content": "really great stuff here",
"sharingLevel": "DoNotScrape",
"to": ["https://www.w3.org/ns/activitystreams#Public"]}
Then, any http request that doesn't provide X-I-Observe-Sharing-Levels gets denied.
It sucks, but it provides the same "feature" that people who aren't currently in the know to this extension don't even get to see it, and people who are can, and people who want to abuse it... well they can, but they also could with authentication, but this time we didn't open a giant festering privacy problem.
nobody is "self-leaking" posts. they're posting publicly. everyone on Twitter and Tumblr posts publicly all the time, and it hasn't even been an issue until today. I don't think your analysis of the outrage is correct. you're implying that a full cohort of users migrated from a platform where private posting isn't even a thing, and didn't expect to actually be posting publicly. that doesn't make any sense. I think it's much more likely that the source of the outrage is what people have said it is—a group of people overstepping unwritten fediverse norms due to their ideology.
I still think this is a reasonably good proposal, and I think it's good to have, but if cwebber isn't happy including it, I don't think there's anywhere near the type of urgency you're implying there is.
On Mon, May 27, 2019, 10:44 PM William Pitcock [email protected] wrote:
to be absolutely clear, I don't think anyone here is under any illusion that this is basically "as:Public, but please interpret me in a different way"
but our patient (the fediverse) is presently gushing blood all over the operating table and the heart monitor is going critical.
to be clear, OCAP is the solution we really need, but we need to stop this bleeding before we can even talk about how to make OCAP work. this is strictly about introducing a mitigation that allows users to stop self-leaking their posts to anybody who drops by, just so they can get boostable posts.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/339?email_source=notifications&email_token=AABZCV3EBHLYJONVRQY23JTPXSMAVA5CNFSM4HP6T7E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWKZ62I#issuecomment-496344937, or mute the thread https://github.com/notifications/unsubscribe-auth/AABZCV4FZVKPWKHDWEWXSNTPXSMAVANCNFSM4HP6T7EQ .
I'm not sure I exactly understand your comment about "private reading". As I see it, this wouldn't add any additional fetches where they weren't before? (the part about Announces feels somewhat trivial and honestly non-essential, since there's no way to Announce something to someone who isn't already an activitypub actor). so the privacy of reading is isomorphic to what it already was—just swapping a single actor for a single IP
IP tracking isn't great, but people can use all sorts of things (including tor) to read, previously. There also wasn't any requirement previously that fetching be done by a server... it can also be done by clients. This would also break C2S stuff, I think.
But even worse, it adds what's-this-user-reading tracking to the system. Do we really want to add something akin to google analytics to the fediverse? Because I sure don't.
Especially, do we want to add something that opens up that many problems when there's a not-authenticated option that's an equivalent level of effective+broken, without those problems?
the problem with using sharingLevel is that it doesn't really fit into how recipients are calculated, which, at least in Pleroma, we calculate a recipient set and then filter using that.
yes, we could just change it in our IR, but it seems cleaner to just have a special label as we do with as:Public.
I would find as:UsersOnly or similar to be an acceptable label name.
but either way, we need the ability for users to reliably create Announceable posts that aren't part of their outbox collection.
I'm still not sure I understand. how do you get from "only show this object to authenticated users" to "some sort of google analytics tracking" without making additional fetches?
for example, if mastodon implemented this, it probably wouldn't be using any individual user's actor to request the objects, we'd use a system wide Service, since the request would be made on behalf of all users the Announce was delivered to
unless I'm missing something, there's nothing here saying the origin server has to be doing the authentication, which is maybe the sticking point?
fwiw I left out discussion of instance-wide actors because I figured that would be worse than leaving it flexible. should I just say "use an instance-specific actor to sign your fetches"?
but either way, we need the ability for users to reliably create Announceable posts that aren't part of their outbox collection.
for the record, this is not a problem mastodon shares. our only point of ambiguity is "who is allowed to boost a given post?". we've decided that we won't treat boosts of private posts as valid. we could reverse that decision tomorrow (allow all users to boost-by-reference) with minor technical work and it wouldn't change much about the network, just user expectations.
if you use an instance-specific actor to do an authenticated fetch, then that still says nothing about what the instance will do with the content afterward. the instance could show the post in an unauthenticated public timeline (if it were not aware that it shouldn't)
the problem with using sharingLevel is that it doesn't really fit into how recipients are calculated, which, at least in Pleroma, we calculate a recipient set and then filter using that.
yes, we could just change it in our IR, but it seems cleaner to just have a special label as we do with as:Public.
This kind of ties in with two of my big regrets about activitypub, which are two ways that we allowed the actor model to be broken:
a) to and cc shouldn't be being used in S2S for filtering delivery; they should be used for informing who to deliver to in C2S. The original model was, you posted to specific inboxes; targeting was very direct. Receiving-side filtering is pretty broken. Probably we should have said that we strip off to and cc before delivery, and instead have another property like audience be the "keep these people in the loop for replies" property. That should be its only purpose. The fact that it's preserved has clearly confused people about the actor model style delivery that the protocol was intended to represent.
b) "but how does that work with sharedInbox?" sharedInbox never should have been changed at last minute to be a server-side filter-on-receive; we should have gone with the original proposal that the ~sharedInbox like thing allow a header with all recipients on the targeted server to be sent to; that way delivery is still intentional.
Regrets, I've had a few..
stripping off to/cc is one thing, sharedinbox is another thing... i think it's clear how the spec should behave in direct addressing to defined actors or collections. the only real point of contention is what exactly is implied by as#public as it relates to delivery. since as#public is not a real actor, it has to mean something else, and that unfortunately has not been defined at all. what does it mean to have to/cc/audience of as#public? consider mastodon's use of to:public as "public" and cc:public as "unlisted". this is a completely arbitrary distinction that indicates something else is missing semantically.
i.e. there are competing ideas of what addressing/delivery to the public pseudo-collection entails exactly. software should not have any ambiguity in how it handles certain things; to be ambiguous is to be underspecified.
edit: what happens if we hypothetically want to add more scopes? public is all we have currently; authenticated/logged-in is what's being proposed in this issue; suppose we wanted to have friend-of-a-friend scope as facebook or google+ implemented? there really should be a way to advertise what kind of access is allowed, or at least what is intended by the authoring actor. i don't intend this to be an acl-vs-ocap debate, but rather a concern about the issue of auth{entication,orization} scope itself.
if you use an instance-specific actor to do an authenticated fetch, then that still says nothing about what the instance will do with the content afterward. the instance could show the post in an unauthenticated public timeline (if it were not aware that it shouldn't)
The instance could do that either way, authenticated fetches just allow for more control over who gets the object verses unauthenticated fetches. Case in point: instance blocking leaks.
and, yes, this is what i mean with as:Public. we already have something which behaves like a security label. so, lets just admit it's a security label, that it's advisory policy, and move on.
don't like as:Authenticated as a security label? okay, why not as:Users or as:People or whatever. as you admit, the cat's out of the bag.
The problem isn't the label, it's the requirement for authentication, with no extra serious benefit.
What both proposals have in common: acknowledgement of an "advisory" policy in order to read the message.
What's different is only that one of them requires authentication. So what does authentication get you? Somehow I think the belief is that it will allow for abuse moderation? Except that doesn't make any sense. Let's consider a real-world scenario about it.
- Alice's post requires authentication in order to read.
- Bob and Carol both fetch the content, authenticating themselves as the reader.
- One of them leaks it, somewhere. Who leaked it??? How the heck can you tell? Unlike posting a reply, you can't tell who it was that leaked the content, because that information isn't put in the scraped out-of-band area.
So can we drop authentication from this conversation?