yourdigitalrights.org icon indicating copy to clipboard operation
yourdigitalrights.org copied to clipboard

Capture user's email on request send

Open yoavaviram opened this issue 3 years ago • 3 comments

Add an email address to the BCC field of the user's data request email. The address should be of the following form: [email protected]

Where $UNIQUE_ID$ is the ID generated in issue #159

AWS SES should capture the incoming email and update the DB record with:

  • Request sent date & time (taken from the email headers)
  • Destination email address(es)
  • User email address
  • Request text

yoavaviram avatar Mar 16 '21 09:03 yoavaviram

What do we want to Store? In order to minimize the information we store, let's define two different types of data collection.

  1. A user does not want to receive follow up emails. In this case, we track:
    • UUID: Generated on the client side (or server prior to rendering the form). This UUID tracks the request.
    • Request Type: Delete/SAR
    • Regulation Type: GDPR/CCPA/etc
    • Current Date and Time: When the "Review your request" was clicked
    • Organization: The organization's domain
  2. A user wants to recive follow up emails (https://github.com/your-digital-rights/yourdigitalrights.org/issues/160). In this case, we track:
    • The above fields
    • Sent: This is initially not set. When the email comes in with the BCC, we update the record to set this to the date and time the email was sent. In practice, this will likely happen relatively shortly after the "Review your request" button was clicked.
    • Full Name: Directly copied from the form. Used to populate the reminder page. After the final email is sent, should be deleted from our DB.
    • Additional information: Same handling as full name.
    • Email: Same handling as full name.
    • Initials: @yoavaviram, I was wondering if there's a small token that we want to save along with the request. This field could be, for example, the initials extracted from the user's full name. The goal would be to keep this minimally identifying information in perpituity in our database, even after the other data was removed. For me, this field would likely be "H S". If we want to ensure all fields, including fields derived from names, are removed, we can drop this field. What do you think?

honzie avatar Mar 30 '21 16:03 honzie

Having some more time to think about this, lets also add: Use case 1:

  • Email of the organization (it's sometime on a different domain then the one we have in the DB for the org, and it can change)

Use case 2:

  • All email addresses in the 'To' field of the email.
  • Request text (this is useful to include in the escalation email)

As for your initials, what would be the point? If it serves a purpose we could even keep the user's name as on it's own it's not really a unique identifier.

yoavaviram avatar Apr 01 '21 19:04 yoavaviram

I like these additions. Especially the full request text.

For initials, the point would be to have a semi-anonymous way to refer to a requestor. Given that we have a fully anonymous way of referring to each request (the UUID), I don't think this is a necessity.

honzie avatar Apr 02 '21 16:04 honzie