Consider policy on informing people when we get requests to takedown elements of "their" correspondence threads and/or if we actually remove material from them

[RichardTaylor]

We currently have a policy of running the service as transparently as possible, and giving reasons for taking material down where we can.

If we annotate a correspondence thread the requester will be informed.

We don't currently routinely inform users if we get a takedown request which we reject (though we may add an annotation in such circumstances).

We don't routinely inform users if we apply a "censor rule" to their request, or hide / make "requester_only" an element of the correspondence, though in some of cases the action will be visible to all on the thread.

[garethrees]

I don't think we should manually do this – it'll generate a lot of support mail.

Better would be to create a visible event (maybe visible only to the request owner?) that shows "censor rule has been added" or similar. Same idea as in https://github.com/mysociety/alaveteli/issues/4565.

[mdeuk]

Better would be to create a visible event (maybe visible only to the request owner?) that shows "censor rule has been added" or similar. Same idea as in mysociety/alaveteli#4565.

This would make our life a little easier when responding to Right of access requests - although we would maybe need to be able to dynamically 'unfold' the original version.

mysociety/alaveteli/#6267

[RichardTaylor]

Linking to: Option for censor rules to only apply to public presentation of request https://github.com/mysociety/alaveteli/issues/5412 as a user who is alerted to the fact their request has been redacted may well want to see the original material.

[garethrees]

Related to clarifying ownership of content https://github.com/mysociety/whatdotheyknow-theme/issues/841

[RichardTaylor]

We do consider this on a case by case basis. Some notes on recent practice can help making that case by case decision in the future:

• Consider if we want the requester's input to the takedown decision. They may be a subject-matter expert. They may know how the material has been used/misused.
• Consider if informing the requester could reduce harm. If there is sensitive material in a response we might let the requester know so they don't republish/reuse it and make the issue worse. We need to take care, and consider if pointing to the problematic material could exacerbate a problem.
• Consider if we might want to give the requester the chance to obtain material in a situation where we might otherwise delete it (in a case of a bulk data breach), eg. if they are trusted academic / journalist / MP etc. [We haven't done this yet]

Note that following subject access requests asking for information about who requested a takedown of a user's request - we generally do have to identify any organisation which requested the takedown, but usually do not have to, and do not, identify any individual.

[RichardTaylor]

It might be useful to consider what our presumption / starting point should be:

Do we inform users unless there's a reason not to? Do we only inform users where we are reasonably sure doing so won't cause unwarranted harm?

There is also a question here of how actively we inform users. Sending them a specific email, is different from inserting a note into a correspondence thread and not drawing attention to it.