Hmm, Isn't /usr/share/libsocialweb/keys/ there simply because Terms Of Service problems with embedding API keys?

To be honest, I don't think it makes much sense to play games like that... right now the thinking is that if we can't ship the API key in gnome-online-account's configure.ac file, then we just don't support the service (this is also to ensure that it works out of the box with e.g. jhbuild)... and since goa only supports Google right now (which is going into 3.2) and we're using anonymous API keys for that, there currently is no problem.

Note that there is some work going on at the GNOME Foundation level to a) study the TOS of services we wish to support (formally clicking "I accept this TOS" is usually a prerequisite to obtaining API keys for a service); and b) establish relationships with service providers.

Btw, sharing API keys might not even work... for example, Yahoo OAuth 1.0 API keys encode what kind of stuff you can access (the socalled "scope")... and most other keys encode the name of the requesting application which usually should be set to "GNOME".

Anyway, before closing this bug as NOTABUG, I'd like to understand the deeper thinking behind /usr/share/libsocialweb/keys/ ... anyone?

cc'ing Eitan & Rob who can probably talk about the libsocialweb side of things.

Eitan & Rob: ping?

I have not touched this in a while, but I would suggest looking into how bisho[1] does it. It also shares keys with lsw, and serves a similar function to g-o-a. In general, lsw is modular and silently fails to support a service if an API key is missing, so each distro and vendor could make their own deals with providers and provide their own API keys - not to mention custom lsw modules for those services.

David, most web services require defining a scope of permissions an API key has access to, we just need to make sure we get access for all goa and lsw functionality combined.

1. http://meego.gitorious.org/meego-netbook-ux/bisho

Currently we have the secret keys for the following providers embedded in GOA's configure.ac:
+ Google
+ Facebook
+ Windows Live
+ Flickr

Facebook and Windows Live don't require a secret key for desktop apps, only a client ID, which can be public.

Google needs both a client ID and client secret, but desktop applications are allowed to embed it in their sources:
https://developers.google.com/accounts/docs/OAuth2InstalledApp#overview

For Flickr, we had the SFLC review the terms of service and they think it is ok for us to do so.

For adding more providers in future, I am inclined to follow the current practice of requesting the SFLC to review the
legal stuff via the GNOME Foundation board. (They have already given their nod to add Dropbox.)

While the keys were the main problem, there are some other issues too. eg., trademarks for icons and bug 683968. 
Also, some providers like Flickr will refer to GNOME as untrusted 3rd party, but will refer to an N9 as a trusted partner. Presumably because of some contract between Nokia and Yahoo!. I am sure Apple has such contracts too.

Would be nice to look into some of these issues too.

Closing as NOTABUG as suggested before.

Please feel free to re-open if you think that a deep enough understanding of the situation with the keys has not been reached. :-)

I'll bite since I'm not sure I understand this "key" thing  anyway... Whe a Google or Facebook account is opened a small pop-up window appears and the user enters the user name and password. It seems - from other services like Suse Studio, that the same is true for Yahoo, so what's the difference? Why would a "key" of some sort be required for Yahoo and not Google?

Because Google and Yahoo! are different web applications.