We minimize the data we collect about our users. Originally, this was because we didn't feel technically capable of protecting their data. Today, we do it because it reduces friction and because we believe it's the right thing to do. That said, we also believe that account systems offer a lot of conveniences. The loginless system we've developed is an attempt to combine these two ideals into a persistent user identity without requiring any personally identifiable information (PII) such as an email, phone number, or password.
An account system needs two things to be complete: restorability and syncability. Restorability refers to the ability to restore an identity that was previously tied to a device (think re-downloading an app on your phone and signing in again). Syncability refers to the ability to sync an identity to a new device from an existing one (think signing into your email account on your new phone). We describe the process of assigning, restoring, and syncing a user identity and how this process differs depending on device type.
The first time a user visits the Coursicle web app or downloads a mobile app, we generate a random UUID server-side and set the UUID in the user's cookies (browser), iCloud key-value store (iOS), or Backup Service (Android). On the web app, we also fingerprint the user's browser, hash the fingerprint, and then send this hash to our server along with any application layer data that may help us re-identify the user later, such as which college they go to. We store their UUID and this hash together in our database, and on each new page they visit, we update the hash (if it has changed), to ensure we have the freshest hash for them.
In addition to this UUID, we assign the user a picture selected randomly from a set of 350 hand-picked public domain images. This allows users to visually identify whether their device becomes dissasociated with their UUID without memorizing it, since they will have become accustomed to seeing the same image each time they use Coursicle. We also display the last 6 characters of their UUID (which we refer to as a User ID) and a link to both a summary of the loginless system and opt-out options.
Syncing and Restoring
When a user on iOS or Android installs the Coursicle app on a new device, or re-installs it on a device, iCloud key-value store or Backup Service automatically restores their UUID to the device (provided they are using the same iCloud or Google Play account).
Any time a user visits the Coursicle web app and does not have a UUID already set in their browser, we silently attempt to re-identify them using their browser's fingerprint and any relevant application-layer data (such as the college of the page they're visiting). If this silent re-identification fails and they actually are a returning user and want their data restored, we provide them with several options depending on whether they have a second device that is still associated with their UUID.
If they have a second device already associated with their UUID, they have 2 options:
Option A (more secure): on this second device, the user enters a "sync" mode which lasts 10 minutes. During this time, the first device they type their User ID (last 6 characters of their UUID) into will be automatically associated with their UUID.
Option B (more convenient): on this second device, the user enters in their email or phone number, and a special link containing their UUID is emailed or texted to them. Opening that link on a device will automatically associate that device with their UUID.
If they do not have a second device already associated with their UUID (or do not presently have access to it), they have 3 options:
Option C (more convenient): if the user has previously used our system to email or text themselves a special link, they can open that link again on their device to associate it with their UUID. A downside of this approach is that the user at one point had to provide PII. Fortunately, though, storing that PII in our database isn't necessary to support this option.
Option D (most convenient): if the user has ever provided us with their email or phone number, they can re-enter that PII and we'll send them a link they can use to associate their device with their UUID. Unlike option C, though, this requires that we store this PII in our database.
Option E (more secure): if the user had written down their entire UUID, we allow them to type it in to restore their identity.
It's important to note the flexibility of the loginless system. Depending on where on the convenience–security spectrum developers would like their application to sit, they can curtail the options above to a select few. In fact, some applications, such as Lyft and WhatsApp, already use a modified version of Option D as their only method of login. We think this is a step in the right direction and we're interested to see how we can take it further with loginless.
Loginless is an experiment we've been eager to try. That said, even if it proves sucessful at Coursicle, it still may not be widely applicable. This is because our user base is very unique: the lifespan of a Coursicle user is limited to the ~4 years they're in college, most college students have at most two devices they use regularly, students are nicely segmented by college (helpful for re-identification), and the information students keep on their Coursicle account, like which classes they're taking, are not closely guarded secrets.