force authentication for informed consent process

[ben-jones]

force the user to register, then do informed consent so we can enforce authentication and prevent someone from doing the informed consent on the user's behalf

[phillipa]

I’m not sure exactly what is meant by this.

The informed consent process (as approved by the IRB) is that each install of the software comes with a unique “tag”/code value that is difficult to guess but not so ugly a person cannot type it in (e.g., 5-10 alphanumeric characters). The person types in the tag at the end of the consent process instead of their name. The tag identifying the installation can then be mapped to the consent that was obtained.

Some users may not want to register if they are concerned about privacy. Registering would be an optional step for people who want to administer their own Pi via a Web UI requiring log in (e.g., view what is run on their Pi, run custom experiments of their own on it).

(Pi and Install of the software can be interchangeable in the above paragraph). We had the idea that when we ship the Pi the “tag” would be included with the device. For people who might just install via pip onto an arbitrary computer we will need to do something different.

On Sep 24, 2014, at 10:22 PM, Ben Jones notifications@github.com wrote:

force the user to register, then do informed consent so we can enforce authentication and prevent someone from doing the informed consent on the user's behalf

— Reply to this email directly or view it on GitHub.

[ben-jones]

@phillipa, I am happy to change this, but the comment about authentication is tied to how we are currently setting up usernames and passwords. In the rest of this comment, I discuss what we are currently doing and how we could potentially modify this process to do more of what you want.

Current Approach

Right now, we generate a 64 character username and a 64 character password for each user. When the user registers, we create a file with their login credentials and send the username and password to the server. This is all done without any user interaction and when I say registration, I mean the process by which the Centinel client registers these credentials with the Centinel server.

In the model I had for informed consent, we would have centinel register a user, but prevent them from doing anything, the first time they start centinel. Whenever the user tries to run centinel, we would print a message on the console saying that the user needs to visit http://centinel.noise.gatech.edu:8080/get_initial_consent?username=username-var, where username-var is the user's username (Note that this is a live demo of what we have for informed consent so far). From here, we follow the informed consent process through and auto-populate the username where necessary. In the backend, we have a field that stores if the user has completed the informed consent process. If the user has not done the informed consent, then we will not give them any experiments or let them upload any results. At then end of the described informed consent process, the user sends an authenticated request that sets the informed consent field to True.

Potential modifications

To make our informed consent/registration process more inline with what Phillipa suggested, we could make some or all of the following changes:

1. we could register each PI before deploying, then let the user do the informed consent in the field. Each user would still be registered, but they would not have any interaction with the server until after they did the informed consent piece
2. we could make the username/ identifier shorter and more human readable
3. potentially we could do a completely separate process for the pip package and our deployment, though this seems unnecessary.

@phillipa, would any or all of these modifications address your concerns? Also, are there other changes we should be aware of for informed consent? We just wrote up what you sent us in pdf form.

[phillipa]

Ah ok that makes sense. I forgot this ‘user registration’ was a notion internal to us. Probably easiest thing to do is use the 64 character username as the ‘tag’. Maybe there is a way to make it easier than typing 64 chars though?

On Sep 25, 2014, at 8:13 AM, Ben Jones notifications@github.com wrote:

@phillipa, I am happy to change this, but the comment about authentication is tied to how we are currently setting up usernames and passwords. In the rest of this comment, I discuss what we are currently doing and how we could potentially modify this process to do more of what you want.

Current Approach

Right now, we generate a 64 character username and a 64 character password for each user. When the user registers, we create a file with their login credentials and send the username and password to the server. This is all done without any user interaction and when I say registration, I mean the process by which the Centinel client registers these credentials with the Centinel server.

In the model I had for informed consent, we would have centinel register a user, but prevent them from doing anything, the first time they start centinel. Whenever the user tries to run centinel, we would print a message on the console saying that the user needs to visit http://centinel.noise.gatech.edu:8080/get_initial_consent?username=username-var, where username-var is the user's username (Note that this is a live demo of what we have for informed consent so far). From here, we follow the informed consent process through and auto-populate the username where necessary. In the backend, we have a field that stores if the user has completed the informed consent process. If the user has not done the informed consent, then we will not give them any experiments or let them upload any results. At then end of the described informed consent process, the user sends an authenticated request that s ets the informed consent field to True.

Potential modifications

To make our informed consent/registration process more inline with what Phillipa suggested, we could make some or all of the following changes:

we could register each PI before deploying, then let the user do the informed consent in the field. Each user would still be registered, but they would not have any interaction with the server until after they did the informed consent piece we could make the username/ identifier shorter and more human readable potentially we could do a completely separate process for the pip package and our deployment, though this seems unnecessary. @phillipa, would any or all of these modifications address your concerns? Also, are there other changes we should be aware of for informed consent? We just wrote up what you sent us in pdf form.

— Reply to this email directly or view it on GitHub.

[ben-jones]

@phillipa, we can make it shorter, but is that required by the IRB? All of this is/will be autofilled, so the user could copy and paste it to keep, but they won't need to type it themselves.

It seems like longer usernames would provide more security by making them harder to guess, but we could make the password longer to compensate. I would prefer longer usernames, but I don't feel strongly. @rpanah, @gsathya, @feamster do you see advantages to longer usernames?

[phillipa]

Yeah I never thought about autofill. That should solve it.

Also you saw my comment that we have approval to not actually embed the external sources right? (Though the Freedom House styles look nice)

On Sep 25, 2014, at 8:24 AM, Ben Jones notifications@github.com wrote:

@phillipa, we can make it shorter, but is that required by the IRB? All of this is/will be autofilled, so the user could copy and paste it to keep, but they won't need to type it themselves.

It seems like longer usernames would provide more security by making them harder to guess, but we could make the password longer to compensate. I would prefer longer usernames, but I don't feel strongly. @rpanah, @gsathya, @feamster do you see advantages to longer usernames?

— Reply to this email directly or view it on GitHub.

[ben-jones]

@phillipa, I vaguely remember this, but Sathya and I discussed potential attacks when I wrote this up last night and decided that it would be better to download it all at the Centinel server rather than at the client because we don't want freedom house or any of the other sites to get the IPs of our clients.

[phillipa]

You could still link it and have it open in a new tab/page though (having it delivered locally) rather than embedding it directly in the form though … It would help solve your style sheet problem.

On Sep 25, 2014, at 8:39 AM, Ben Jones notifications@github.com wrote:

@phillipa, I vaguely remember this, but Sathya and I discussed potential attacks when I wrote this up last night and decided that it would be better to download it all at the Centinel server rather than at the client because we don't want freedom house or any of the other sites to get the IPs of our clients.

— Reply to this email directly or view it on GitHub.

[ben-jones]

@phillipa, I like that idea a lot and it should solve #10

[ben-jones]

We completed this issue by inserting the username and password as hidden fields in the HTML and showing the user this username whenever they go to complete the informed consent. Additionally, I refactored the informed consent pages so that they load the freedom house and canada pages as iframes. The iframes point to versions of the content that are hosted on the centinel-server. The centinel-server server downloads the content from these pages, strips all src and href links out (replaces them with empty strings), and hosts the content locally.

Unfortunately, there is still an attack avenue through JavaScript, but when we remove all JavaScript, the Canada travel page won't render (likely a bad parsing regex). Regardless, this is almost certainly sufficient for our needs.

All of this functionality is added by #14