Public users' sessions

[gunar]

Currently PlanX stores session information on the computer's localStorage. This allowed us to skip having a login wall, while still permitting a user to come back at a later time to continue their application. This is all fine and dandy when you're using a personal computer, but PlanX will be accessed by people in all sorts of computers, including public ones like in libraries.

What can we do to:

• allow users to resume their application at a later time (most flows are long and can take someone more than one day to finish)
• preserve the user's privacy in case of a shared computer

Proposals for discussion

Saving session to a file

Allow user to download a .json file with their session, than load the file at a later time in another window. Of course this won't work if the session schema changes—and this is already the case today with sessions stored locally, where if the schema changes the session can't be recovered—however having a file laying around in a usb-stick is annoying. To upload this file and have it not work would be frustrating, and would perhaps trigger support tickets asking us to re-format the file to make it work.

Adding a login wall

The "obvious" solution is adding a login wall. We wanted to avoid that as it's a tricky thing.

• It's not really our responsibility to maintain (and verify) the identity of UK citizens.
• Also, for how long would we keep these sessions?

Username and password

This historically the default one. However, the homo sapiens species has a tendency to not use password managers and forget passwords, so inevitably we'd have to build a password reset flow (which sends an email), at which point we might as well just use magic links.

Magic links

Magic links make away with the need for passwords. The user inputs their email address only and receive a link in their inboxes that logs them in. Next time they want to log in, be it in a different computer, they input their email address again and get a new login link in their inboxes.

Magic "codes"

In order to simplify the process on public computer, perhaps we could send "codes" to the email address as opposed to long email links. This means the user could receive the code in their phone and type it into the computer. Otherwise, the user would have to log into their email account on a public computer just to receive their links—which is also not optimal.

Secret application code

We could generate a "code" (an identifier) for each application. Similar to flight ticket record locators (e.g. AH32PR). When starting the flow the user receives this code, and is prompted to write it down somewhere. Because the code is short it's easy to write it down on paper or in the notes app on their phones. Whenever the user wants to resume their application in a new computer, all they have to do is type it the code they've received previously.

This solution would require a brute-force protection algorithm.