That sounds like you are talking about application sandboxing. I am happy that you are interested in that area because it is something that we have recently started working on.

“We have reviewed the GOA project, but find it quite hard to add a full fledged ACL system there and fairly unlikely that it would get accepted upstream”

GNOME is working on a better application story, and sandboxing is one aspect of it. Here is one random URL on that topic: https://live.gnome.org/GnomeOS/Design/Whiteboards/Sandboxing

The G in GOA stands for GNOME, and I am curious what made you reach the above conclusion.

The Linux Desktop way of security-less environment is not acceptable in other environments. For us there is a strict requirement for SMACK-based mandatory access control. So you can define which application(s) can access which credentials and in which ways.

We have reviewed the GOA project, but find it quite hard to add a full fledged ACL system there and fairly unlikely that it would get accepted upstream.

Anyway, the work in progress is here:
http://code.google.com/p/accounts-sso/source/list?repo=gsignond
(also the authentication plugins will be ported to glib, this is already done for sasl, and work has started on oauth)

Of course we’re open to discussions and clearing up of any misunderstandings and such.

That’s a bad start. I think think GOA is better because it was created first. That’s non-sense.

GOA doesn’t offer enough services. I can setup my facebook, google, and windows live accounts, but accounts like AIM I have to go through a totally different UI (empathy). This would’t be so bad if these two cooperated, but I found that if I have some accounts set up in GOA (facebook, google, WL), and some set up in empathy (AIM), on a cold boot when I first open empathy the GOA accounts sign in fine, but AIM refuses to sign in until I toggle it on/off. If I set them all up directly through empathy this problem does not occur. In addition when I resume my machine from suspend the opposite happens: Aim signs on fine, the GOA accounts absolutely refuse to sign on until I kill telepathy. I saw these issues in both fedora and arch. With UOA I can set up all my accounts in one place, and experience none of the above “game-breaking” issues.

Each of the shells is developed in its own little world with not much thought about 3rd party app developers, or in many cases even the users. An app developer shouldn’t have to special-case each desktop API as that adds to development cost and therefore makes desktop Linux a less attractive target platform. As for users, why would a KDE user expect a KDE app to behave any differently than a Gnome app? What possible justification is there for users to care?

The problem seems reducable to the fact that there’s no uniform shell API for Linux desktops. FreeDesktop.org was a start but it’s largely stopped covering new ground (i.e. online accounts.) The good news is a third party could create a uniform shell API on their own, the bad news is the amount of work involved. That said, I wish someone would take this on.

When KDE people complained that they should not use Telepathy, GStreamer or Folks because it’s written in GObject we argued that was stupid and that code sharing is the best for both projects. We should stay coherent and stick with the same logic here.

When I said Files, I had this in mind: https://live.gnome.org/ThreePointSeven/Features/Owncloud

Having said that, there is a fundamental problem that makes it difficult to support something like Google Drive (or earlier Google Documents) in Files. This is because Google Drive being a database driven store does not fit in very well with the abstraction of Gvfs, which is heavily used by Files. So writing a Gvfs backend for such a service becomes tricky. I do remember a Gvfs backend for Google Documents floating around somewhere. Don’t remember what the state of it is.

However, SkyDrive looks a lot closer to the Gvfs model. Therefore, it should be the first target for integration in Files. One would have to write a Gvfs backend using libzapojit for that.