#ThoughtProvoker 🤔
-
@kimapr yes, sure is. Thanks for your reply.
-
@ireneista @smallcircles this is also obv not intended to "educate" irenes, but to speak to another case where the legality of recording is actively used to harm (in my case, it arose while i was experiencing illegal discrimination from an employer, which i resolved by switching employers instead of litigating). i see this as complimentary to and distinct from irenes's analysis—irenes proposes the rights-based framework that protects the act of recording (this is a necessary prerequisite to any discussion), while mine instead identifies a structural disadvantage that results from the illegalization of making your own recording (which imperils the free exercise of fundamental rights).
@ireneista i like @smallcircles a lot and think this is exactly the convo we should be having! but i did want to note how OP begins with:
in daily life, if , you have the right to [...]
i expounded at length upon the above interpretation predicated upon adversarial litigation, because i think "daily life" can often be a(n unintentionally) misleading/deceptive framing for the thought experiments we use to understand the future we want to build for each other. i think we absolutely want to construct systems that make sense to our users.
but human rights are not yet universally agreed upon (!), and for people who don't have the experience of recordings being used against them e.g. by law enforcement, "daily life" probably doesn't include the scenarios (like irenes initially proposed in their extremely effective and concise reply) in which fundamental rights would bear upon the answer to this legal policy question. so that's where i might question the framing of "daily life" when used to adjudicate questions around technical capabilities as per OP.
-
@ireneista i like @smallcircles a lot and think this is exactly the convo we should be having! but i did want to note how OP begins with:
in daily life, if , you have the right to [...]
i expounded at length upon the above interpretation predicated upon adversarial litigation, because i think "daily life" can often be a(n unintentionally) misleading/deceptive framing for the thought experiments we use to understand the future we want to build for each other. i think we absolutely want to construct systems that make sense to our users.
but human rights are not yet universally agreed upon (!), and for people who don't have the experience of recordings being used against them e.g. by law enforcement, "daily life" probably doesn't include the scenarios (like irenes initially proposed in their extremely effective and concise reply) in which fundamental rights would bear upon the answer to this legal policy question. so that's where i might question the framing of "daily life" when used to adjudicate questions around technical capabilities as per OP.
@ireneista @smallcircles i do think it's important to consider "daily life" in the context i suspect it was being invoked in for OP, namely to consider the threat model of the user we're building for (and even to acknowledge that there may be multiple such threat models, which may not overlap neatly at first).
signal is effective because it identifies a specific threat model and guarantees user safety within those parameters—for fedi software with an idea of normal usage (e.g. assuming a single human user per account), one immediate consideration arises: who should have access to the recording of a conversation, and how can it be stored? one particular guarantee signal provides is repudiation—in general, a signal message alone provides no cryptographic assurance of the sender's identity. a screenshot of a fedi thread can record a conversation, but it too has no guarantee of correctness (you can edit or fake a screenshot).
in general, screenshots are pretty effective for some types of behavior, but the reporting function on fedi does not rely upon screenshots alone (i'm not sure how reporting works in general but i know this is an area of active study). so in the vein of irenes distinguishing moral right vs convention, it would also be useful to identify ways that recordings are already made, and what role the Delete activity currently plays in reconstructions of the past, so we can then imagine the impact of the policy decision under discussion (i say "imagine" because it's important to accept that there may be unintended consequences)
-
@ireneista @smallcircles i do think it's important to consider "daily life" in the context i suspect it was being invoked in for OP, namely to consider the threat model of the user we're building for (and even to acknowledge that there may be multiple such threat models, which may not overlap neatly at first).
signal is effective because it identifies a specific threat model and guarantees user safety within those parameters—for fedi software with an idea of normal usage (e.g. assuming a single human user per account), one immediate consideration arises: who should have access to the recording of a conversation, and how can it be stored? one particular guarantee signal provides is repudiation—in general, a signal message alone provides no cryptographic assurance of the sender's identity. a screenshot of a fedi thread can record a conversation, but it too has no guarantee of correctness (you can edit or fake a screenshot).
in general, screenshots are pretty effective for some types of behavior, but the reporting function on fedi does not rely upon screenshots alone (i'm not sure how reporting works in general but i know this is an area of active study). so in the vein of irenes distinguishing moral right vs convention, it would also be useful to identify ways that recordings are already made, and what role the Delete activity currently plays in reconstructions of the past, so we can then imagine the impact of the policy decision under discussion (i say "imagine" because it's important to accept that there may be unintended consequences)
@ireneista @smallcircles i'm unfortunately also not familiar enough with AP/Delete to immediately analogize to this exact discussion further. iiuc a Delete request is a remote server requesting my server modify the data it presents to other servers, making it necessarily a censorship API and possible to abuse. one way i have seen this handled that i like is to maintain a public log of deletions (and ideally record the requester and rationale for deletion). this requires care (how can you verify the public log isn't missing entries?), but can be used to balance the needs of transparency with user safety.
-
@ireneista i like @smallcircles a lot and think this is exactly the convo we should be having! but i did want to note how OP begins with:
in daily life, if , you have the right to [...]
i expounded at length upon the above interpretation predicated upon adversarial litigation, because i think "daily life" can often be a(n unintentionally) misleading/deceptive framing for the thought experiments we use to understand the future we want to build for each other. i think we absolutely want to construct systems that make sense to our users.
but human rights are not yet universally agreed upon (!), and for people who don't have the experience of recordings being used against them e.g. by law enforcement, "daily life" probably doesn't include the scenarios (like irenes initially proposed in their extremely effective and concise reply) in which fundamental rights would bear upon the answer to this legal policy question. so that's where i might question the framing of "daily life" when used to adjudicate questions around technical capabilities as per OP.
Thank you. Many good and thoughtful points.
The #ThoughtProvoker hashtag is quite nice in this regard. Where the text is inprecise, it can be thought provoking too. I allow a bit of wordplay now and then. The "daily life" was not deliberate this time, but could have been, as "we all come to the network from our daily life", each with our own subjective experience of what that means. In our own social context and environment. So what does that give? As you point out, there are many nuances that are not immediately obvious, and doing things the "right way" is more difficult that it initially seems.
Personal social networking is the term I chose for SX, where analogies to other familiar social dynamics are considered, as we commonly practice them offline. So we can contrast better how things are different or similar in online environments. And design better social experiences.
https://coding.social/blog/reimagine-social/#personal-social-networking
-
@ireneista @smallcircles i'm unfortunately also not familiar enough with AP/Delete to immediately analogize to this exact discussion further. iiuc a Delete request is a remote server requesting my server modify the data it presents to other servers, making it necessarily a censorship API and possible to abuse. one way i have seen this handled that i like is to maintain a public log of deletions (and ideally record the requester and rationale for deletion). this requires care (how can you verify the public log isn't missing entries?), but can be used to balance the needs of transparency with user safety.
@ireneista @smallcircles from https://www.w3.org/TR/activitypub/#delete-activity-inbox however i find the Delete activity kinda fails to justify its own existence to some degree
7.4 Delete Activity
The side effect of receiving this is that (assuming the object is owned by the sending actor / server) the server receiving the delete activity SHOULD remove its representation of the object with the same id, and MAY replace that representation with a Tombstone object.
This often occurs with SHOULD. It's not MUST, because:
(Note that after an activity has been transmitted from an origin server to a remote server, there is nothing in the ActivityPub protocol that can enforce remote deletion of an object's representation).
this results in the following:
(A) the Delete activity's specified behaviors are all completely optional
(B) without using CAN, MUST, MAY, or SHOULD, the spec asserts, as if it were an uncontestable statement of fact, that any attempt to enforce the desired behavior of the Delete activity is the word of the false prophet -
In daily life, if you talk to someone, you have the right to remember what was said, right?
And if you don't possess photographic memory, you have the right to take notes, keep record, maintain a diary, yes?
And no one has the right to order you to forget your memories, or under normal circumstances to destroy your notes?
So if you have a single-person #fediverse instance, it is okay then to ignore #ActivityPub Delete requests to erase your memory of online public conversations you had with others?
@smallcircles If you give service to the UE, you need to be aware of the Right to be forgotten -> https://gdpr.eu/right-to-be-forgotten/
-
In daily life, if you talk to someone, you have the right to remember what was said, right?
And if you don't possess photographic memory, you have the right to take notes, keep record, maintain a diary, yes?
And no one has the right to order you to forget your memories, or under normal circumstances to destroy your notes?
So if you have a single-person #fediverse instance, it is okay then to ignore #ActivityPub Delete requests to erase your memory of online public conversations you had with others?
@smallcircles
A classical, "it depends" for me:Are we talking only about conversations that involved both of us or everything I posted?
Do you keep it private to yourself or do you make it public?Especially the public / private point would be important to me.
-
@ireneista @smallcircles from https://www.w3.org/TR/activitypub/#delete-activity-inbox however i find the Delete activity kinda fails to justify its own existence to some degree
7.4 Delete Activity
The side effect of receiving this is that (assuming the object is owned by the sending actor / server) the server receiving the delete activity SHOULD remove its representation of the object with the same id, and MAY replace that representation with a Tombstone object.
This often occurs with SHOULD. It's not MUST, because:
(Note that after an activity has been transmitted from an origin server to a remote server, there is nothing in the ActivityPub protocol that can enforce remote deletion of an object's representation).
this results in the following:
(A) the Delete activity's specified behaviors are all completely optional
(B) without using CAN, MUST, MAY, or SHOULD, the spec asserts, as if it were an uncontestable statement of fact, that any attempt to enforce the desired behavior of the Delete activity is the word of the false prophet@ireneista @smallcircles cc @kopper it seems strange to me that the Delete activity exists at all, especially if it can be used to delete literally anything at all. like ideally we assume the Delete arises from the user making the post who wants to delete their own post, but the separate section describing an example Delete has no such permissions checking at all https://www.w3.org/TR/activitypub/#delete-activity-outbox
6.4 Delete Activity
The Delete activity is used to delete an already existing object. The side effect of this is that the server MAY replace the object with a Tombstone of the object that will be displayed in activities which reference the deleted object. If the deleted object is requested the server SHOULD respond with either the HTTP 410 Gone status code if a Tombstone object is presented as the response body, otherwise respond with a HTTP 404 Not Found.
i'm assuming as usual the fedi server is assumed to be acting in response to one of its user accounts, but as-is my admin could just start sending Deletes everywhere without asking me first right? the mastodon quote fep says outright there's no source verification of quote permission responses and that this is a huge problem with activitypub in general (but i think that was a separate-but-related matter of verifying server identity vs the identity of the user requesting the activity).
-
@ireneista @smallcircles from https://www.w3.org/TR/activitypub/#delete-activity-inbox however i find the Delete activity kinda fails to justify its own existence to some degree
7.4 Delete Activity
The side effect of receiving this is that (assuming the object is owned by the sending actor / server) the server receiving the delete activity SHOULD remove its representation of the object with the same id, and MAY replace that representation with a Tombstone object.
This often occurs with SHOULD. It's not MUST, because:
(Note that after an activity has been transmitted from an origin server to a remote server, there is nothing in the ActivityPub protocol that can enforce remote deletion of an object's representation).
this results in the following:
(A) the Delete activity's specified behaviors are all completely optional
(B) without using CAN, MUST, MAY, or SHOULD, the spec asserts, as if it were an uncontestable statement of fact, that any attempt to enforce the desired behavior of the Delete activity is the word of the false prophetAs @Johns_priv just mentioned there's the right to be forgotten. But that would likely only hold for publicly displaying a post. Not deleting it from my own personal archive that my single-person instance represents.
https://gdpr.eu/right-to-be-forgotten/
Hiding it from the public then, potentially. But IANAL nor an expert. GDPR is handled in different ways. Discourse forums for instance have the option to anonymise a person's account name, yet keeps their published posts intact. Seeking a balance with not breaking the public content structure vs. the right to be forgotten. There may be PII in someone's posts. And it gets even more difficult if you consider that PII can be quoted and cross-referenced by others, which should also be processed for strict compliance perhaps.
One thing that stands out to me, time and again, is how unnatural it often is if you come to think of it, and how take it for granted. We 'underestimate' social online, as it were.
-
@smallcircles
A classical, "it depends" for me:Are we talking only about conversations that involved both of us or everything I posted?
Do you keep it private to yourself or do you make it public?Especially the public / private point would be important to me.
@fgraf yes, these are the questions the thought provoker immediately raises. Quite a few reactions on similar lines of thought.
-
@ireneista @smallcircles cc @kopper it seems strange to me that the Delete activity exists at all, especially if it can be used to delete literally anything at all. like ideally we assume the Delete arises from the user making the post who wants to delete their own post, but the separate section describing an example Delete has no such permissions checking at all https://www.w3.org/TR/activitypub/#delete-activity-outbox
6.4 Delete Activity
The Delete activity is used to delete an already existing object. The side effect of this is that the server MAY replace the object with a Tombstone of the object that will be displayed in activities which reference the deleted object. If the deleted object is requested the server SHOULD respond with either the HTTP 410 Gone status code if a Tombstone object is presented as the response body, otherwise respond with a HTTP 404 Not Found.
i'm assuming as usual the fedi server is assumed to be acting in response to one of its user accounts, but as-is my admin could just start sending Deletes everywhere without asking me first right? the mastodon quote fep says outright there's no source verification of quote permission responses and that this is a huge problem with activitypub in general (but i think that was a separate-but-related matter of verifying server identity vs the identity of the user requesting the activity).
@ireneista @smallcircles @kopper it's also really weird that the client-to-server message in §6.4 has a json example while the server-to-server message (the focus of OP) in §7.4 does not provide a json example. it's also strange that the "overview" section only describes client-to-server interactions, explicitly notes that server-to-server interactions are being left out:
Technically these are two separate steps... one is client to server communication, and one is server to server communication (federation).
...and then never follows up? the server interactions section handwaves obsequiously:
In order to propagate updates throughout the social graph, Activities are sent to the appropriate recipients.
what is the appropriate recipient? it's from the appropriate links:
First, these recipients are determined through following the appropriate links between objects until you reach an actor
incredible follow-up:
Delivery is usually triggered by, for example:
usually!
-
@ireneista @smallcircles cc @kopper it seems strange to me that the Delete activity exists at all, especially if it can be used to delete literally anything at all. like ideally we assume the Delete arises from the user making the post who wants to delete their own post, but the separate section describing an example Delete has no such permissions checking at all https://www.w3.org/TR/activitypub/#delete-activity-outbox
6.4 Delete Activity
The Delete activity is used to delete an already existing object. The side effect of this is that the server MAY replace the object with a Tombstone of the object that will be displayed in activities which reference the deleted object. If the deleted object is requested the server SHOULD respond with either the HTTP 410 Gone status code if a Tombstone object is presented as the response body, otherwise respond with a HTTP 404 Not Found.
i'm assuming as usual the fedi server is assumed to be acting in response to one of its user accounts, but as-is my admin could just start sending Deletes everywhere without asking me first right? the mastodon quote fep says outright there's no source verification of quote permission responses and that this is a huge problem with activitypub in general (but i think that was a separate-but-related matter of verifying server identity vs the identity of the user requesting the activity).
@hipsterelectron @ireneista @kopper
I consider this to be part of the "misconceptions" that exist on the ActivityPub fediverse, to once more quote the term as Rich Hickey uses in "Hammock driven development". See:
https://coding.social/blog/grassroots-evolution/#remove-misconceptions
The way I look at ActivityStreams is as a toolbox of social primitives, building blocks for federated solutions. Not as core capabilities of the ActivityPub protocol. Because they are simply not specified as universal and ubiquitous protocol capabilities.
If one particular object supports CRUD is solution-specific in my book. Ideally the ActivityStreams primitives all have well-defined singular purpose, but unfortunately that is not the case. More the opposite where everyone is encouraged to hammer their business domain into an ActivityStreams straitjacket.
-
@ireneista @smallcircles @kopper it's also really weird that the client-to-server message in §6.4 has a json example while the server-to-server message (the focus of OP) in §7.4 does not provide a json example. it's also strange that the "overview" section only describes client-to-server interactions, explicitly notes that server-to-server interactions are being left out:
Technically these are two separate steps... one is client to server communication, and one is server to server communication (federation).
...and then never follows up? the server interactions section handwaves obsequiously:
In order to propagate updates throughout the social graph, Activities are sent to the appropriate recipients.
what is the appropriate recipient? it's from the appropriate links:
First, these recipients are determined through following the appropriate links between objects until you reach an actor
incredible follow-up:
Delivery is usually triggered by, for example:
usually!
@ireneista @smallcircles @kopper if we want to make policy for the fediverse as per this (great) discussion, and particularly for matters regarding information retention, i think we also have to consider the fedi server as an imperfect proxy for the user accounts it represents, because users cannot send Delete requests of their own volition—they must be proxied through the server, who represents all aspects of their identity in the current system.
so if we want to make policy around mutual deletion as per OP, we have to incorporate how each user's admin is currently acting as jesus in the consent meme (except even more powerful, because your admin can also falsify your affirmative consent as well as rescind it over you). i wouldn't call this a "blocker" to solve first (because it's such a big problem), but it's an example of how the fediverse in practice would complicate any policy decision around this matter.
-
@ireneista @smallcircles @kopper if we want to make policy for the fediverse as per this (great) discussion, and particularly for matters regarding information retention, i think we also have to consider the fedi server as an imperfect proxy for the user accounts it represents, because users cannot send Delete requests of their own volition—they must be proxied through the server, who represents all aspects of their identity in the current system.
so if we want to make policy around mutual deletion as per OP, we have to incorporate how each user's admin is currently acting as jesus in the consent meme (except even more powerful, because your admin can also falsify your affirmative consent as well as rescind it over you). i wouldn't call this a "blocker" to solve first (because it's such a big problem), but it's an example of how the fediverse in practice would complicate any policy decision around this matter.
@ireneista @smallcircles @kopper this is actually an example where "daily life" (as per OP) is a great framing, because it exposes how the imposition of the admin into matters of deletion is actually kind of strange! (unless the content harms others or is otherwise a subject of moderation, in which there is a valid legal basis for the admin authority, which is an authority granted conditionally to the admin by the users for purposes of moderation)
-
As @Johns_priv just mentioned there's the right to be forgotten. But that would likely only hold for publicly displaying a post. Not deleting it from my own personal archive that my single-person instance represents.
https://gdpr.eu/right-to-be-forgotten/
Hiding it from the public then, potentially. But IANAL nor an expert. GDPR is handled in different ways. Discourse forums for instance have the option to anonymise a person's account name, yet keeps their published posts intact. Seeking a balance with not breaking the public content structure vs. the right to be forgotten. There may be PII in someone's posts. And it gets even more difficult if you consider that PII can be quoted and cross-referenced by others, which should also be processed for strict compliance perhaps.
One thing that stands out to me, time and again, is how unnatural it often is if you come to think of it, and how take it for granted. We 'underestimate' social online, as it were.
@smallcircles @hipsterelectron @Johns_priv we are a privacy expert but not a lawyer. we're not going to comment on this one, other than to say that companies have a tendency to implement these laws in liability-averse ways, which have very little overlap with what's good for society or people
-
@ireneista @smallcircles @kopper this is actually an example where "daily life" (as per OP) is a great framing, because it exposes how the imposition of the admin into matters of deletion is actually kind of strange! (unless the content harms others or is otherwise a subject of moderation, in which there is a valid legal basis for the admin authority, which is an authority granted conditionally to the admin by the users for purposes of moderation)
@ireneista @smallcircles @kopper kopper has done some really interesting research into how an activitypub server can decouple representations of identity from the mechanical work of post propagation. see especially https://codeberg.org/outpost/ois/src/branch/dev#authentication (cc @dalias—the "nomadic identity in practice" section is extremely interesting). cryptography is described here (often implicitly) as a way to decouple user/account identity from the server identity (and effectively avoids granting the server the implicit right of attorney over all its users)
-
@ireneista @smallcircles @kopper kopper has done some really interesting research into how an activitypub server can decouple representations of identity from the mechanical work of post propagation. see especially https://codeberg.org/outpost/ois/src/branch/dev#authentication (cc @dalias—the "nomadic identity in practice" section is extremely interesting). cryptography is described here (often implicitly) as a way to decouple user/account identity from the server identity (and effectively avoids granting the server the implicit right of attorney over all its users)
@hipsterelectron @smallcircles @kopper @dalias oh! we'll have to give that a look
-
In daily life, if you talk to someone, you have the right to remember what was said, right?
And if you don't possess photographic memory, you have the right to take notes, keep record, maintain a diary, yes?
And no one has the right to order you to forget your memories, or under normal circumstances to destroy your notes?
So if you have a single-person #fediverse instance, it is okay then to ignore #ActivityPub Delete requests to erase your memory of online public conversations you had with others?
@smallcircles I think you'd better remove it from public record even if you keep it available privately.
-
@smallcircles@social.coop thank you, glad im not alone in thinking that "other person can delete my chatlogs" is awful. i should be able to opt out, possibly with a big red "this user does not accept delete requests" notice.
@nycki @smallcircles the mastodon quote fep mentions that a server is allowed to transform rejecting a quote authorization into deleting the entire post (as in, if someone quotes you, you can tell their server to delete their entire post, including their own words, from their own server). this is explicitly described as an acceptable and conformant behavior. not sure why gargron is allowed to write FEPs since he certainly never implements them himself
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi