Privacy risk: Storing personal details like birth date in user preferences

[redsolver]

There's a recent commit (44b721b) which added a new personalDetailsPref type to user preferences which includes birth date.

Unfortunately this poses a big privacy risk, because

• any third-party app can read it
• all preferences are stored in one big JSON blob, so it's impossible to detect which part of the preferences third-party apps are reading. they can only request everything or nothing

A good solution might be to use a key-value API instead, which only allows reading/writing one preference type at once. Sensitive preference types like personal details could then be blocked for third-party apps.

[redsolver]

Not sure if the "bug" label is appropriate, but looking at the available issue templates it made more sense than "feature request"

[dholms]

Hey thanks for the report!

App passwords are meant to provide essentially full access to an account - except for the ability to create new app passwords and delete the account.

Really this issue is solved by introducing a better authorization scheme (such as OAuth) which we do have plans for.

However, I can see how this preference could be particularly intent-violating. So I've added some logic to the getPrefences route to specifically filter out personalDetailsPref