Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a mechanism for acknowledgements of Delete activities #406

Open
ThisIsMissEm opened this issue Dec 27, 2023 · 11 comments
Open

Provide a mechanism for acknowledgements of Delete activities #406

ThisIsMissEm opened this issue Dec 27, 2023 · 11 comments
Labels
pending-closure-in-7-days This issue will be closed in 7 days after review Waiting for Commenter

Comments

@ThisIsMissEm
Copy link

Currently when an origin server issues a Delete activity, it's a fire-and-forget action, and there's no guarantees that the deletion was actually actioned. Given the various data privacy laws around the world, I think we will need some mechanism to acknowledge a deletion request.

We could use Accept though this could be ambiguous given Accept/Reject is more used around Follows and other activity types, and it's not like it'd be a really acceptable position to "reject" a deletion request from the user who's data is present on your instance. As such, I think we may need some sort of "Acknowledge" activity that just references another activity and says "yup, I've done the thing".

In very rough form, this may look like:

// Sally Sends to Fred:
{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Sally deleted her account",
  "type": "Delete",
  "actor": "http://sally.example.org",
  "object": "http://sally.example.org/"
}

// Fred responds with an acknowledgement after deleting Sally's data:
{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Fred acknowledged Sally's deletion request",
  "type": "Acknowledge",
  "actor": "http://fred.example.org",
  "object": {
    "type": "Delete",
    "actor": "http://sally.example.org",
    "object": "http://sally.example.org"
  }
}

This could help users' track the deletion of their accounts across the Fediverse, should they decide they want their content's permanently removed; Any instance that doesn't send back an acknowledgement could then be requested to delete the data through legal processes.

@evanp
Copy link
Collaborator

evanp commented Jan 3, 2024

This is probably a useful feature, especially for services concerned with tracking GDPR compliance of downstream processors. However, it's not currently covered in ActivityPub, and it would probably be a nicely-encapsulated FEP. I'd be happy to comment on, and even collaborate on, that FEP, since it has obvious use.

@evanp evanp added the pending-closure-in-7-days This issue will be closed in 7 days after review label Jan 3, 2024
@bumblefudge
Copy link

me too! i think lots of diff kinds of implementation need this. tag me in the PR or draft PR!

@ThisIsMissEm
Copy link
Author

ThisIsMissEm commented Jan 3, 2024 via email

@bumblefudge
Copy link

bumblefudge commented Jan 4, 2024

I think this would make for a powerful FEP, not just for activities that the originating actor asks to be deleted, but also legal/copyright takedowns, etc. my question is whether it makes sense to have a single delete activity just for activities, or whether it might be possible to model this beyond activity objects to also work with attachments, which have a different identification/deduplication story across software (ISCC?) and which are not as neatly "owned" by originating actor.

@bumblefudge
Copy link

opened a FEP-ideas issue and linked back here, so close away!

@snarfed
Copy link

snarfed commented Jan 4, 2024

@bumblefudge do you mean eg media that instances make copies/transcodings of and host themselves, like masto.host on their CDN?

@bumblefudge
Copy link

right, transcodings, upscale/downscale might happen in that form of opinionated federation case, but i'm also thinking about the copyright/IP takedown case where some server may want to detect and/or verifiably remove not just the one version of, say, a copyrighted film that got taken down upstream, but also check its buckets for variants that have been tinted a little or cropped a few seconds short to break its hash.

@ThisIsMissEm
Copy link
Author

@evanp I think we should probably keep this open, perhaps a "awaiting FEP" label would be appropriate?

@ap-socialhub
Copy link
Collaborator

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/report-errors-in-server-processing/3006/15

@ThisIsMissEm
Copy link
Author

right, transcodings, upscale/downscale might happen in that form of opinionated federation case, but i'm also thinking about the copyright/IP takedown case where some server may want to detect and/or verifiably remove not just the one version of, say, a copyrighted film that got taken down upstream, but also check its buckets for variants that have been tinted a little or cropped a few seconds short to break its hash.

@bumblefudge Yeah, I'd say that's safely out of scope for this proposal; that falls more under a Content ID system which can and absolutely has been abused (see Russian trolls claiming copyright over Ukrainian videos on youtube)

@ThisIsMissEm
Copy link
Author

@evanp can we change this to needs-fep ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending-closure-in-7-days This issue will be closed in 7 days after review Waiting for Commenter
Projects
None yet
Development

No branches or pull requests

5 participants