A thought experiment:
A software developer decides to write an open-source GNOME desktop application that interacts with any number of Internet services, such as Facebook, Gmail, Flickr, and so forth. It’s not specific to any one service, however. The app should take advantage of all the available desktop technologies, not only to leverage all that hard work, but also to be a good desktop citizen.
The first thing the application does is log in to an Internet service. What should this developer do?
(a) Handroll the authentication code. Most Internet services use a token-exchange system, but each service is different, so the developer will need to write custom code for all of them. The user will want the application to save the password for next time, so better look into keyring solutions. And there’s always the problem of where and how to store long-term tokens, since every service has its own Terms of Agreement. And don’t forget to request Application Keys — each service has its own. Some services have different entry points for their various “faces” (i.e. Yahoo! and Flickr) while some have a federated login system (i.e. Google).
Halfway through the process the developer thinks, “Why am I reinventing this wheel? A lot of applications could use this code.”
Or (b) Use a system library. The developer calls the library and gets back a token. No messing around with passwords, keyrings, confirmation Web pages … all that’s handled by the system service.
The developer thinks, “Perfect! Problem solved and we’re being a good desktop citizen because the user only has to enter their password once.”
(b) seems the obvious choice, right?
Then the developer learns that Ubuntu and most of its derivatives (Ubunten?) use Ubuntu Online Accounts (UOA). The rest use GNOME Online Accounts (GOA). UOA and GOA are not API/ABI compatible.
Suddenly (a) looks like an appealing prospect.
This is a poisonous situation for application developers. It’s not terribly visionary of me to suggest that the number of programs that interact with Internet services — the magical “cloud” — is only going to grow over time. GNOME and Ubuntu are both acutely interested in attracting more developers (or at least should be). But new and curious developers arrive and are confronted with this situation.
I speak from experience. Both Shotwell and Geary could use some kind of Online Account solution today. Canonical has forked Shotwell to call UOA rather than our handrolled code, but those patches have not migrated upstream, nor could we take them as-is. Requiring UOA would preclude Shotwell from running on non-Ubunten distros.
I’m not here to argue UOA vs. GOA, or GNOME Shell vs. Unity, or lament that there’s yet-another split on the desktop. I accept that both sides have decided to go their own ways (here’s Debarshi Ray giving his reasons). But we at Yorba want Shotwell and Geary to work well — no, work spectacularly — on all GNOME desktops. That we can’t deal fluidly with something as low-level as server credentials seems absurd.
I once had a professor tell me, “All problems in computer science are solved with a layer of indirection.” He was being snarky, but there’s a germ of wisdom in that observation. It seems to me that the solution to the GOA/UOA divide could be solved with a translation or wrapper library. I’m not thrilled about wrapper code, but sometimes that’s what you’ve got to use.
To throw the first dart at the dartboard, here’s my proposed interface for such a library:
- Enumerate supported Internet services: Facebook, Yahoo!, Google, etc.
- Query a particular service for details/capabilities/description/icon/etc.
- Generate an authentication token for a particular service
- Launch the login/account registration application (i.e. the GOA/UOA program that takes the user though the steps of logging in to a service and making it available to all applications)
Obviously it’s far more complicated than this, but that’s the gist. I know GOA is DBus-based, and I believe UOA is as well, so the solution could simply be a DBus interface that both technologies implement, perhaps in the org.freedesktop namespace. In fact, maybe this should be a freedesktop.org initiative.
We need something. Asking an application developer (including Yorba) to pick UOA or GOA is a non-starter. There seems to be a bit of bad blood between the GOA and UOA camps — I don’t know all the details — but I ask both of you to scratch together a bridge rather than fork the path.
Seeing as these frameworks are themselves abstraction layers, adding another abstraction layer on top seems a bit overkill? (To play the stereotype monkey for y’all: when a KDE hacker says you have too many layers of abstraction … 😉
On the KDE side of life, it’s been 99.9% decided that we will be using AccountsSSO (aka UOA) as well. That means that it will not only be Ubuntu but also all OSes that use KDE’s Plasma Workspaces (Desktop, Active, etc.)
I read the various blogs etc. about why GNOME went their own way with GOA .. but it would be a really awesome thing if GNOME also adopted AccountsSSO as we would have one abstraction layer for online accounts.
As you noted, this is a bad situation for application developers and there’s really no good justification for it.
Btw, don’t let the Ubuntu in UOA fool you too much: AccountsSSO started in and first appeared in MeeGo (e.g. the N9 phones) and was adopted by Ubuntu. It’s not Ubuntu specific by any means, and I think it is great they adopted rather than created another system.
I know another abstraction seems overkill, but unless all parties agree to one system (which I don’t see happening), then I think it’s the only reasonable solution.
The reasonable thing to do is to “give up”.
Vote with feet/code? Only target the marginally interoperable or easier version?
The impression I got from the sidelines is that there is this concept of GNOME OS which drives the development of components such as GOA. While GNOME OS as a comprehensive platform might be an appealing idea with a lot of technical merit to it; it also comes with all the ‘airs’ of a market leader OS. IMO this hurts GNOME because GNOME OS is not in any shape or form in a market leading position and therefore can ill afford to pull random stunts like that. At least not if the objective is to have applications which work well with GNOME right now instead of some hypothetical future by which time all the auth providers in GOA/AccountsSSO will probably have been put to pasture anyway.
UOA is truly an awful bit of software. Ubuntu decided to switch to UOA ,after GOA already existed, presumably for “differentiation”, “uniqueness”, “branding” and various other nebulous buzzwords that Mark Shuttleworth likes to drone on about. A standardised DBus API seems to be the answer. Then Ubuntu and KDE can run whatever shitty implementation they want.
AccountsSSO/UOA *is* a DBus API. Are you suggesting a DBus API that in turn targets multiple DBus APIs?
Hi Jim, and thanks for this blog post. I will not repeat why the split happened; most of the reasons are given in Debarshi’s post which you linked (and in the links departing from there). To me, it mostly looks like a reformulation of NIH with nicer words. I can only repeat that if GNOME is willing to reconsider the AccountsSSO solution, we would be happy to help. There aren’t any unsolvable issues.
This is however orthogonal to the other point you raise: even if the implementations are different, it should still be possible to figure out a client API which can wrap both. True; there are many differences, but from a client POV they should all be solvable. Unfortunately I don’t have the time, the motivation (and the energy, I’m afraid) to drive a similar project, but if someone else starts a topic about this in the freedesktop ML I’ll try to participate. 🙂
Blerh, KDE. Even the name AccountsSSO induces vomiting.
“If you don’t have anything ~~nice~~ important to say, don’t say it at all”.
The current situation is not ideal for users as well because the current situation defeats the whole idea of having The One place for credentials and permissions. Personally, I find this very unsatisfactory, since there seems to be no easy answer.
Something to add: Empathy (or better, Telepathy) has an interface for plugging in account backends, and has a plugin for GOA and another for UOA. Evolution is going to follow the same route.
Since Shotwell publishing plugins are also, well, plugins :-), you could try a similar approach: you could have a different set of plugins for GOA and UOA (you could create a base class which does the real work, and the subclasses will provide the authentication). Then you load all plugins, and ask from each of them the list of accounts; if a plugin doesn’t give you any account, you skip it (this is actually what the patch for UOA was adding to the plugin interface).
If you prepare the base classes like that, then I or David will happily write the UOA plugins.
We’ve discussed the online-account-plugin idea a bit here for Shotwell and it may wind up being the solution to this problem. But all that does is take my proposal and push it into the application space. That work has to be done by every application: Empathy/Telepathy, Shotwell, Geary, and so on.
It seems to me that these Online Account solutions are meant to solve two problems:
(a) Give the user a single place to sign on to various Web services
(b) Give applications a single place to go to get these credentials
In essence, problem (b) is not being solved. Worse, as Lawrence’s AskUbuntu link demonstrates, problem (a) is not being solved either.
No offense, but this idea just sounds stupid. Nobody can decide on which of two competing APIs to use, so you’ll introduce a third one to give developers even more choices to worry about.
No – just pick one, and go with it. Even if it you have to put all the competing developers in a cage to fight it out, that’s better than making things worse by adding yet another API, and an extra layer of indirection.
I don’t think it’s “stupid”, this kind of solution happens a lot. I don’t like it, but I don’t like the situation even more.
There’s been a few calls to just pick one and go with it. Shotwell and Geary picks one, another app you use picks another … and every user will soon have two Online Account services on their desktop, and will have to login twice to every Web service they support. Suddenly it’s not a solution any more.
I didn’t mean each project should individually pick one – I meant that the major projects who wish to make use of online-account functionality need to collectively sort this out.
Maybe that means enhancing one or the other to have the capabilities of the other, maybe it means designing a new option from scratch to meet everyone’s requirements. Either way having everyone migrate to a single provider is no more technical effort than having people migrate to a new API that can support multiple providers. It just needs cooperation instead of the usual factional bickering.
Oh well. Personally i don’t use neither UOA nor GOA. They both are too limited, too cumbersome to use, too buggy, and don’t beat good ol’ browser.
Yeah…adding another layer of abstraction on top of this would be stupid and obnoxious and, quite frankly, might not help the situation at all. After all, its success relies on developers knowing about and using the second-level abstraction rather than UOA or GOA.
It’s the system tray debacle all over again: KDE and Ubuntu do one thing, GNOME does another. It’s a tragedy, really. We need to stop fighting each other when our real enemies are on the march.
Paraphrasing my own blog, XEmbed, QtWebKit, QWidgets, dbus-glib and a pass through authentication scheme — that is why we couldn’t use the MeeGo’s SSO as it is in GNOME when this was initially discussed on d-d-l.
And in any case Ubuntu is increasingly becoming a separate OS or DE — think systemd vs upstart/ConsoleKit, gnome-shell vs unity. So I am not sure what to say if they decide to re-write some component of GNOME all by themselves and suddenly announce it 6 months later. But, I guess, every project has a right to choose what is best for them and I don’t think Ubuntu owes GNOME an answer to “why did you do that”.
GNOME, on its part can only hope to discuss and talk about things in public — blogs, public mailing lists, IRC, etc., and I believe we do that.
Anyway. 2 other things.
1) Are 3rd parties interested in using the platform’s SSO? Last GUADEC when we discussed with you and Lucas, you were apprehensive of loosing your brand if content uploaded via Shotwell got marked as GNOME, instead of Yorba/Shotwell. That is a valid concern. What are your current thoughts on that? What does other 3rd parties think?
2) Do we (ie. GNOME) want to let 3rd parties use our SSO and in turn our brand? We don’t know. Different people will tell you different things. Currently there is no way for the user to say: “ok, I will let application A & B to use my credentials, but not P”. In other words, you can’t sandbox suspicious applications from picking up your credentials via the SSO.
(1) Our concern wasn’t so much about losing our branding as being replaced by another brand. Yorba’s not out to make itself a household name, but if we see “Photos uploaded by Ubuntu” or “Photos uploaded by GNOME” on Facebook, it gives us pause.
I can’t speak for other 3rd parties, but it would be nice if the branding issue could be resolved by the OA services. I suspect the solution is different for each Web service (and for some, not an issue at all). Bottom line, this issue won’t stop us from moving to an OA solution. What’s stopping us is having to code to two separate APIs.
(2) I can’t answer (2), but I appreciate the concern on your end too. It does sound like there’s more thinking to do regarding OA’s and how they interoperate with applications.
Hi Jim, as far as UOA is concerned, the branding issue is resolved. In fact, Evolution will use its own Google application key.
I think that having each application use its own keys is a gain for everyone 🙂
“XEmbed, QtWebKit, QWidgets, dbus-glib and a pass through authentication scheme”
The first three are related to the UI side. What’s interesting to share is the infrastructure bits. GNOME would presumably have its own UI face to the system (perhaps even using GtkWebKit?).
They ported to GDBus in version 1.4 so that’s a non-issue, too.
The pass-through auth would hopefully be manageable by a wrapper if GNOME really wants to avoid it.
So there’s the one real issue: pass-through auth .. and against that you are investing all this time and effort into creating a framework that you will have to maintain (lower bus factor) and is not interoperable with what other leading Free software desktop and mobile systems are using (Ubuntu, Jolla, Nemo, KDE ..). It seems a lop-sided cost/benefit calculation.
I understand there is quite some history here with Canonical and what not, and more than a little misinformation spread around. It would be awesome if we could find some time on IRC or Google+ to discuss the situation. At worst we’d lose 10 minutes of our lives and have a better understanding of why each of us (KDE and GNOME) are making the decisions we are. At best, we’d find common ground and maybe even a common approach.
What do you say? You can reach me on G+, on irc (aseigo) or by email (aseigo at kde.org)
I’ve only skimmed the past GOA vs UOA discussions, but it seems UOA has pluggable backends. Perhaps an UOA plugin which is implemented using GOA would allow for using a single application interface which integrates with both systems, without inventing a new interface/library?
This low level stuff for Linux should be standardized and developers should not have to think too much about it. Talk about it some more and make it work i know you can do it.
Yorba does make nice apps for us Linux users and isn’t it a shame they have to think about stuff like this and waste energy and time on it because we have 2 solutions for the same thing? In the future maybe Linux devs will be able to achieve things like one toolkit for apps that works for all but for now at least try to achieve one solution for OA that works for all and yes rename it to simply OA.