Gittip Fraud HOWTO

[pjf]

Gittip involves moving money between people, and as such it's also a potential vehicle for fraud and money laundering. A typical workflow may be as follows:

• EvilPerson steals credit card details and attaches them to a gittip account.
• EvilPerson pays money to other Gittip accounts under their control.
• EvilPerson withdraws money from those other accounts, possibly via BitCoin, which—like its legally dubious cousin "cash"—is used by drug-lords, arms-dealers, and Portland street-food vendors.

Where this sucks for GitTip is when the fraud is discovered and the fraudulent credit-card pay-ins are reversed, leaving GitTip with the bill for the fraudulent pay-outs.

It would be useful to have a discussion as to how to combat this. New accounts giving lots of money to other new accounts are a potential sign of fraud, but an attacker may choose a less obvious (and less efficient) route to try and avoid detection.

One possible solution would be to have the concept of "cleared funds" and "uncleared funds". Pay-ins that can't be reverted (eg: Bitcoin) are automatically cleared. Those which can be reverted as 'uncleared' for a period of time, to at least increase the likelihood of us receiving fraud alerts before we pay-out of those funds. Another solution would be some sort of fraud insurance.

Other suggestions and discussions very welcome here. Understanding potential attack patterns can help us defend against them when they arrive.

~ pjf

[chadwhitacre]

@pjf Yes! Fraud is a thing on Gittip. We had our first experience with fraud while we were quite young, in September, 2012. This resulted in a fairly extensive write-up a couple months later. That's the place to dive in on understanding Gittip's relationship with fraud. Since then our process has been to manually review, as part of payday, all accounts that have attached a bank account or credit card in the past week.

I believe this ticket was motivated by a suspicious request for a bitcoin payout from khanhnguyenlt00 (yes?). The patron who gave to khanhnguyen00 is believe272, and I failed to flag that during manual review, probably because they had multiple accounts attached. Sorry. Thanks for catching it on the payout! :-)

What additional actions items do we need on this ticket?

[chadwhitacre]

P.S. I've taken the following steps:

• marked khanhnguyenlt00 and believe272 as suspicious
• refunded the money back to the credit card that believe272 used

[chadwhitacre]

I've responded to khanhnguyenlt00's email to support:

Khanh,

Thanks for getting in touch! Unfortunately, we've decided to consider your use of Gittip to be suspicious, and we've refunded the money that was given to you back to the original credit card that it came from. :-(

Let us know if you'd like to dispute our decision.

chad

[pjf]

I think we also need to talk about our procedures for discussing fraud investigations in a public forum. Most notably:

• If someone is innocent of fraud, then we've just publicly cast suspicion on them, which is uncool.
• If someone is guilty of fraud, then we've given them advance notice that we're on to them, and also who's involved with that investigation. This also doesn't seem wise.
• In any case, I believe that Gittip users have an expectation of privacy when contacting support, and this violates that expectation of privacy.

Consequently, I can neither confirm, deny, or comment upon anything posted in this ticket beyond the original issue that I raised.

~ pjf

[chadwhitacre]

I think we also need to talk about our procedures for discussing fraud investigations in a public forum.

@pjf Fair enough. As you can see from the "Delpan Incident" report, our long-standing pattern has been to deal with fraud publicly. Gittip is predicated on openness and transparency, so we're actually touching on a core issue here: Gittip shares information by default. Why should we hide information in this case?

If someone is innocent of fraud, then we've just publicly cast suspicion on them, which is uncool.

Why is that uncool? If they're innocent, then we apologize. This isn't theoretical: see Gittip 85 for an example. We interacted with two folks on that ticket and on Twitter, and we decided to back off.

If someone is guilty of fraud, then we've given them advance notice that we're on to them, [...]. This also doesn't seem wise.

Why is this unwise? If someone knows we're onto them, then what? They "escape"? What does that even mean in our case? Think of the difficulty of catching someone who uses Gittip to charge $100 to a stolen credit card. It's not like we're tipping off a big-time mobster that the cops are going to raid them in a few hours.

[...] and also who's involved with that investigation [...]

I do admit that I have a feeling of personal risk, like, "What if khanhnguyenlt00 decides to come after me, personally?" My belief is that this feeling of mine indicates a deep sickness in society, which Gittip is in fact aimed at addressing. More trust! More openness! More light! More love! I don't believe in secrecy and fear, if I can help it. I accept that you (@pjf) and others working on Gittip support may not wholly share my view, in which case I'm happy to keep you out of public fraud discussions like this in the future. :-)

The problem with the traditional, secretive approach to anti-fraud is that innocent people get squished—you end up with PayPal freezing your account and then stonewalling to you. Totally gross. There's a theoretical possibility with our open approach to fraud that an innocent user will end up lynched by a mob—the dark side of the crowd. We have not yet seen this risk materialize in our practical experience, and we're (I'm) on the lookout for it.

In any case, I believe that Gittip users have an expectation of privacy when contacting support, and this violates that expectation of privacy.

I've been cross-posting support requests to public GitHub issues for almost two years, and I have only a vague feeling that a user once expressed concern, maybe.

Perhaps we could set expectations by publishing a policy on what information coming into [email protected] we will share by default. This should go on the website and also in the automatic email replies to send to incoming support requests.

[bruceadams]

Interesting call out of #1913. The two users I blocked for that payday and we later cleared, shortly after that payday, have not been active since. What happened to the giver's credit card? I don't think we disconnected it. Am I wrong? Did we disconnect their credit card?

[pjf]

I'm going to focus on what I feel are core issues here. For me, those revolve around expectations of privacy, and consent.

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.

In the case of fraud, I'm not sure there's much to be gained by mentioning exact users in public. If they're guilty of fraud, then we're unliekly to see them again, but if they're not guilty of fraud, what's the chances that they're going to continue to use gittip? What's the chances they'll recommend it to their colleagues and friends? What's the chances that their reputation has been damaged, or they feel it's been damaged?

I'm very much in favour of open processes, open development, and open governance. But when it comes to individual users, I'm hugely in support of them being the ones to decide how their data is used. And right now, when it comes to support, we're not doing that.

~ pjf

[ncoghlan]

On the "expectation of privacy" front, the other thing to consider is that the issue tracker is already open for anyone to post concerns/questions. That suggests that other contact channels exist for other reasons, such as to provide a less public way to report a problem or ask a question.

[sigmavirus24]

I agree with @ncoghlan and @pjf. While I'm not a heavy user of Gittip or a frequent contacter of Gittip, I would expect that at the least there would be a disclaimer on the website or explicit permission asked during the conversation. I would guess most users would be okay with it. The other situation I can imagine is the case where someone is working under a pseudonym because their company prevents them from doing X and receiving monetary compensation for it.

That aside, hasn't it always been the case that @whit537 posts the list of accounts marked as suspicious during a payout run? In that case, a change to how fraud is handled would be significant. Innocent users may feel persecuted or trapped for exhibiting behaviour they did not realize would be considered suspicious. Likewise, it could give someone intending to commit fraud an idea of how fraud detection works which could potentially work against Gittip in the future. On the other hand, as a user of Gittip, I like the openness of the community and leadership. Especially if someone used my account to test out a credit card which was then charged back, I'd like to know. As an innocent victim (like Gittip) I would love to have the opportunity to support Gittip and reimburse it for any money it is out because I was randomly chosen to test a stolen credit card.

[greggles]

I support @whit537's perspective here. Gittip is open by default. Maybe that should be part of the signup flow so that people know their support request might end up in the open. I actually think that should reduce the chances of fraud and misbehavior on the part of users.

The only place I can see a problem with being open about Fraud is that it's essentially an arms race. Fraudsters do something shady. You notice it once (by accident?) and create procedures and code around preventing it. Eventually they learn you are preventing it so they try to find ways around that prevention. And the process repeats. Handling it in the open means that a tenacious fraudster will learn quickly what process/code is in place to prevent them and they will be able to adapt faster. Then gittip has to adapt quickly too. One benefit of accelerating this arms race is that if gittip becomes more fraud resistant than other sites then the fraudsters will move there.

I think any benefit the fraudsters will get from the discussions being in the open is outweighed by the broad benefits of being an open company. It will require you to be a little more vigilant in theory. That seems OK.

[sreynen]

"Gittip is predicated on openness and transparency." I really like this approach. And I would like it even more if it were more transparently shared with users where they would reasonably expect to see it, i.e. in the privacy policy.

I don't think I'd read the privacy policy previously, and reading it now, I was surprised by what it says. I've read a good deal about the philosophy behind Gittip, so I wouldn't be surprised to find my info shared more openly than it might be on other sites. But for users who have less background, I think it's reasonable for them to get their ideas about how private their info is from the privacy policy. The current privacy policy does not suggest openness is the default, and actually says almost the opposite: "Gittip takes measures to help protect your personal information in an effort to prevent [..] unauthorized access." I suggest updating this to reflect whatever decisions are made here so users can make informed decisions about what they want to share with the site.

[chadwhitacre]

What happened to the giver's credit card? I don't think we disconnected it. Am I wrong? Did we disconnect their credit card?

@bruceadams We did not disconnect their credit card. We've been charging it since they first arrived, but to no avail, as it has failed every time.

[chadwhitacre]

When I contact any organisation for support, I have an expectation to some level of privacy

Reticketed as #2180. Let's keep this ticket focused specifically on how we deal with fraud.

[chadwhitacre]

Derp. Looks like I already reticketed #2131. I'm going to close that in favor of this since there's more attention here.

[chadwhitacre]

Dropped to ★★☆ because it's not urgent.

[chadwhitacre]

Edge case: https://www.gittip.com/huanxuefeng/ (from #2190).

[bruceadams]

Ah! So, a failed credit card charge shows as no credit card attached on a Gittip user's profile page.

[patcon]

Interesting: http://www.newrepublic.com/article/117608/chinese-number-websites-secret-meaning-urls

I've previously read numeric usernames or emails with suspicion, but it's just because chinese speakers are more comfortable with numeric characters than latin ones.

[chadwhitacre]

Finally circling back around to this one after an eventful couple of years. Gittip is now Gratipay, and Gratipay now has a well-established policy for managing the private/public boundary in user support:

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.

That was actually a sidebar in this ticket. The main point here was how to combat fraud, for which we've also adopted policies by now.