Deletions and edits #889
-
|
This is a question about the security guarantees of the bluesky software and ATP more generally. If a user deletes or edits a post, what is the nature of that action, security-wise? Does the server continue carrying a copy of the old data, or is it securely discarded? How quickly will the action be replicated to other servers in the federation? Is the software designed to ensure deleted data is irretrievable, to the best of its ability? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 6 replies
-
|
It would be pretty easy to modify a PDS / server / federated instance in order to save a copy of all posts, and this will probably happen. For example, this happens with Reddit: https://www.unddit.com/ |
Beta Was this translation helpful? Give feedback.
-
|
I'm aware that posts can be saved by an external client or modified server, but this doesn't really answer my questions w.r.t. the AT Protocol. |
Beta Was this translation helpful? Give feedback.
-
|
To put it another way: If I were implementing at ATP server, is there any situation where I would have to serve deleted or outdated data in order to comply with the standard? Since ATP works kind of like a git repository, with each commit building on the previous commit, I'm wondering how much old data is retained in the system. |
Beta Was this translation helpful? Give feedback.
-
|
Right now, the commit hash chain and Merkle Search Tree architectures seem to preclude truly deleting things from individual user repos. Moderation plans are at a higher level, https://blueskyweb.xyz/blog/4-13-2023-moderation . Users and servers would use labels to hide things instead of deleting them outright. Federation obviously usually means that one PDS can't necessarily make another one delete data if it doesn't want to. In those cases, you'd moderate or block the data, users, or servers instead. Your question still stands though:
Another framing is, if another PDS has illegal material (eg CSAM), and your PDS syncs it locally, eg if one of your users follows that user, can you remove that material from your PDS? I believe the answer is yes. As the PDS admin, you'd block/unsync the remote user and drop their repo from your PDS. The Bluesky team is actively working on questions like these and tools for them right now. |
Beta Was this translation helpful? Give feedback.
-
|
Daniel or Devin should answer this, but essentially there's an operation called "rebase" which modifies the history of a repo. This can be used to clear edited and deleted items out of the history, and it does propagate through the network. We're still learning about the performance characteristics of the operation before we work it into the UX. Once the data leaves the server, the only thing that can stop servers from hosting deleted data is social contract / social pressure. There's some discussion about what kinds of terms of service might be required for replication, but serving deleted data could be examined under that kind of lens or via regulation. |
Beta Was this translation helpful? Give feedback.
-
|
Yup that about nails it As an update, we're getting in rebases soon: #948 & we also do delete blobs & associated media when the record that referenced them is deleted |
Beta Was this translation helpful? Give feedback.
-
|
Hi, in the time since this discussion was posted there has been some implementation work on rebasing. The experiments and discussion resulting from that work seems to indicate the dev team considers rebasing to be too slow and heavyweight, and they are looking at alternatives. What sort of alternative methods to perform deletions and edits are under discussion? |
Beta Was this translation helpful? Give feedback.
-
|
There's some active work happening on this that seems to be yielding positive results, but I think the team is hesitant to share until they've confirmed it will work. I'll let @dholms share more. |
Beta Was this translation helpful? Give feedback.
-
|
Yup that's right. There's an ongoing discussion about removing repo history from the canonical repo state (so no |
Beta Was this translation helpful? Give feedback.
-
|
Have you considered using Chameleon Hashes (conveniently, you already a key pair that can be used!)? In principle they would let you delete content from a record in-place while preserving the hash and in constant time with respect to the repo size, and not have to perform an actual rebase, which would (a) potentially be quite expensive, and (b) presumably break links? since all records thereafter would have different hashes too? |
Beta Was this translation helpful? Give feedback.
-
|
I actually wasn't aware of chameleon hashes. Thanks for the post! Unfortunately we don't want to use that because the hash is important for integrity checks - ie "I like this post at this version" where the version is a hash. We are having conversations about leaving dangling references in the repo so we can delete real-time, but need to properly research that before throwing it in |
Beta Was this translation helpful? Give feedback.
-
|
Interesting, thanks for the info. I see why that rationale makes sense for edits, I'll have to stew more on why it applies to record deletion as well. |
Beta Was this translation helpful? Give feedback.
Daniel or Devin should answer this, but essentially there's an operation called "rebase" which modifies the history of a repo. This can be used to clear edited and deleted items out of the history, and it does propagate through the network. We're still learning about the performance characteristics of the operation before we work it into the UX.
Once the data leaves the server, the only thing that can stop servers from hosting deleted data is social contract / social pressure. There's some discussion about what kinds of terms of service might be required for replication, but serving deleted data could be examined under that kind of lens or via regulation.