Skip to content
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.

hash out policy for user support privacy #2180

Closed
chadwhitacre opened this issue Mar 24, 2014 · 15 comments
Closed

hash out policy for user support privacy #2180

chadwhitacre opened this issue Mar 24, 2014 · 15 comments

Comments

@chadwhitacre
Copy link
Contributor

Reticketing from #2125, which is specifically about how we handle fraud, but where @pjf makes the following case:

When I contact any organisation for support, I have an expectation to some level of privacy regarding our discussions. I expect they'll be used internally, discussed, used to make reports, and whatever else. However I don't expect to see my support requests posted publicly without at least asking me first.

There are many reasons why I might not want my details posted publicly. Maybe I'm in a country that outlaws bitcoin, and I'm asking for a bitcoin payout. Maybe I'm an activist, or a pornstar, or someone else who wants to keep control over which of my communications are released to the public. Maybe it's because I expect that Gittip understands there's an expectation of privacy, and I'm surprised when that's violated.

Why would Gittip provide an expectation of privacy? Because there are privacy controls in the UI! I can hide how much I'm giving, and how much I'm receiving, but if I'm then shown to be making a pay-in or pay-out, then one can simply deduce if I'm funding or being funded from that. Plus most organisations do not release details of their support tickets for all to see. Is that something that's in our privacy policy? If so, we definitely should be highlighting it. If not, then it should be, or we should procedures accordingly.

None of this is an issue if we get user consent. Just a quick "hey, can I mention details of this in a github ticket" is polite, and I imagine most users would say yes. Likewise, referencing support tickets by number is fine, because we're not naming people. Heck, some people just don't like attention; naming them is just being mean.

@chadwhitacre
Copy link
Contributor Author

None of this is an issue if we get user consent. Just a quick "hey, can I mention details of this in a github ticket" is polite, and I imagine most users would say yes. Likewise, referencing support tickets by number is fine, because we're not naming people. Heck, some people just don't like attention; naming them is just being mean.

👍

I'm fine with asking permission before posting specific details back to public fora, i.e., GitHub issues. I think our process should be:

  1. Add an anonymized +1 to whatever ticket.
  2. Notify the user about the anonymized +1 (I like that we're proactive about adding +1s for people instead of requiring them to take that step themselves)
  3. ... and ask for permission to post specific details of their case (if we decide that that adds value to the ticket).

How does that sound, @pjf, et al.?

@chadwhitacre
Copy link
Contributor Author

Maybe language like:

Since we manage our development priorities in public using GitHub, I've added an anonymous +1 for you to [whatever ticket] so that your voice is heard. Would you like me to post your specific comments over there as well?

@chadwhitacre
Copy link
Contributor Author

The deliverable for this ticket is twofold:

  • an update to Run Support
  • an update to ... our privacy policy?

@pjf
Copy link
Contributor

pjf commented Mar 25, 2014

I have less problems with the +1's on tickets (although I strongly agree that '+1 from FreshDesk %d' is a great thing here!), and much more when we have things like "Leslie Hacker is having trouble with X".

When a public medium is used (eg: twitter), I don't see any issues with public +1s.

@chadwhitacre
Copy link
Contributor Author

Cool. So we're on the same page then?

@pjf
Copy link
Contributor

pjf commented Mar 25, 2014

And an update to the privacy policy sounds great; not least because it's not quite human friendly right now. :) (I'm also really fond of tumblr's policy of linking to diffs on github for privacy and terms of usage changes.)

@pjf
Copy link
Contributor

pjf commented Mar 25, 2014

Cool. So we're on the same page then?

I think so. :)

On the matter of the privacy policy, the current stylesheet means that h3 headings don't look any different the regular text. The they've been reset by reset.css, but no actual style has been applied. They could be at least a little bold, and a little larger. :)

  • Update stylesheets so h3 have style.

@pjf
Copy link
Contributor

pjf commented Mar 25, 2014

Or, using existing styles, we can flip the privacy policy to using h1s and h2s. Imma going do that now.

pjf added a commit to pjf/www.gittip.com that referenced this issue Mar 25, 2014
As discussed in GH gratipay#2180.
No content changes.
@chadwhitacre
Copy link
Contributor Author

!m @pjf

@patcon
Copy link
Contributor

patcon commented Mar 28, 2014

Am I doing this right? #698 (comment)


fwiw, this is likely something that was can integrate later...
https://support.freshdesk.com/support/solutions/45931

cc: @bruceadams

@patcon
Copy link
Contributor

patcon commented Apr 11, 2014

At risk of being a step backward, might I suggest this:

  • edit auto-reply to very clearly state that the presumption is that the information discussed in support emails can be made public at Gittip staff discretion UNLESS they reply to the auto responder saying otherwise.
  • we add a custom field to freshdesk, defaulting to consent of openness. If we hear back otherwise, we set the privacy flag.
  • those who feel strongly will indicate so, and we will have that in one solid and predictable place per ticket.

Good idea? Bad idea?

@chadwhitacre
Copy link
Contributor Author

@patcon +1

@bruceadams
Copy link
Contributor

This is pretty bold, but I do like it. I'd like to get several people's review on our outgoing text that "very clearly state"s anything. We have often confused people in several areas.

@patcon
Copy link
Contributor

patcon commented Apr 15, 2014

OK, cool. I'd love to hear back from you @pjf, before I move foward with that, as I know you have strong feelings (as a user privacy advocate of a very appreciated sort :)

Also, we could add something to the "footer" canned message, which I've personally been adding to the bottom of every message, below my signature. For example:

User has given consent to openness of ticket contents, at discretion of Gittip staff? True

For more information, please see Gittip's privacy policy.

@chadwhitacre
Copy link
Contributor Author

Circling back after a couple years ... looks like we ended up not going with the bold opt-out approach, but rather with an opt-in approach:

Protecting User Privacy

  1. Before answering questions or performing actions related to an account, verify the user's identity by asking for, "the first eight digits of the API key on your Gratipay settings page." We generally don't trust even verified email addresses as identity confirmation (because of the risk of spoofing).
  2. Never share personally identifying information about a user on GitHub or anywhere else without their explicit consent.
  3. Copying anonymized, generic comments into a public GitHub ticket is okay, and so is a simple "+1" with a link to Freshdesk.

http://inside.gratipay.com/howto/support-users

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants