Phone number storage requirements

[scy]

As per the data protection document:

• Have an application-wide secret that will be used to pepper hashed phone numbers and encrypt those that can’t be hashed.
• In addition to being able to store a hashed phone number, make it possible to also store unhashed parts of it for debugging purposes:
  • the country prefix
  • a configurable number of digits of the number (not counting the country prefix), either “n digits from the left” or “all but n digits from the left”

[scy]

Just for completeness, the “data protection document” mentioned above is https://github.com/AKVorrat/dearmep/blob/main/doc/data-protection.md; it talks in detail about what to do and why. But it’s also a few months old by now and there might be some details that haven’t made their way into it yet. If anything seems odd or unclear, please don’t hesitate to ask.

[jbethune]

This issue depends on #122 which provides the application-wide secret as config.authentication.secret.pepper

make it possible to also store unhashed parts of it for debugging purposes

How do you envision the debugging process? What kind of circumstances would require us to take a closer look at the numbers and how would we enable and disable debug phone number storage?

I'm also considering if this information should be printed with Python's logging module. That way the information will be deleted automatically and eventually. Cleaning up the database would be an active effort.

[jbethune]

@scy How do you envision the debugging to look like with this feature? How should that debugging mode be turned on and off?

[scy]

How do you envision the debugging process? What kind of circumstances would require us to take a closer look at the numbers and how would we enable and disable debug phone number storage?

In the initial design, we wanted to be able to always keep the country code and a configurable prefix length available un-hashed, do be able to run statistics on it (“how many people from Spain had technical problems”). I don’t really remember where the “debugging” wording comes from.

We (okay, I) have decided to not track the prefix for now, simply because it doesn’t offer a lot of helpful information. Taking German mobile phone numbers as an example, the idea was that maybe we could track whether T-Mobile customers would have more technical problems than Vodafone, but the prefix doesn’t say too much about this due to MNP. Also, the required prefix length would be different per country, and it’s all a can of worms for little benefit. So let’s skip this prefix thing for now. We do keep the country code though.

This information is kept always, not on a case-by-case basis. We do want to be able to completely de-anonymize numbers in abuse cases, but that’s a separate issue (#169). I think this one here can be closed since most of it has been implemented in #154.

I'm also considering if this information should be printed with Python's logging module. That way the information will be deleted automatically and eventually. Cleaning up the database would be an active effort.

Yes, but I’d say deleting stuff from the database is a normal thing to do, while deleting single lines from logs isn’t. Deleting personal information from logs is much harder than from a database. And if somebody comes along and writes you an email like “hey, I’m entitled by right to have all my data deleted from your system”, answering “no problems, the logs will delete automatically and eventually” doesn’t really help.