Re: Online Accounts panel for 3.2

[Alberto Mardegan <mardy users sourceforge net>]

Hi David,

On 04/19/2011 04:08 PM, David Zeuthen wrote:
> Hey,
>
> One of the things I'm looking at doing for 3.2 is the Web Accounts panel:
>
>   http://live.gnome.org/ThreePointOne/Features/Sharing

See the "Current status" section in that page. We already have all of this (and 
more) in MeeGo, and I'm willing to support any efforts in bringing this to Gnome.

> I sat down last week with one of the designers, Jon McCann, and we
> came up with what we both think is a really nice user experience. It
> is described in [1] for now - will move to the wiki soon.
>
> Implementation-wise, I can see this as a very minimal daemon / library
> that sits below libsocialweb, Telepathy, e-d-s and other APIs (e.g.
> these libraries/frameworks would use this new framework) that is
> dealing data online accounts.

In MeeGo we chose two split the thing into two: account framework, which simply 
consists of descriptions of providers and sources (which we call "services"), 
and a library wrapping a SQLite DB for accounts settings, where applications can 
read/store accounts settings (not the passwords).

The provider and services are described by XML files, which can be installed in 
predefined directories. This allows for expandability: to support a new service, 
you just need to install a package which adds a service XML file.
The service XML files not only describe the service (icon, name and provider) 
but also contain a default value for account settings; the account library uses 
these settings as fallback when a settings has not been explicitly written in 
the DB -- this is all transparent to the application.
The point of this is that you don't want to ask the user for the address of the 
IMAP server of GMail: we can write it in the service XML file.

The accounts library support change notification via D-Bus, so that when a 
setting in the GMail account has been modified, all applications interested in 
the e-mail service type are notified and can reconnect the account.

> This daemon / library would
>
>   a. have a notion of "source types"
>     - email source
[...]
>   b. have a notion of providers that can be added removed by the
>     end user
>     - Google (for accounts at google.com and Apps For Your Domain)
[...]
>   c. provide a concrete list of providers and what sources the
>      instance of the provider supports. For example, for my setup, I
>      would have the following
>
>     - zeuthen gmail com (an instance of the Google data provider)
>       - Mail (email source)
>       - Contacts (contacts source)
>       - Calendar (calendar source)
>       - Chat (chat source)
[...]

It's similar to what we have, except that we don't hardcode the list of 
available sources in the provider file. It's the source, who tells what provider 
(and source-type) it belongs to.

> This "screenshot" shows an example where the david fubar dk account
> needs attention (suppose that the password has been changed from
> another system). In this case, I think the desktop would show the user
> a notification saying "The account david fubar dk needs your
> attention" and upon clicking on it, the user is taking to the
> control-center pane above.

Mmm... that's one option, though I'd rather like that by clicking on the 
notification you directly go to the login screen where you can enter your password.

And one thing that I heartily recommend you based on experience: do *never* let 
the user change the username once the account has been created. This saves you a 
lot of trouble.

> This daemon/library thing, let's call it GOA (Gnome Online Accounts),
> would _not_ be a mechanism to access any of these services. But it
> would provide e.g. libsocialweb, telepathy, e-d-s and so on with
> either the username/password combo or the OAuth token, whatever is
> appropriate.

And for this we have the SSO framework in MeeGo. It's one daemon, that stores 
the user credentials on an encrypted partition which is mounted only when the 
user is identified (in our device we'll use the SIM card for this goal, in the 
Gnome desktop it could be the lock-screen password).

Passwords are generally not given back to applications; instead, signond (the 
SSO daemon) loads a plugin specific to the authentication method being used 
(SASL, OAuth, Google, etc.): the plugin gets the passwords, and uses it to 
compute a response to give back to the client. This response can be a response 
that the client must give back to the remote server in a SASL challenge, or a 
token that can be used to login.
In cases where the authentication plugin performs the authentication with the 
remote server, in case the password is wrong it will itself inform signond, 
which in turn will invoke a UI to prompt the user for a new password. If instead 
the plugin is simply computing responses without having knowledge if the 
password is correct, the application will get an error and it can retry the 
authentication with a flag which tells signond to ask the user for a new 
password before computing the response.

> I would imagine Telepathy/Empathy to use GOA to get the Chat accounts
> that is configured in GOA (in the above example, it would be Google
> Talk from zeuthen gmail com and Facebook Chat for davidz25). I would
> use an Empathy specific preferences window (not appearing in
> gnome-control-center I think) to add e.g. my ICQ account.

Telepathy has already been modified in MeeGo to support the accounts and SSO 
frameworks.

> There are of course security / implementation considerations
> (password/auth token hygiene, should we treat the desktop like it's
> not a single security context when it really is?) here - all of that
> comes next.

We addressed all security concerns already; feel free to ask in case you have 
some doubts.

> Technically, I'm proposing that we add a GOA module with
>
>   - a daemon, goad, that implements the org.gnome.OnlineAccounts interface
[...]
>   - a library, libgoa-1.0, that is used to speak to goad (but an app can
[...]

I'm afraid you are a bit too optimist; or maybe it's just me who likes making 
things more complicated. :-)

>   - initially GOA will know about the following source types
>      - mail
>      - contacts
>      - calendars
>      - chat

Also the {source,service} types should be installabe XML types, IMHO.

>   - initially GOA will have support for a couple of online providers (Google,
>     Yahoo! comes to mind) as well as "generic servers" (initially, say email
>     servers (IMAP/SMTP) and iCal/Jabber servers).

Our framework doesn't have any knowledge about specific account types. It's all 
handled in XML files and in authentication plugins (OK, OK, we also have account 
UI plugins for creating/configuring accounts, but we actually could have done 
without them and just have QML UIs -- and anyway these plugins are very trivial).

[...]
> Timing-wise, I'm not sure how it's going to work - I can have goa
> ready somewhat soon (it's actually a rather simple daemon/library) but
> I'm not sure if that's enough time for everyone to use it for 3.2...

I would encourage you not to start everything from scratch. As I said, we have 
it all done already (except the UI parts, which are not open source):
https://gitorious.org/accounts-sso

I'm sure that especially for the SSO part there'll be need for work in order to 
adapt it to the desktop; but it will still be far quicker than rewriting 
everything. The accounts part should be already well working on the desktop.

We are using the meego-dev mailing list for development of the frameworks, but 
as I wrote in my e-mail "Re: Planning features for 3.2" (date: 09/04/2011) we 
can move it to a different infrastructure (freedesktop.org?) if there's interest 
for it.

Ciao,
  Alberto


P.S.: I believe that GtkSwitch is perfect for this use-case. :-)

--
http://blog.mardy.it <-- geek in un lingua international!