decred / decrediton

Cross-platform GUI for Decred.
https://docs.decred.org/wallets/decrediton/decrediton-setup/
ISC License
195 stars 120 forks source link

Implement support log upload #1433

Open matheusd opened 6 years ago

matheusd commented 6 years ago

Right off the bat: this will be tricky, as we need to balance several different competing desires.

The rationale for having this is faster support turnaround time: instead of requesting that users search for and upload their latest logs looking for errors, we could automate this process by having them upload their logs into some service, then look for errors ourselves. The tricky thing is doing this in a safe manner, so as to not break user privacy and security concerns.

Items to look out for:

To decide:

My personal concern:

If data is stored in plaintext (even if anonymized) then anyone with access to this service/channel can see it. This might or might not be acceptable to our users.

One alternative to this would be to encrypt data on the user's end (with a symmetric key) and then users can share that key with whoever they are trusting their support request to (which wouldn't even necessarily need to be someone from the existing/usual support pool). Obviously, once this key is shared the other person can copy and send data to anyone, but IMO this is a step up from just having data open.

jrick commented 6 years ago

dcrwallet logs don't have any particular structured form (besides the timestamp, level, etc.) and the messages can change between releases, so I don't think sanitizing that automatically is feasible.

xaur commented 6 years ago

At least detecting addr and tx patterns is possible. But still this is super controversial and I expect getting some beating for it, although it's great from user perspective.

One practice I recommend (for all things uploading any user data) is showing the user exactly the data that will be sent.