The login screen of any web application is the equivalent of that application telling you 'In order to access YOUR data in MY database, prove you are who you say you are.' You're authenticating with the application so that you can have the privilege of giving it your data. An application's owner can restrict your access to your own data. They can delete the data. They can sell the data to a third party. They might introduce a bug that allows other people to access the data. They might get compromised. Or they can avoid all of this just to modify their policies down the road or see changes in ownership or management. It's your data! You shouldn't have to prove to anyone else that you have the right to access it. To gain agency over your data, you have to have agency over the database in which it lives. If you own the database, you actually own the data. But running a database is a serious undertaking that we can't expect from the average internet user.

Over the past few months, I've explored the concept of personal database authorization, which allows you to give an application access to a database you control. Specifically, I built an authorization flow into ayb, my project to make it easy to create databases, share them with collaborators, and query them from anywhere. Here's a video of how you can grant an application access to a freshly created database you own. Critically, the application has no login screen, instead asking for a database where your data will live: Authorization in action: A to-do application with no login screen that requests access to a database you control.

The Todos application in the video is static HTML, CSS, and JavaScript. It knows nothing about its visitors. When you first load Todos, it asks you to Connect to your database to get started. Once it has a token with which to query your database, all of your intimate to-do list items are stored in that database you own. You can revoke Todos' access any time. ayb is open source and while you CAN host it for yourself, do you want to? This leaves users with a frustrating choice: trade their trust of third-party applications for their trust of third-party database hosts.

The 'authorize, don't authenticate' model works most smoothly for situations where you definitively 'own' the data. The more the dataset is the result of collaboration or social interaction, the less clear it is who owns the data, and the harder it is to authorize access. Still, there's benefit to separating applications from the databases that they operate on. The abstraction means that once you get the hang of a tool like ayb, you can use it for multiple applications, which hopefully amortizes the cost of regaining agency over your data.