Accounts added through GNOME Online Accounts are meant to be used by core operating system components. Some of these components are operating system services running in the background, while others are applications necessary for a minimum viable product.
Examples of OS services:
Calendar events in GNOME Shell exposed by Evolution Data Server
Kerberos credentials configured via the usual krb5 mechanisms
Examples of core applications:
Note that, while third-party applications can access the accounts setup through GNOME Online Accounts today, it may change in future.
Accounts offered through GNOME Online Accounts should appeal to a wide range of users.
By default, GNOME Online Accounts includes a set of account types that are necessary for the recommended upstream user experience. Downstream distributors can add or remove account types to and from the default set using build-time options.
This section explains the requirements listed above.
Establish specific contracts of trust
Various online providers require clients to identity themselves via a user-agent. This is often encoded in the OAuth2 access token issued by the provider, which is used to access the remote service. It is an explicit goal to restrict the amount of code that can identify itself as GNOME.
Having third-party applications identity themselves as GNOME would be misleading as to what is actually accessing the account. It will prevent there from being specific contracts of trust between users and applications who access their data.
Shield GNOME from bugs in third-party code
Service providers flag erratic client behaviour, either arising out of honest bugs or malicious intent, that can endanger users. It could be attempts to flood the service with a massive number of API calls that may lead to a denial-of-service attack, or leaking information that can impact the user's privacy. Any punitive action by a provider will affect all components across all users using the GNOME identity, which is a very serious outcome.
We need to do our best to prevent such occurrences by regularly testing and reviewing the components that use the GNOME identity. If the GNOME identity isn't restricted to a pre-determined set of components, there won't any way to know the body of code that GNOME is accountable for.
Isolate one third-party from another
Restricting the identity to a smaller group also shields unrelated software components from each other. A bug in GNOME won't affect a third-party application, or one third-party application won't be taken down due to the acts of another.
Avoid being a kitchen sink
Accounts offered through GNOME Online Accounts are prominently placed in Settings. Each and every user looking to connect their systems to their accounts has to sift through the list of entries in the Online Accounts panel. Having very domain-specific and niche account types adds noise to the user experience for the majority of users.
Adding new account types
As mentioned above, accounts added through GNOME Online Accounts are meant to be used by core operating system components and should appeal to a wide range of users. Therefore, the following questions need to be answered:
- Is there an operating system service or a core application which is going to consume with the proposed account type?
- How widely is this account type going to be used by the target audience?