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 disassociated 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 successful 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.
6/9/20 update: it has become clear that browser fingerprint collisions are much more frequent than we expected. Since implementing the loginless system, 1.74 million browsers have visited Coursicle. 159,000 of these browsers were ineligible for the identity restore process because we detected two or more distinct users had browsers that had the same fingerprint. That means that only 90.8% of browsers using Coursicle were eligible for automatic restoring of data based on their fingerprint. We still believe that fingerprinting has incredibly high (≥99.9%) accuracy for unique device identification in certain use cases (such as uniquely identifying devices on a site with modest traffic in a 24 hour period), but we've found that when you remove time windows and expand to millions of devices across the internet, this accuracy plummets.
Among the 1.58 million browsers that the loginless system claimed it could uniquely identify, it ended up restoring users' data 154,000 times on 118,000 different browsers. Given the vast number of restores occuring, we've decided to make further modifications to the restore flow of the loginless system. Specifically, after successfully re-identifying users using their browser's fingerprint, they must now take action to confirm that the identity we're trying to restore to their browser is correct.
Before a restore is performed, the user is now presented with their user picture, name, user ID, and up to 4 classes that they've saved to their schedule. They are blocked from performing any action on Coursicle until they click on the recovered user profile, or the "That isn't me" button (which stops the restore process). Although we believe this will better protect user privacy, it does rely on trust and the attention of users, which shouldn't be the case when it comes to account security. Thus, we believe that further revisions of this system are inevitable, specifically those that move us farther away from a silent fingerprint-based restore process and closer to a conventional account recovery process. We believe a great next step is a CAPTCHA-like system where the user proves ownership of the recovered account by picking 3 classes they've taken out of a grid of 12 otherwise random classes from their college.