This Time Self-Hosted
dark mode light mode Search

Identity Crisis In The Age of AI

Usual caveat emptor here: what Im writing here is my personal opinion, and while it does relate to a field my current employer (Meta) has interest in, it does not represent the views of my current, past, or future employers. Yes we all get bored by these preambles, but if you want to still be able to hear the opinions of seasoned engineers you’ll have to live with them. I personally would not want to lose my job because my posts are reported as being related to it. They’re not.

Over the past year, if you are a tech enthusiast, you cannot have missed the raise of a new class of software, which I personally started referring to as APA, Artificial Personal Assistant. Both because I dislike the “claws” name, and because as it was predicable a number of projects are now spawning to refine (pun intended) the concept and in some case “productify” it. I have played around with a couple of these projects (harnesses? frameworks?) if nothing else because in my profession I don’t get to choose not to engage at all with the newest hype without a good reason. I even engaged, at one time, with Bitcoin, if nothing else to know exactly why I did not want to ever touch any other carboncurrencies in my life.

I could be writing about what I expect these APAs to achieve, both in terms of wins and losses for society, of course. But that’s not honestly something I have enough expertise to write about. I’m sure that there are plenty of opinionists that will provide their hot takes as time goes by, and about as many actual researchers looking to make a study of them that will not get as many readers as the scary headlines. (Yes I’m being a bit cynical here.) Instead, I want to focus on one problem that has been nibbling at the back of my mind for many years now: who is the identity behind an account?

You may remember that a few years back I have written about my difficulties with setting up password sharing with my then-girlfriend (and now wife), as well as with my mother and my sister for different sets of accounts. The solution I’m using to this day is not really my favourite: for most (but not all, for various reasons) accounts, we now use shared email aliases, some of which go to me and my wife, others to me, my mother and sister, and some others going to my wife and her mother. This allows us to at least receive all the required notifications to handle these “shared” accounts, but they are, still, in an individual name. These become annoying when you have to call and they request to talk to the account holder.

I have to say I’m particularly surprised that, after this many years of digital life, we still haven’t solved the problem that many accounts belong to a family, more than to an individual. I know quite a few services allow supervised accounts for minors (my employer does that for Instagram, to the best of my understanding — I don’t work on that product and I have no need for supervised accounts so I have no idea how any of that works), and I believe Apple is the state of the art in terms of “family accounts”, but I have not used an Apple product outside of work for over ten years. Google theoretically supports “Google One Family” accounts, but the only features that appear to be useful at that point are Google Play paid-app sharing (which is also almost impossible to confirm before buying the app!) At the very least I would enjoy having a “Family Drive” where the files are organized together, instead of being shared “individually”, but I fear that particular feature is still gated behind the professional Workspace product (which explicitly shed any notion of being usable for families years back.)

Banks and other financial institutions, of course, already mostly know how to deal with this. Joint current accounts have been a thing for decades, and most credit card issuers have a concept of “additional cardholders” with more or less access to the card’s information. For example, American Express allows my wife to see all of her transactions in real time, as well as the offers and membership points, while my “main cardholder” account includes both our transactions, statements and so on. But somehow most of the household bills end up in a single account holder: power, broadband, mobile phones… Octopus is at least a little better in terms of being able to put both names on the account and thus count us both as account holders, but even that required us to send an email as it is not part of the normal flow of operations online.

But how does this even connect to APAs? Well, from a certain point of view, APAs could be considered similar to supervised minors. And my personal preference when playing with them, is for them to get their own accounts and identities, even though the default path that most people seem to take is to provide them with full access to their own (the user’s) accounts. This is understandable, as often registering a second account for the same service is considered a violation of the Terms of Service. Or it’s just incredibly complicated and fraught with issues. For instance, I tried providing my most recent APA with its own GitHub account – both so that it is very clear for the receiving end that they are interacting with an APA, and to make it clear on who the person responsible for the APA’s behaviour is (me) – but at first the account has been restricted and left pending review for nearly a month. I don’t blame GitHub: ensuring fairness for contributors on both the executing and receiving side requires a complex balance of intention and letter of the terms. Eventually, the account was reinstated, and even made its first contributions.

As an aside, I’m very much throwing anything that the APA is generating to the public as 0BSD, the most accepted intentionally permissive license I’m aware of.

Part of the problem is that the type of accounts that APAs would end up using are not new for most of these services, they just are not the kind of accounts those services have wanted to have in the first place: bot accounts. For the longest time, bot accounts have been the adversary, bringing nothing but spam and negative value content, at least outside of the enterprise space, which is why often the APIs for supervised bot accounts actually exist, but they’re behind a paywall, or at least restricted to use in ringfenced aspects, such as GitHub organizations. It also meant that the “valid” bot accounts would be balanced against the number of users they supported. A company with a dozen employees and a couple of bots is easier to support than a reality where every geek out there ends up with their own personal bot, or even more than one.

But to be clear, the problems and limitations around supervised bot identities do not stop at commercial services. Even when taking my least favourite option, the self-hosted path, there rarely are proper paths for these bots to be supervised: Nextcloud doesn’t have this as an option (though at least in some features it supports delegates), Home Assistant has an extremely coarse-grained permission system (at least for now, who knows, they can change it next month for all I know!), and good luck trying to get a read-only password set up with Mail-U.

And some of these end up being a horrible game of ping-pong between them. I would like for my household-wide APA to have access to both my and my wife’s calendars, and the shared “Family” calendar. We share each other calendars’ already, but we have our own mostly so that we don’t get reminded to go to an appointment than the other is due for…

… but it turned out to be a lot more complex than that. Google Calendar APIs require OAuth2 permissions to access the calendar in read-write mode. You can get a testing API key for that, but it needs reauthentication every seven days which is completely pointless for an APA. And for companies (Office APA? More like an Artificial Receptionist then) you have the option to make the key internal — but if you need to share it with two consumer accounts? You need to go through the whole verification as if the app was a launched startup! Ridiculous!

So I looked into alternative solutions and tried Radicale… and it’s almost as terrible. Well, it’s not as much terrible as it is not designed for either humans or bots. It’s over complicated to set up, with custom configuration languages and direct filesystem access, but also still relies on you providing authentication separately (okay that’s “easy” with Authelia thankfully) and even then you get no UI so you need to find something you can use with it, because sure as heck you can’t use Google Calendar on Android for that.

I have, eventually, found a half-decent way to test this out with aCalendar+ and DAVx⁵, but besides both apps costing money (sure, you can get DAVx⁵ on F-Droid, or build it yourself, but that’s not feasible for most people), they’re just… clunky. The fact that you need two separate apps to be able to get there is already annoying, but even then… oh and let’s not forget that Nextcloud doesn’t do calendar from their own Android app! Maybe everyone is using Macs and iPhones so they don’t care about the rest of us normies?

And this is without going back to “What is an email?” and the fact that oh-so-many authentication services require a strict correlation between email addresses and accounts — which doesn’t really work when you decide to use shared email aliases, and in particular, per-service shared email aliases.

For instance, any Shopify shop ends up recognizing you by email address, to the point that if you pay with PayPal, it will just use that email address for your order. Which is fine for an individual, but quite a lot more annoying when my wife wants to know when the thing I ordered arrives, while I’m on the other side of the world for a work trip. And it became annoying to me because, up until recently, my Shop app recognized email wasn’t the same as PayPal — mostly as a result of my having had PayPal now in four separate countries (and not having been able to immediately delete the old accounts when creating a new one.)

None of these are particularly novel problems, none of these are Earth-shattering, but they’re definitely going to be the kind of problem a lot of engineers will have to solve, or at least attempt to solve, if they want their software to fit in with a world that, whether we like it or not, is going to adopt some level of LLM automation, in form of Artificial Personal Assistants and the like.

Because the alternative, which is scary to me but unfortunately extremely likely, is that users of these artificial assistants will simply give them the passwords of their main accounts. Which is both risky for the users’ data (would you really let an LLM delete your emails without you?), and a bad experience for whoever is on the other side of a conversation (are you talking to a person, or to a bot?)

Or maybe Douglas Adams was right once again, and we’re on our way to have electric monks. On horses, of course.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.