One device vs. one account - pinocchio61/Architecture GitHub Wiki

One device vs. one account

Author

Brian Wan (bwan2)

Context

A decision on how we define one user in Pinocchio. A user is an attendee that will vote on transcripts for events they were present at. The goal of this decision is to recognize potential vulnerabilities or issues that would be present based on the decision we made.

Investigation

Defined that a user is either:

  • One device (smartphone)
    • cookies
  • One account
    • Pinocchio account
    • Reputation system
    • Identity cost
    • Attendence validation I
    • Attendence validation II

One device (smartphone)

It is not possible to uniquely identify a user's device with a web or native app running in iOS. iOS has prevented this due to privacy concerns. Trying to uniquely identify a device with an identifier is strongly avoided in all platforms due to privacy. Therefore, we cannot uniquely identify a user by identifying their device.

Cookies

We can manage 'unique users' by giving a user a cookie to recognize their previous sessions. In this case, attendees would be uniquely identified based on this cookie.

Cookies Issues

  • Cookies can be cleared to have clean access. Cannot store previously attended events this way.
  • People can generate multiple cookies to create multiple accounts

This decision is discarded due to potential sybil attacks, where a user can generate multiple accounts.

One account

This is easy to implement, but is susceptible to Sybil attacks, where a malicious user can create multiple accounts to manipulate the vote in their favor. There are several mitigation strategies, but do not completely mitigate the attack.

Pinocchio Account

This invenstigation is to make it difficult for a user to generate an account. A Pinocchio account per attendee would be easier to manage in our database, and we can combine this with tieing social logins (Facebook) or phone numbers to try to mitigate one user generating multiple accounts.

Pinocchio Account issues

A user may have multiple phone numbers/social logins (maybe store some ID info on server to prevent multiple users from logging in (e.g. location/name/phone combo)

We found that social logins or phone numbers can be easily generated, so this approach has been discarded.

Reputation system

We can tie a user with an email address for limited identity storage, or use external social APIs to identify a user. This is the same approach as the Pinocchio Account. In addtion to this, we would implement a reputation system to incentivize users to use thier main accounts and build their reputation. Reputation may be used to gain more weight than others in voting.

Reputation System issues

  • A user may have many “good” accounts and suddenly turn bad for one political event.
  • Need to build reputation system

For the first reason, where a good user can suddenly turn bad due to their account being comprimised or due to malicious intent, this would be very detrimental to the system and hard to detect. Therefore, we discarded this approach.

Identity cost

Put a cost to creating an account. Users will be not willing to create multiple accounts due to this cost.

Identity cost issues

If each account has some monetary value, how would we define this value that would incentivize people to not create multiple accounts?

We cannot identify a cost threshold that would limit large organizations resources to manipulate the vote. Therefore, we discarded this approach.

Attendence validation I

An established account verifies a new attendee, where they are referred and approved by another established account. Two established accounts are required to approve a new account.

Attendence validation I issues

An established account can potentially create multiple new accounts by approving themselves. This approach can be easily gamed with one valid account. Therefore, we discarded this approach.

Attendence validation II

An attendee gets a Pinocchio generated QR code if their device location is recognized by Pinocchio to be at the event location. The attendee is only checked in if that QR code is scanned by the event organizer.

Attendence validation II issues

  • An attendee can have multiple accounts to generate multiple QR codes.
  • Organizer has to be trusted to not create multiple attendees.

Decision

We decided on Attendence validation II and recognize the issues that can happen. Although having a trusted figure is unideal, we found that this is unavoidable in our investigations. Also, an attendee can also create multiple accounts, but we mitigated this by having them physically check in at the event. An organizer should be cognizant of an attendee potentially scanning multiple QR codes.

Attendence validation II is the most manageable approach in both development and issues that arise. As a result, we decided on this approach.

Status

7/3 - Proposed by Brian