jewelfox: A portrait of a foxgryphon with a beak, black fur, magenta hair, fox ears, and a neckband with a large jewel on it. (Default)
[personal profile] jewelfox
tl;dr Imagine a web browser that only lets you log in to MySpace and Yahoo!, and breaks when you access Google+, Pinterest, or any microblogging site. This is GOA in 5 years.

The situation

GNOME Online Accounts is GNOME's attempt at letting your desktop OS work seamlessly with websites. Instead of having to browse to Google Drive's website, for instance, you just open up GNOME Documents and there's all the stuff that you've written on Google Docs over the last several years.

It works this way because that's how it's supposed to work. GNOME Documents is useless in this day and age, to a growing number of technical and nontechnical users, if all it can get to is stuff on your hard disk. And Skype has become the universal chat client in the world at large, partly because of its effortless handling of video calls but also because of its seamless way of handling logins and chat logs from any device.

Once stuff that works this way becomes the norm, anything that doesn't support it feels broken.

The problem

The problem is that GOA only supports Microsoft Exchange, Microsoft Windows Live, your Google account, and your Facebook account. That's it. There is no easy way to add support for your application to GOA. There is no way to share information from your app to others via GOA. The only way to get GNOME's core applications to work with your web app is to patch GNOME core, which involves persuading GNOME's core developers that your app is an essential part of GNOME.

This renders GOA irrelevant, and it renders GNOME's core apps irrelevant. Because by the time any of us realizes an app needs to work with GNOME, a bunch of people will have already stopped using GNOME core apps.

The next Facebook will be out for five years before someone from GNOME decides "hey we ought to import your pictures and contacts from this," because it won't be targetted at the demographic which comprises most of GNOME's core contributors. The next Skype will work on Ubuntu first, because it allows apps to add plugins to its version of GOA.

This has the potential to cause a bit of a mess, but the alternative isn't a pure and uncompromised user experience. The alternative is GNOME core having to make the decision, for every new web app, of whether or not GNOME should support it. The alternative is new Free Software web apps not working with the premiere Free Software desktop, because they'd rather write a plugin than beg and get turned down anyway.

The alternative is nobody using GNOME, because it doesn't work with their stuff.

"Asking permission from GNOME's core devs" is a solution which does not scale, and which imposes an unnecessary burden on third-party developers. We need a new solution. Because whatever we can do that makes it easier for people to work with GNOME, to write apps for GNOME, to write apps which tie in to GNOME, is a step towards making GNOME more relevant to more people's lives.

Yes!

Date: 2012-11-16 02:17 am (UTC)
From: [identity profile] adamwill.id.fedoraproject.org
This. So much this. I had the same thought when I first heard of GOA - it has the potential to be an awesome mechanism, but it's _so_ potentially broad (let's face it, this at least potentially covers almost every instance of 'access Stuff from Elsewhere') that it inevitably will need to be easily extensible to work properly. Thanks for explaining why very clearly, and why the messiness will just have to be dealt with.

Extensibility in GNOME

Date: 2012-11-16 07:47 am (UTC)
From: [identity profile] mardy [launchpad.net]
Hi JewelFox! I'm Alberto, one of the Ubuntu Online Accounts developers. After Debarshi's post in his blog, we tried to get together in IRC to see if we could find some ways to reduce the split in the two different implementations and find some more common points than divisions. Unfortunately this lasted just a couple of days, after which the communication got interrupted (for personality reasons and pride, if you ask me, but you might want to hear Debarshi's version as well).

But even though we talked just for a short time, I think that the main obstacle between GOA and UOA emerged rather clearly: GNOME wants to control what accounts/applications are integrated with GOA, while for UOA third party integration is very welcome.

But this is not some limitation of just GOA: it's the direction taken by the GNOME project as a whole. GNOME seems to aim to be a final product, with very limited customisability and extensibility. Even the GNOME control center does not allow third party applets.

And what about "writing apps for GNOME"? Which toolkit should the developer use? Gtk+? It seems it's being discouraged by GNOME developers themselves, unless you are willing to closely follow GNOME development to see when APIs break:

"at this point in time I'd advocate against Mozilla, Libreoffice, XFCE or LXDE to switch to GTK 3"
(from https://mail.gnome.org/archives/gtk-list/2012-November/msg00044.html)


So, unless the direction changes, I don't see how GNOME could become more relevant for application developers who don't have their projects in git.gnome.org. :-(

Date: 2012-11-16 07:55 am (UTC)
From: [identity profile] dylanmccall.com
As it happens, this is one of the reasons for Ubuntu Online Accounts, which is (as I understand it) based on the system from Meego. On the one hand, there's a risk of duplicate account providers. For example, note the horrible mess with OpenID where everyone wants to be a provider for some reason (even though it involves more work :/), but very few websites want to be consumers. Of course, the other side of that coin is, as long as an application _can't_ get the account providers it needs from GOA, it just won't use the technology. (Hence, no providers to begin with, let alone duplicates).

I agree with you, that latter end of things is a little more serious, especially when we just end up with major downstreams replacing the offending pieces with their own incompatible technologies — or adding their own account providers. I wonder if a shiny website or something could help with the duplicate providers concern?

Ignoring the key issues

Date: 2012-11-16 12:07 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawmsR5-w_CfeZX7OdVWzeaPIrTLif2YLZUk
Jewelfox, you seem to be missing a few important points here, and you make some questionable assumptions.

First of all, you assume that the only option for an application that wants to integrate with an online service that isn't supported by GOA is to patch GOA. That's obviously a fallacy. Applications can do their own sign on if they want to, with any services that they choose. GOA doesn't prevent that in any way.

Second, you assume that GNOME will only include account types that are interesting to the developers who work on GNOME: another odd assumption. Even if GNOME developers do use different online accounts from their users (I'm not convinced that this is the case) it is entirely possible for them to provide extra account types that are valued by our users but not us personally.

Now for some of the issues that you miss. The purpose of sign on is to *identify* both a user and an application. But if an application uses a common sign-on mechanism, like GOA or UOA, it has to be identified as the system and not as an individual application. If a Twitter client authenticates using GOA, it is identified as "GNOME", for example, not as the application itself. There's a real issue here for 3rd party application developers. If I write a Twitter client for GNOME, do I want every tweet sent from my application to be identified as being sent "from GNOME"? Probably not: it denies the 3rd party application developer important exposure on the services with which they integrate.

The other issue with using a common identity for applications is that it means you can't selectively disallow them via online services. You can't block a specific application from using your Google account - you have to block everything that is authenticated using the GNOME identity.

The third and final thing that you ignore is application sandboxing. Right now, we don't have this in any shape or form in GNOME. That means that any application has access to any online account added through the sign on service. We should take this very seriously indeed. We are essentially giving free access to people's online accounts to anything on the system.

Looking forward, application sandboxing is an absolute must. Users should have control over which applications have access to individual online accounts. Until that happens, being conservative about which account types are supported by the system seems like a reasonable position to take.

Don't get me wrong - I'm not saying that GOA is 100% correct and UOA is 100% wrong. But you do seem to miss some of the key issues.

Re: Ignoring the key issues

Date: 2012-11-17 05:50 pm (UTC)
niya: (Default)
From: [personal profile] niya
First of all, you assume that the only option for an application that wants to integrate with an online service that isn't supported by GOA is to patch GOA. That's obviously a fallacy. Applications can do their own sign on if they want to, with any services that they choose. GOA doesn't prevent that in any way.

Obviously. But isn't that the entire point of GOA? To allow sign-ons to an account and have applications that support that type of account to use them without being granted access to the authentication details and allow for integration. ie: Mail client accessing a mail account or a photo sharing app being able to seamlessly integrate with Picasa?

If we're going to say, well, applications can do it themselves, then what's the point of GOA at all? Any application can do their own sign-on.

Second, you assume that GNOME will only include account types that are interesting to the developers who work on GNOME: another odd assumption. Even if GNOME developers do use different online accounts from their users (I'm not convinced that this is the case) it is entirely possible for them to provide extra account types that are valued by our users but not us personally.

I certainly can't speak to how GNOME does things, and I hope that it is as you say, but I know other projects where I, or others, have requested, or even provided patches, to add functionality that were needed, and the maintainers have said to us, essentially, sorry, that doesn't match with the way we use our product, so no.

The other issue with using a common identity for applications is that it means you can't selectively disallow them via online services. You can't block a specific application from using your Google account - you have to block everything that is authenticated using the GNOME identity.

Why? Sure, on Google's side it says GNOME, but on the client side there's still AwesomeIntegratedGoogleApp and GoogleIntegratedAppIDon'tLike. I can just uninstall the second if it's causing a problem.

Looking forward, application sandboxing is an absolute must. Users should have control over which applications have access to individual online accounts. Until that happens, being conservative about which account types are supported by the system seems like a reasonable position to take.

If a user doesn't have control over which applications have access to which accounts, how does limiting the type of accounts help?

In what way does saying, only Facebook, Google, etc... accounts are allowed protect the user's Facebook, Google, etc... accounts?

That is, it seems as though the two issues are unrelated, and preventing the addition of new account types does nothing to protect the security of the accounts the user does authorize.

At least, that's the way it sounded to me, so please correct me where I am incorrect.

About us

Furry, fantasy, and fanfiction writer. Miniatures hobbyist, Mi'qote White Mage, 4E DM. Windows gamer, fangirl, and developer. Pronouns she/her, they/their.

Transfemale plurality, otherkin, fictive. Polyamorous pansexual. Proud introvert. Inari worshiper; xenotheist.

We wrote Jewelfox's Otherkin FAQ.

Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Dec. 21st, 2014 04:27 pm
Powered by Dreamwidth Studios