Orphaned Gittip accounts

[bruceadams]

was: "Orphaned Gittip accounts"

What, if anything, do we want to do with orphaned Gittip accounts?

Some examples:
https://www.gittip.com/kodbaz/ has a suspended Twitter account.
GitHub disavows any knowledge of https://www.gittip.com/ashah09/.

I see two issues with inaction here. One is accumulated noise pages within Gittip. The other is what happens if a different person claims the elsewhere account name at a later date? Gittip could have old, inappropriate information for the user.

I think we should, at least, mark orphaned accounts as suspicious and maybe deactivate them more completely.

[bruceadams]

@rbebic hit this in an interesting way.

I just deleted my github account to create new one with same username. Now when i logged in to gittip it created new account. Is it posible to delete my old account gittip.com/rbebic so i can reuse the username?

Going straight to https://www.gittip.com/rbebic appears to be connected to @rbebic on GitHub. Yet, going to https://www.gittip.com/on/github/rbebic/ gets a 500 Internal Server Error. It appears that Gittip is confused.

[xetch]

+1 - I'm also experiencing this problem.

[galuszkak]

+1 .
I've notice also other problem. Sometimes images from API are changing there location and therefore we get 404 on this img.
example:
https://www.gittip.com/julython/
but on Twitter everything is fine.
https://twitter.com/julython

Seems like a bug to me :)

[bruceadams]

@syst3ml00t helped me see the connection between this issue and #639. Thanks @syst3ml00t !

[chadwhitacre]

@galuszkak Can you reticket the img issue if not already done? Thanks! :-)

[chadwhitacre]

Re: noise pages: yes.

Re: inappropriate user info, that should only be a concern for Bitbucket, where we don't have an immutable user id. For Twitter, GitHub, and Venmo, we have an immutable user id, so someone reusing a username on Twitter would not end up taking over the old account on Gittip (if I'm understanding your concern correctly).

A suspended or missing account elsewhere is a negative trust signal. With our current binary trust metric I don't think it's necessary to mark either https://www.gittip.com/kodbaz/ or https://www.gittip.com/ashah09/ as suspicious (neither has a CC or bank account attached anyway). I think it would be enough to simply deactivate those accounts using our usual procedure (#54 (comment)).

The other side of the problem stems from the fact that we require an account elsewhere in order to login to Gittip. With their account elsewhere suspended, neither kodbaz nor ashah09 can login to their Gittip account now. Neither is active or has a balance, but if they did they would be in a pickle right now. Again, a deleted or suspended account elsewhere is a negative trust signal (we may want to prevent them from logging into Gittip), but it doesn't seem right to enforce that a priori. Having password authentication for Gittip would make this a non-issue (#1052).

What I'm hearing with @rbebic's case is that they don't have access to https://www.gittip.com/rbebic/, because it's associated with a now-deleted GitHub account that happens to have had the rbebic username as well. This is expected behavior per the above (we associate with GitHub via an immutable user id, not the username). In this case, because gittip.com/rbebic has no activity, I'd be comfortable deactivating gittip.com/rbebic, so that @rbebic can create a new Gittip account using his new GitHub user. However, https://www.gittip.com/on/github/rbebic/ will continue to 500 because it's finding two possible resolutions. But that's a separate issue.

[zbynekwinkler]

However, https://www.gittip.com/on/github/rbebic/ will continue to 500 because it's finding two possible resolutions. But that's a separate issue.

#1395

[bruceadams]

Looks like a +1 from Louise Flory via [email protected]. It appears that Louise has orphaned their Gittip account with a credit card attached and outgoing tips setup. This, of course, is very bad. They cannot cancel those tips.

[bruceadams]

Bumping this to three stars. This is a borderline emergency. We are charging credit card for people who cannot authenticate to stop those charges.

I'm going to work on writing a script to scan existing Gittip accounts with credit cards attached and check if their "elsewhere" accounts, especially on Bitbucket (due to the support case), still exist.

[bruceadams]

This is related to #823

[bruceadams]

I did find the relevant Gittip user, https://www.gittip.com/lflory/. They have outgoing tips setup (despite the profile page saying "LFLORY IS QUIETLY WATCHING THE GITTIP WORLD") and a good credit card attached to the account. We last charged this user's credit card on December 26th. We definitely owe them a refund for that charge, and quite possibly for the previous charge on October 17th.

I am leaving the account active for a few days to retain the credit card tie so we are able to issue a refund.

[bruceadams]

We've initiated a refund of the most recent (December 26) Gittip charge to lflory. I still intend to deactivate the account. I was very surprised that @whit537 suggested (in comments on the support ticket) that we not deactivate the account.

What does a Gittip user mean when no one can authenticate as that user?

Even worse is the Bitbucket case, where our OAuth tie to Bitbucket is based on the Bitbucket user name. If a user, such as lflory, deletes their Bitbucket account, some new person can create a Bitbucket account with the same name and authenticate to Gittip as that other user. This is not a theoretical risk. I just did this for lflory. 💥 I have successfully authenticated to Gittip as lflory, someone with an active credit card on Gittip. ⁉️ (OK, I've removed the credit card link before publishing this comment. I've also zeroed outgoing tips.) I did not even have to confirm my email address with Bitbucket. (I hadn't even noticed that Bitbucket had asked for that confirmation until after I had gotten into Gittip.)

[galuszkak]

@bruceadams this seems like a very serious issues if you manage to do that.

[zbynekwinkler]

@bruceadams I definitely agree that this is serious brokenness (I mean design time brokenness). If that is all Bitbucket API can give us I think the only valid solution is to drop support for Bitbucket sign in (if not all of Bitbucket support).

Maybe another +1 for #1052? I still think that authenticating to a 'bank account' using your social accounts is not a good idea.

[chadwhitacre]

I think the only valid solution is to drop support for Bitbucket sign in

Agreed. Reticketed as #1945.

Maybe another +1 for #1052? I still think that authenticating to a 'bank account' using your social accounts is not a good idea.

Yes, though I think we should give people an option for a few of the bigger networks: Google, Facebook, maybe Twitter.

[bruceadams]

+1 for deleting orphaned accounts from @devavratravetkar via [email protected]

[bruceadams]

The https://www.gittip.com/rbebic problem, which I was tracking (and mostly ignoring) as a ticket in SupportBee, appears to have been lost in the transition from SupportBee to FreshDesk.

Just now, I went ahead and deactivated rbebic, but I'm pretty sure that person still cannot create a new account on Gittip using a newly recreated GitHub account named rbebic. (It is clear that this person has tried to do exactly this several times over the past few months.) That is: https://www.gittip.com/on/github/rbebic/ continues to give a 500 error.

[bruceadams]

It seems like we need to disconnect deactivated accounts from any elsewhere links.

As with everything related to deactivation, I'm really uncomfortable with these kinds of updates. I hate destroying historical information.

[bruceadams]

I went ahead and did it for this specific case

delete from elsewhere where user_name='rbebic';

Now the 500 errors are gone. And, now, I get to figure out how to initiate a support ticket in FreshDesk.

[bruceadams]

And... this broke the homepage query: https://app.getsentry.com/gittip/gittip/group/16268371/

[bruceadams]

Attempted to patch things back together:

insert into elsewhere (platform, user_id, participant, is_locked, user_name, is_team) values ('bitbucket','rbebic','deactivated-rbebic','f','rbebic','f');
insert into elsewhere (platform, user_id, participant, is_locked, user_name, is_team) values ('bitbucket','renato','deactivated-renato','f','renato','f');

Off the wall question: is there a way to get interactive psql to not do the paging? It's not the paging the really irritates me, it clearing the results off the screen that really drives me nuts.

[chadwhitacre]

"\pset pager without a value toggles pager use on and off."

http://www.postgresql.org/docs/current/static/app-psql.html

[chadwhitacre]

I'm looking into this in connection with account cancelation (#54). Part of cancelation will be archiving the participant record, which we already do during take_over. Turns out that we don't touch claimed_time during archiving in take_over, so there we can end up with an orphaned participant: still technically claimed, but not able to be accessed, because it has no accounts elsewhere linked.

[chadwhitacre]

So how does that relate to the cases here and what are the action items?

[chadwhitacre]

Alright, catching up on this thread. It sounds like this ticket is about the case where an account elsewhere is suspended or canceled, and we don't notice, and that this is a real security hole wrt Bitbucket. :-(

I am hearing that kodbaz and ashah09 are examples, but are not users who have specifically requested from us. Yes?

rbebcic seems to be taken care of, yes?

Re: lflory. Am I right that https://bitbucket.org/lflory is actually you, now, @bruceadams? O.O We have refunded them, yes? They still have a 4.55 balance. Was that included in their refund and we just need to record that on their history page? Or do we need to do another refund/distribution? I agree that we should deactivate their account.

@syst3ml00t What's your status? Are you still stuck wrt this ticket?

What's @devavratravetkar's status? Any action item there?

[chadwhitacre]

Once those users are squared, what's the remaining action item? Do we get an oauth invalidation during cancelation/suspension on a platform elsewhere? If so then #823 would fix this, yes? Otherwise what's our option? Periodically crawl? Once we drop Bitbucket (#1945) then this is just about noise and annoyance, yes? Once we land #1052 then this goes away, right? Well, to be replaced by users forgetting their password and their security questions, etc.

[chadwhitacre]

I've downgraded this to ★★☆ and have added "Security" to #1945.

[chadwhitacre]

I've reticketed the issue w/ claimed_time that I'm seeing as #2472.

[Changaco]

Closing in favor of #900.