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: https://github.com/globaleaks/GlobaLeaks/issues/2541 https://github.com/globaleaks/GlobaLeaks/issues/3429

[evilaliv3]

I suggest we could use the following characters for temporary mask ░ (alt+176) and █ (alt + 220) for permanent redaction.

We still then need to understand if we want to preserve the original copy of the answers and of the comments and enable whistleblowers to continue to see them.

What do you all think?

[gianlucagilardi]

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 the case as of now, 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.

[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 https://github.com/globaleaks/GlobaLeaks/issues/3420#issuecomment-1597485837, 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 https://github.com/globaleaks/GlobaLeaks/issues/3420#issuecomment-1605744260, 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_maskinformation: , 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]

https://github.com/globaleaks/GlobaLeaks/assets/9531531/9871cc62-4b54-4bf1-8c88-6187c1d47d01

[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.