Online Accounts

Operating system provided online accounts service.

Background

GNOME Online Accounts has been with us for a while now, and has provided useful function during that time. However, several developments mean that now is a good time to evaluate what we have as well as other potential approaches. Reasons for this:

Flatpak, and application sandboxing - potentially limits which apps can use online accounts, but also offers the opportunity to improve the privacy situation
Increasing recognition that we need to manage GNOME's API keys better
Desire to provide clarity for application developers who might want to use the service
Increasing recognition that GNOME needs to better define which apps are part of the project
Changing composition of the core GNOME app suite, and the need to manage change better as apps are added and removed

Obviously, these factors relate to both the technical architecture of Online Accounts as well as wider-project management issues.

Potential Goals

The following are expected to evolve as this initiative develops.

Make online accounts and cloud integration a main part of the GNOME 3 experience (as opposed to local data and storage)
Reduce the need for users to sign into the same service multiple times
Protect user privacy, by having effective controls over which apps can access their online accounts
Make it clear to users what accounts will be used for, and what the value is in adding them; avoid situations where someone adds an account and is uncertain what it does or how the integration works
Provide effective design patterns for applications which integrate online accounts
Provide useful user-facing functionality in relation to online accounts (example: share an image to Facebook)
Make it easier for app developers to integrate online accounts into their apps

Potential Constraints

API keys must be used in accordance with service-provider terms and conditions; in particular this means no "umbrella accounts"

Relevant Art

Research should focus on the architecture and basic interaction model of each service, rather than just looking at UI.

Mac

Windows

iOS

Android

GNOME 3.30

Discussion

In the past, the design focus has been on initial setup and settings as the main places that users interact with online accounts. However, in more recent years there has been an interest in pushing online account setup and status into the apps themselves, since this offers a more immediate and direct experience. Example: prompting a user to setup an account when they run Contacts for the first time. It would be interesting to explore this further - to see if there's a way to setup or modify an account without ever needing to leave an app.

Key questions:

Does it make sense to allow apps to provide their own API keys?
With Flatpak it's possible to have new versions of apps on an old version of the host - do we need to do anything to ensure compatibility?
- Does it ever make sense to have an old version of Online Accounts, anyway? (Considering that online services change all the time.) Does there need to be a way to update old versions, or flag old versions when we know particular services will no longer work?
In the past, Online Accounts presented users with a list of content types for each account - Mail, Contacts, Files, etc. Are those the most interesting things to present? Do we want to show which apps are authorised to use an account, instead?

Flatpak and sandboxing

Online accounts aren't available from inside an application sandbox: it requires breaking a hole in the sandbox to access them. In the future we want to avoid this from being necessary.

TODO: what are the options?