GDPR Compliance: Make it possible to mask (hide) parts of reports (such as unnecessary personal info)

[danielvaknine]

Proposal

We suggest that recipients can be enabled the ability to redact parts of reports or chats with the whistleblower (like they can be enabled the possibility to delete the cases as a whole). This is important when it comes to e.g. unnecessary personal information or other sensitive data that the receiving party has no right to process and/or keep.

The function would not straight-off delete the text, but only redact it, as seen below

The original info can still be shown to the whistleblower.

More advanced implementations could also be evaluated, such as that another recipient must approve the redacting, that a comment must be made to the redaction or that the redacted text could be retrieved. However, what's most important is that recipients can have the ability to, if needed, hide or delete certain unnecessary parts of reports.

Motivation and context

This function would be needed to make the platform fully compliant with the GDPR by enabling the redaction of sensitive personal information not needed for the investigation. It could also be used to e.g. hide the whistleblower's identity before granting access to other recipients (that the whistleblower may not know would get access to the report, hence their identity should be hidden) and many other important aspects of a fully-compliant whistleblowing channel with high levels of integrity and whistleblower protection.

Related tickets:
#2541
#3429

[evilaliv3]

Thank you @danielvaknine for your valuable feedback.

This proposal is something we are considering not only in relation to the general principles of the GDPR but as well in relation to Article 17 of the European Directive on Whistleblowing that is built on it an states:

Such an article appear to us not so trivial to be implemented and we are hoping that the legislator will provide advice especially that Article 17, competes with the principles of Article 12:

This article primary requires that reporting channels "are designed, established and operated in a manner that ensures the completeness, integrity and confidentiality of the information and prevents access thereto by non-authorized staff members of the competent authority". This requirements is stated just for external reporting channels but as the principle is very general we consider it had probably to apply to both the two types of channels

For this reason it is not clear if:

• does article 17 refer to any information possibly collected in the process including the evidences or just to a part of the process?
• if it applies to the evidences how could the process guarantee the integrity (i.e. forensic validity) of an official evidence if the process impose to invalidate the evidence?
• how should the recipient department work in relation to authorizations on this matter and how to properly keep track of the reasons of deletion of the redacted details?
• how should operate the organizations where the person mandated to manage the reports is one?

We could definitely start addressing the possibility to redact information and produce a copy of the report that do not export redacted information but it is very unclear what to do in relation to actual ultimate deletion of such information.

[gianlucagilardi]

@danielvaknine redaction, at least as far as GDPR goes, is not deletion thus redaction would unlikely lead to art. 17 compliance.

@evilaliv3 food for thought: is voluntary deletion of a record in a DB (more so if this deletion is mandated by law) an integrity violation? If the answer is yes then any deletion of a record containing personal data (even by request of the data subject) should be considered a data breach, with all the relevant GDPR consequences.

[danielvaknine]

Thanks @gianlucagilardi for your feedback! We meant redaction as deletion, but where it is still visible what text was deleted, as the image in the ticket above.

@evilaliv3 , I completely understand the difficult situations/questions you pose and respect that they are no "easy fix". However, we believe that enabling the redaction of data is important to let the user handle reports in the way they want to. We don't believe that the GlobaLeaks platform should tell users how to work in relation to the GDPR and other data processing, but rather enable them to work with it according to their own interpretations.

In this way, those who don't want to enable redaction can keep it that way, while those who do want to enable it can. Many law firms put redaction as a requirement for whistleblowing platforms to be fully compliant, and we want to enable organisations to follow the interpretation they want (while still making sure status quo can be used).

Should we really decide for the organisations how to interpret these complex regulations?

[gianlucagilardi]

Thanks @gianlucagilardi for your feedback! We meant redaction as deletion, but where it is still visible what text was deleted, as the image in the ticket above.

@evilaliv3 , I completely understand the difficult situations/questions you pose and respect that they are no "easy fix". However, we believe that enabling the redaction of data is important to let the user handle reports in the way they want to. We don't believe that the GlobaLeaks platform should tell users how to work in relation to the GDPR and other data processing, but rather enable them to work with it according to their own interpretations.

In this way, those who don't want to enable redaction can keep it that way, while those who do want to enable it can. Many law firms put redaction as a requirement for whistleblowing platforms to be fully compliant

I myself am having a quite a hard time arguing art. 17 compliance of the platform at the moment and I can definitely relate to the struggle of lawyers on the issue at hand.

[evilaliv3]

Thank you both for your feedback and i understand your points.

There are many points of which i think we have consensus here and we could:

• make it possible to redact (hide) a full answer or a part of an answer or file while still preserving the original
• make it possible to assign users the privilege of redacting parts of the report
• make it possible to assign users the privilege to see the redacted parts of the report
• make it possible to export a redacted copy of the report and of the file evidences

The part on which instead at the moment different opinions exist is if the original should be preserved to preserve the integrity of the forensic evidence or if it is acceptable to invalidate the evidence to pursue article 17.

Regarding the question:

Should we really decide for the organizations how to interpret these complex regulations?

I do not have an answer that is probably representative for anyone but i can give my answer to this question that is "definitely yes" and i consider this is the vision at the base of the creation of globaleaks project and shared by most of the contributors.

It is great that the software complies for the most with the existing regulations and we will try to continue to guarantee this, but let me say that this is just a state of facts and it was not the original goal.

GlobaLeaks is a project started 13 years ago to support whistleblowers before any regulations existed and has at it's base the will to support the creation of a community of whistleblowers protection activists and stimulate the creation on a best practice on the matter. The configurations and the functionalities implemented are the results of continuous improvements thanks to the research on the matter by the early adopters that worked and made lobbies together to try to get whistleblowing protection laws.
The fact that an European, powerful, directive exists is such a noticeable result but the fact that the transpositions appear to be for the most poor translations enabling every possible interpretation does not mean our work is ended and all the research previously performed should vanish.

[evilaliv3]

I removed one of my previous argument because incorrect in relation to the usage of "shall" that should in fact be read as a "must".

[danielvaknine]

Thanks @evilaliv3 for your comments! I agree regarding where we have a consensus and I believe these bullet points are key functions. Then, later on (if that's what's agreed then), it's a smaller step to go from "redaction" to "deletion", if even necessary.

Adding one potential proposal (that could potentially replace your third point.

• Only the user that made the redaction can undo it (to avoid a situation where one user redacts a part, grants access to a different user (that shouldn't see the redacted information) and this new user un-redacts that part, or such).

I understand your explanations on GlobaLeaks stand on helping organisations comply. Let's keep it that way!

Perhaps we should try involving more parties to get their thought on the matter?

What more can we provide to help begin/before beginning the development?

[evilaliv3]

Thank you @danielvaknine for your feedback that was very fruitful.

Based on your feedback in fact i consider we just need a single privilege to enable a user to redact (and unredact) information;
This privileged could be probably specified: "Give this recipient the ability to redact reports."
Based on such extension we could give all users that have the privilege the possibility to see the original, redact new parts or underacts part of the report redacted by others.
All the users without the privilege instead will have only access to the current status of the report without the possibility to read its redactions.

This said regarding "how could we support development?

There are many activities actually that even non developers could support and that are part of the research and development of every feature.

• Trying to look at other software that implement similar features and provide simple sketches of how you imagine the feature to work
• Trying to think to all the needed texts to implement the functionality.
• Make diagrams that clarify how the functionality should work in relation to the other existing functionalities.

From a development standpoint I consider the main challenge will be identifying technically how to make it possible to redact part of the text without enabling users to hand craft an arbitrary message fully replacing what has been reported; this would in fact result in a significant vulnerability of the whistleblowing process especially if combined in the possibility to permanently save the result of the redaction activity removing the original answer. This in the context of a web application is actually not trivial.

I agree that Its worth to continue including more users in these evaluations to get proper understanding that could the be translated in the development.
This would help and stimulate developers interested in developing this feature to possibly move forward this implementation.

Probably at this stage other users that cold participate in the feature design are: @pablovigo @maxmois @elbill @giorgiofraschini and @msmannan02

[evilaliv3]

@danielvaknine: as an example of the activity we should try to do together i've created this prototype: https://jsfiddle.net/uv3nLoc6/

I've produced a small prototype where i'm simulating few questions and an interface enabling to redact the information.
If you would like give it a try and provide feedback.

At the moment i consider the interface would result very ackward due to the redundancy of buttons.
while developing a good features we should consider in fact these aspects of usability.
We should consider for example how to implement a proper compact interface and use it in the whole application in relation for example to free text answers and to messages.

In this demo implementation, instead of letting the user edit the text directly i'm just collecting the coordinates of the texts that should be redacted.

[danielvaknine]

Really like your sketch @evilaliv3 !

As you mentioned, the problem is the redundancy of buttons. I therefore suggest having an erase-button like in this (very simple) Figma sketch: https://www.figma.com/proto/J0qiKkDez2aGfGgKAD3949/Untitled?node-id=1-22&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=1%3A22

Basically having a very discrete erase-button, which then (when you click the erase-button) show the redact/unredact buttons. There could probably be just one erase-button for the whole questionnaire with the redact/unredact buttons in the end, and then one set of these for every whistleblower message.

It would be much more discrete and not interrupting or distracting the user by not spotlighting the redact function, but rather enabling it when it is needed

[gianlucagilardi]

As far as permanent deletion of information is concerned, please also see https://edps.europa.eu/sites/default/files/publication/19-12-17_whisteblowing_guidelines_en.pdf, especially chapter 4 § 15:
"EUIs may sometimes come into possession of personal information, which is clearly of no interest or relevance to the allegations. Any such information should not be further processed. This is particularly important for special categories of information. All investigators should be made aware of this rule."
And by now we all know that the fact that storing an information is "processing" according to the GDPR :)
I appreciate the concerns that the provision of art. 17 introduces some new vulnerability to the WB process, but I honestly fail to see how we can maintain compliance while not providing (some) recipients the ability to permanently remove information.

On the construens side let me point out that the whole WB system as provided for by the directive does provide some "failsafes" for investigation tampering (e.g., by deleting data) since the whistleblower can escalate to external channels or even to the media in the event the internal channel fails to address appropriately the facts (s)he is providing notice of.

[danielvaknine]

@gianlucagilardi A very interesting point that we would need to investigate further. But I personally agree with you.

However interpretation, development of the function could proceed since it would either be a) unredactable or b) permanently deleted.

There could also be an alternative c) where admin can assign users ability to either "temporarily" redact or permanently delete, i.e. 2 different levels. The issue could however be more development time and a bit more complex for admins to interprete.

[evilaliv3]

Really like your sketch @evilaliv3 !

As you mentioned, the problem is the redundancy of buttons. I therefore suggest having an erase-button like in this (very simple) Figma sketch: https://www.figma.com/proto/J0qiKkDez2aGfGgKAD3949/Untitled?node-id=1-22&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=1%3A22

Basically having a very discrete erase-button, which then (when you click the erase-button) show the redact/unredact buttons. There could probably be just one erase-button for the whole questionnaire with the redact/unredact buttons in the end, and then one set of these for every whistleblower message.

It would be much more discrete and not interrupting or distracting the user by not spotlighting the redact function, but rather enabling it when it is needed

Compared to my small prototype of few hours of work, your suggestion is definitely what we should look at and very interesting from an end user perspective. We should try to understand how to onboard some developers on this matter and we may try to coordinate them on the development.

[evilaliv3]

As far as permanent deletion of information is concerned, please also see https://edps.europa.eu/sites/default/files/publication/19-12-17_whisteblowing_guidelines_en.pdf, especially chapter 4 § 15: "EUIs may sometimes come into possession of personal information, which is clearly of no interest or relevance to the allegations. Any such information should not be further processed. This is particularly important for special categories of information. All investigators should be made aware of this rule." And by now we all know that the fact that storing an information is "processing" according to the GDPR :) I appreciate the concerns that the provision of art. 17 introduces some new vulnerability to the WB process, but I honestly fail to see how we can maintain compliance while not providing (some) recipients the ability to permanently remove information.

On the construens side let me point out that the whole WB system as provided for by the directive does provide some "failsafes" for investigation tampering (e.g., by deleting data) since the whistleblower can escalate to external channels or even to the media in the event the internal channel fails to address appropriately the facts (s)he is providing notice of.

Your reply is definitely on point.

With this simplistic read of article 17 we are definitely not compliant here and we should be trying to reach out for advice to the regulators explaining our concerns.

[JaviAlama]

Good morning, I would like to offer my opinion on this issue.

Based on our experience:

1- All information sent to us by a whistleblower must always be kept in the same format and with the same content unaltered, integrity depends on this. If a complaint ends up in court we must be able to present all the evidence as we receive it.
2- Globaleaks, in our case, is used as a complaint mailbox and as a way of communicating with the whistleblower, but not as a tool for processing complaints. In the processing tool, if necessary, copies of the documentation and information provided through the mailbox are incorporated, and all information that is not necessary is anonymised or censored in this tool.
3-About art. 17 of the Directive, it talks about the information collected during processing. This does not include information included in the complaint itself.

In summary, I believe that an original, complete and immutable version of the documentation and information received should always be kept, and that if any part of it can be censored, it should always be from a copy.

[gianlucagilardi]

3-About art. 17 of the Directive, it talks about the information collected during processing. This does not include information included in the complaint itself.

I am afraid the EDPS does not agree with your interpretation (https://edps.europa.eu/sites/edp/files/publication/19-12-17_whisteblowing_guidelines_en.pdf, page 6)

"4. AVOID PROCESSING EXCESSIVE PERSONAL INFORMATION
15 EUIs may sometimes come into possession of personal information, which is clearly of
no interest or relevance to the allegations. Any such information should not be further
processed. This is particularly important for special categories of information. All
investigators should be made aware of this rule.
Example 2: A whistleblower reports that a colleague has committed fraud. Within his
statement, the whistleblower happens to disclose information about his colleague’s health
situation. It is clear to the institution that this information is completely irrelevant to the
reported wrongdoing, and therefore it should not be further processed or returned to the
sender."

[JaviAlama]

Are you sure? I think I am right.

If medical data or religious ideology of a denounced person appear in a complaint and they are not relevant to the facts denounced, what should be done is to ignore them in the management of the complaint, in other words, not to process them.

That is what I mean, one thing is the information that the whistleblower wants to provide us with and afterwards the information that we use during the processing of the complaint, which we normally do not do from the complaint mailbox itself but from another tool.

On the other hand, in our case, in the management of the complaints we base ourselves on the facts, not on personal information, we treat nominative complaints in the same way as anonymous ones, and other information not related to the facts is not transferred to the processing.

We apply "Data Minimisation" (GDPR Art 5c) in relation to their processing.

[gianlucagilardi]

Are you sure? I think I am right.

If medical data or religious ideology of a denounced person appear in a complaint and they are not relevant to the facts denounced, what should be done is to ignore them in the management of the complaint, in other words, not to process them.

Since we are discussing GDPR and data protection here, the mere fact of storing some information which can be construed as personal data is processing.

"‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;" (GDPR, art. 4.2)

Thus, if I have to stop processing data i have to permanently delete them or make them anonymous (at least sufficiently so, following the Breyer principles)

[evilaliv3]

I agree. Probably for the moment we need to live with the fact that recipients will have the possibility to temper the data permanently with the impossibility to keep the original. Enable for the whistleblower the possibility to download the full report including the original file requires to make them available files for download in first place that opens to some vulnerabilities.

…

On Mon, Jun 19, 2023, 6:52 PM Gianluca Gilardi ***@***.***> wrote: This actually has no straight answer. The first question is: do we want to enable the whistleblower to download a copy of the report (which is *not* actually the case IMU)? If the answer is no, fine, no further action is required. If the answer is "yes" then we should change the current workflow and - as previously discussed - the only way to have compliance is to have a separate copy of the report generated encrypted with the whistleblower encryption key prior to any permanent deletion/redaction and thus have a history of the report, The whistleblower then would need some UI to download all the "prior to redaction" report(s) which would then need to be packed as non-encrypted content prior to download. In a very perfect world we would have any version timestamped, but at the moment I have no idea on how we could have a third party-issued timestamp integrated with the platform. — Reply to this email directly, view it on GitHub <#3420 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU7SQVSMCJ7CR6NYRWAQLXMB7TTANCNFSM6AAAAAAW4BR5HE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[msmannan00]

Hello again I am sharing the live demo for you guys to comment better. the icon that @evilaliv3 mentioned (I suggest we could use the following characters for temporary mask ░ (alt+176) and █ (alt + 220) for permanent redaction.) will update them on monday

https://demo.whistleaks.com

username: recipient
password: UmT@123456789
username: admin
password: UmT@123456789

[danielvaknine]

Hi Abdul, thank you! How can we test redacting? Is there a user login?

…

On Sat, 24 Jun 2023, 23:43 Abdul Mannan Saeed, ***@***.***> wrote: Hello again I am sharing the live demo for you guys to comment better. the icon that @evilaliv3 <https://github.com/evilaliv3> mentioned (I suggest we could use the following characters for temporary mask ░ (alt+176) and █ (alt + 220) for permanent redaction.) will update them on monday https://demo.whistleaks.com — Reply to this email directly, view it on GitHub <#3420 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZXMC4KGU4TZ3LSBPUTKCE3XM5NQFANCNFSM6AAAAAAW4BR5HE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[msmannan00]

Hi Abdul, thank you! How can we test redacting? Is there a user login?
…
On Sat, 24 Jun 2023, 23:43 Abdul Mannan Saeed, @.> wrote: Hello again I am sharing the live demo for you guys to comment better. the icon that @evilaliv3 https://github.com/evilaliv3 mentioned (I suggest we could use the following characters for temporary mask ░ (alt+176) and █ (alt + 220) for permanent redaction.) will update them on monday https://demo.whistleaks.com — Reply to this email directly, view it on GitHub <#3420 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZXMC4KGU4TZ3LSBPUTKCE3XM5NQFANCNFSM6AAAAAAW4BR5HE . You are receiving this because you were mentioned.Message ID: @.>

yes these are the credentials. its a test server

username: recipient
password: UmT@123456789
username: admin
password: UmT@123456789

[gianlucagilardi]

@msmannan00

I am afraid there is some glitch: post masking the masked information is still visibile in the report page, it somehow defies the whole masking concept :)

[msmannan00]

@msmannan00

I am afraid there is some glitch: post masking the masked information is still visibile in the report page, it somehow defies the whole masking concept :)

yes this is suppose to happen. in case of temporary masking text would not be updated. it would just show when a recipient with rights clicks the edit button. In image you can see a button called permanently redact. click on it. when you do the entire report would be redacted even from the database and ui would no longer contain this button and you would start to see **** on questionare answers directly

[msmannan00]

as requested ascii for temporary and permanent masking changed

[danielvaknine]

Hi and thanks for the demo!

We've been testing it a bit and everything looks great except one minor detail, also mentioned above.

It's difficult to as a recipient understand that you have masked the part you just masked. It says "Are you sure?" and then the options are "Mask" and "Redact", see below.

Somehow, the recipient should be told that the part was successfully masked. As it is now, it feels like something went wrong when you need to close the popup-box without any confirmation and with the question "Are you sure?" still present.

Do you understand what we mean?

[danielvaknine]

We've looked a bit further and it seems that a string is not masked until the user clicks "redact", as in the image in the previous comment.

For masking, we therefore suggest that it instead says:

When having something masked already and wanting to mask a new part, it looks like this (which is rather confusing):

We instead suggest, in accordance with the first image in this comment, that "Mask" changes to "Cancel" and "Redact" changes to "Confirm", "Confirm masking" or similar (and perhaps change positioning then):

In summary

1. The current word "redact" does not really mean "redact", it instead means "confirm masking". Thus it should be updated to ask "Cancel" or "Confirm" after masking.
2. It is very easy to think that you masked something but you actually didn't. You need to click edit again to double check

Would be happy to hear your thoughts @msmannan00 @evilaliv3 @gianlucagilardi and others

[fidi1713]

Is there a possibility to let the whistleblower decide wether he reports anonymous or confidentially? I know I can create a new question in questionnaire but then I don`t have the possibility to get statistics how many whistleblower reported anonymously or confidentially.

[msmannan00]

So this is the updated masking popup model as discussed.

1. Textbox added at top that would always contain current version of text. permanent masking will remain same while temporary would be ignored in above box
2. Bottom box will contain masking logic
3. Switch has been added for the user with both temporary and permanent masking right which is default on temporary masking but can switch to permanent only if data is temporary masked already
4. now their are only three option select unselect and save.

--- For Temporary masking

Select: User would be able to select and mark temporary area
Unselect: User would be able to select and unmark temporary area
Save: The changes made to text both temp mask and unmask will be saved to server

--- For Permanent masking

Select: User would be able to select and mark permanent masking only for the area where text is temporary masked and rest of the text would not be selectable to mark
Unselect: User would be able to select and unmark temporary area to normal text and permanent to temporary text
Save: The changes made to text both permanent mask and unmask will be saved to server

Server checks also implemented to avoid client side attack of forged data

[msmannan00]

def update_tip_masking(session, tid, user_id, rtip_id, id, data, tip_data):
"""
Transaction for updating tip masking

:param session: An ORM session
:param tid: The tenant ID
:param user_id: A user ID of the user performing the operation
:param rtip_id: The ID of the rtip accessed by the user
:param id: The ID of the masking to be updated
:param data: The updated masking data
"""

user_data = session.query(models.User).get(user_id)
masking_data = data.get('data', {})

masking = session.query(models.Masking).get(id)
_, rtip, itip = db_access_rtip(session, tid, user_id, rtip_id)

if masking and masking.internaltip_id == itip.id:
if user_data and user_data.can_privilege_delete_mask_information:
_, rtip, itip = db_access_rtip(session, tid, user_id, rtip_id)

      if 'content_type' in masking_data:
          content_type = masking_data['content_type']
          if content_type == "comment":
              model = session.query(models.Comment).get(masking_data['content_id'])
              db_mask_comment_messages(session, tid, user_id, itip, id, masking_data, tip_data, "comments", model)
          elif content_type == "answer":
              db_mask_answer(session, tid, user_id, itip, id, masking_data, tip_data)
          else:
              print("No valid content type found")


  if user_data and user_data.can_privilege_mask_information:
      db_update_masking(session, tid, user_id, masking, id, masking_data)

so this is the latest changes for to ensure rights, had tested with several seniarios and fake clients

1. (masking and masking.internaltip_id == itip.id) This make sure the user has right to the report whose masking he is trying to manipulate
2. (if user_data and user_data.can_privilege_delete_mask_information) this ensures that he has the delete masking priviledge on this report
3. (user_data and user_data.can_privilege_mask_information) this ensures that he has the masking priviledge on this report
4. No extra data that can help in manipulation is being passed in request

[msmannan00]

2023-09-25-10_43_36.592534529.mp4

[msmannan00]

Some small suggested changes

One major improvement below

1. In case if user have only right to permanent mask, when he opens dialog reduction would be set as default. when he would shift to masking he would only be able to select and unselect from existing temporary masked text. selecting text outside that would be ignored and would have no effect

2. Now if after data is unmasked completely without ever masking permanently, the masking entry for that particular would be removed from database

[msmannan00]

Code is almost merged with devel, will make merge request shortly

[fidi1713]

How is the status with this feature? When do you think can we implement it? Would be really good according to confidentiality and data protection if people want to share a case with others.