[meta] Users taking control of their data. - Automatic Party Aquisition

See #1679722: email confirmation when linking users to parties, where there is a patch needing review and a proposal to add a dependency on a contrib module.

What I wrote there:

Anytime we connect a user to a party, we have to be certain that the user is the right person to connect.

Because otherwise, if permissions are set up to allow users to read or edit their own party's data, we are potentially granting access to data to the wrong person.

In particular, we have to prevent the user from changing their account email without confirming it (which AFAIK users can do in Drupal core).

And to summarize: we have to be certain that the person's whose data we have is the same person as the owner of the email address.

The other way in which this can go wrong is this scenario:

1. Alice writes down her email address, eg on a sign-up form
2. Bob enters the data, creating a party for Alice
3. At either of these stages, one of them makes a mistake. It so happens that the typos in Alice's email address turn it into Oscar's.
4. Oscar is now able to create an account on the site and claim Alice's data.

AFAICT there is no way to guard against this.

Thinking about this more, this is a problem that any website has if it has a workflow that involves Bob entering Alice's email. The paper part is superfluous -- if Alice is speaking to Bob on the phone it can go wrong too.

We could split up Bob's step:

2A. Bob creates a new *STUB* party, containing only Alice's email address.
2B. Alice receives an email asking her to confirm her address.
2C. When Bob sees Alice has reponded, he continues entering data.

But in 2B, this could still be Oscar!

The problem is that unlike in a system like Drupal's user module account creation, the step of account (here, party, but same thing) creation and email confirmation, the two actions are split across two different people.

We could send a sum up of the information to the email address and say 'Is this you?'

> We could send a sum up of the information to the email address and say 'Is this you?'

But then if it's Oscar's email address, Oscar can just lie and say 'Yes, it's me!'.

I think all we can do is:

- make site builders and admin users aware of the problem
- force double-entry of email addresses (and use JS to block paste. I've seen it done on site, it's annoying as hell, but there's a good reason for it)
- encourage site builders to use a pattern where users initially create their own accounts/parties

Yeah, I've been thinking about it as well and I can't think of a way to do it 'automatically' without there being risk involved. The only 'risk free' method I can think of is manually merging, in which the person doing the merging is essentially validating that the two are the same.

The only thing I can think of is introducing some additional security questions or validating additional data (such as an address and an email address), but even those are no guarentee.

I think the best that we are going to get is to do email matching, making sure that we only attach parties to user accounts with verified email addresses (so we only ever do it on account creation), or, as Joachim suggested, trying to make it so that people register their own accounts as much as possible, maybe to the extent that we don't automatically give access to anything.

http://drupal.org/project/email_confirm provides the ability to make sure user account emails don't get changed scrupulously, which I suppose may mean we can make it so that automatic matching doesn't only happen at account creation...

Thinking more about it, I think there are two fundamental issues...

a) Verifying that an account and a party are the same.
This one we can go some way to solve, but in many ways is the less important one...

b) Verifying that a party is actually the right person before attaching sensitive information.
This one I'm not sure we can solve. An example would be I meet someone face to face and record some information about them. Someone registers through the web with the same information. We don't actually know that the two are the same. Even without malicious intent, we could find situations where we get that crop up just by things like two people having the same name etc. This is a generic data protection issue.

In several of our use cases, we have this cropping up. We are still developing a plan of attack, and are unsure of whether to use an email confirmation to claim accounts or deduplicate on account creation. Either way, email seems to be the best option for us so far. Email_confirm seems like it could work quite well!

I'd say email_confirm is essential.

I would suggest that if there is already personal information being stored and you are possibly giving outside users access to that information, then there needs to be at least some minimal level of additional security. With some companies, you may need to verify an account number, but that may not be appropriate in all situations. It could be simpler, like my Internet provider does whenever I can't remember the bizarre userid they assigned me. They just do a quick challenge where I have to select from a series of choices which information from my account, in this case my address, is correct. It takes two seconds is very non-intrusive. This is not exactly high security, but I still need to know my password in this case; however the technique could probably be modified to more securely enable linking new accounts to Parties.

Added Log for names

Oh hey, verifying with an account number is a great idea, that just solved an issue on one of our projects!

Potentially we could provide a simple module with party_user that allows you to identify a confirmation and/or deduplication field for all party_users, that is attached to the user dataset (i.e. profile fields). This way, one could choose usernmame, email, or a numerical ID, etc.

We've been focusing on Scenario 3B today.

With regard to the acquisition we had to make a decision on whether to join a new user to a party upon the user being first saved or when the email is confirmed. We decided to do it in hook_user_insert for the following reasons.

If the user who is registering deliberately puts in a fake email, we join that user to a party, then the user doesn't have access to the information until he can confirm his email address anyway.

> then the user doesn't have access to the information until he can confirm his email address anyway.

Could you review my patch on the other issue please?

Introduce a current real work scenario 3b.