Anonymous Apps: Look Ma, No CIAM
Hiya,
I found this look at anonymous apps, by the folks at Stashpad, insightful. They built an anonymous document creation tool and shared issues they had to address.
I don’t know any details about their implementation, but reading between the lines it appears to be URL based. Ya gotta have some state somewhere, but there are other options using browser storage like cookies.
In the post, they discuss why you’d want to build an online, anonymous app. The primary reason is less friction. Any prospective user can access the application, use it and fall in love with it without the hassle of signing up.
In theory this will lead to greater adoption, though the article provides no numbers, and a brief google search didn’t turn anything up. But it stands to reason that the less your user has to do to access your application, the more users will try it.
The authors do address a couple of things to watch out for:
user confusion: users may not expect to access to an application without an account, since signing up for an account is such a common pattern. The article recommends using UX cues, such as the anonymous account icons you might see in a public Google doc, to make it clear the user is not known.
security: with such online applications, possession of the URL is the access control system (since everything has an access control system). While using random ids can prevent access through enumeration, if a link is forwarded, the document is accessible. However, this flaw does provide a path to monetization. Certain users will want assurances of privacy and will be willing to pay for it.
One approach they don’t address is offering a downloadable piece of software, whether that is a native app (like Bruno) or an offline PWA.
Such applications don’t have either of the above issues, though they do have their own set of complexities, including deployment and updates.
The Fundamental Tension Of CIAM
This article was interesting because it points to the fundamental tension in CIAM. Everyone who writes an application where CIAM is an architectural component wants:
To know who the user is
To get the user into their application as fast as possible
Anonymous applications tilt toward the latter goal. They are great fits when the use case is appropriate. Games, ecommerce stores and utility applications like word processors or diagramming tools all benefit by letting an anonymous user interact with the application.
With this approach, the user gets to see the value as soon as possible, which is helpful when the application is competing in a well-populated niche. (There are also use cases not suited to anonymous applications such as anything requiring payment.)
Account Transition
Typically, but not always, there’s a transition to account creation:
When the user wants to save their game to play later on another device.
When the user wants to order from the store.
When the user wants to save their document or diagram and access it from elsewhere.
If this transition happens, that’s where a CIAM system can be helpful. I wrote about how to use my employer’s CIAM system in this fashion, but the basic steps are:
Create a unique identifer for the user
Capture any data needed for the transition and tie it to this identifier (game data, products in cart)
Offer functionality requiring the transition (“save your game”, “check out with what is in your cart”)
Prompt for data required for a user account
Create the account
Copy over the data tied to that unique identifier into the new user account
The Value Of Anonymous Accounts
Anonymous users make a lot of sense for many use cases. If users remain forever anonymous, you can skip any CIAM integration, but if they do not, integrating a CIAM and building out a transition process makes sense.