Online Accounts authorization on desktop (unity7) is confusing

Bug #1522360 reported by Alberto Mardegan on 2015-12-03
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
unity-control-center (Ubuntu)
Medium
Unassigned

Bug Description

Unlike the phone (unity8) interface, in the desktop (unity7) when a Google account is created in "System Settings" -> "Online Accounts", all applications which can use it get automatically enabled.
Some of these applications, such as Shotwell, have their own UI and use the account only when the user is actively using them, while others (such as Empathy and Evolution) provide background services which start synchronizing the user calendar or contacts as soon as the account is created, but without showing any UI on screen.

Now, the problem is that the first time that these processes start using the newly created account, they need to be authorized by the user: this is not something that we can control, as it's a requirement from the remote server (Google's, in this example). This means that until we show a UI containing the Google's authorization page, these application won't work. The solution we implemented (and that we are currently using) is that when these applications try to authenticate, we refuse their request and instead emit an OSD notification, saying

        Applications can no longer access your Google Online Account
           Choose <b>Online Accounts</b> from the user
           menu to reinstate access to this account.

If the user is clever enough, he'll open "System Settings" -> "Online Accounts" and after clicking on the Google account they'll be prompted to authorize the applications that previously requested access to it. Until the user has done that, these applications won't be able to interact with the account.

Some users (actually, Canonical developers) have been left confused by this message, thinking that it was the symptom of an error that had to be fixed.

I would like to propose a couple of simple suggestions to fix this bug:
1) Reword the notification message a bit, maybe by saying "Some applications cannot access..." (note that I removed "no longer")
2) Some releases ago, the system settings indicator on the top right corner of the screen would become red in this situation, and also the "Online Accounts" menu item inside that menu would appear in red: that helped a lot our users in finding their way. However, this no longer happens.

Changed in ubuntu-ux:
status: New → Triaged
assignee: nobody → Matthew Paul Thomas (mpt)
importance: Undecided → Medium
Matthew Paul Thomas (mpt) wrote :

"the first time that these processes start using the newly created account, they need to be authorized by the user: this is not something that we can control, as it's a requirement from the remote server"

Is this true on the phone as well? If not, how does the phone avoid this? And if so, the phone Online Accounts design needs changing too.

"Choose <b>Online Accounts</b> from the user menu to reinstate access to this account"

Consider the huge variety of ways people can fail at this task. They might:
* Not see the notification bubble before it disappears.
* Not see anything that looks like a "user menu", since there is no such thing. The user menu hasn't existed since Ubuntu 12.04. (And even then, it wasn't referred to by name anywhere except Ubuntu's help pages.)
* Choose the wrong menu item inside the menu by mistake.
* Get bored and switch to some other app before System Settings opens.
* Close or minimize System Settings by mistake.
* Navigate to a different System Settings panel by mistake.
* Fail to find the account in the list, especially if they have many accounts.
* Choose the wrong account by accident, especially if they have more than one account of the same type.
And so on.

The general design guideline: Don't tell me how to do something if it won't make me faster later. Instead, Just Do It, or else give me a button to do it.

In this case we can't Just Do It. So, we should provide a button to do it. What should that button look like? We're allowing the service to access a particular account, so let's label the button "Allow". To make the alternative obvious, we should have another button for that, "Don't Allow". And of course we should identify the service and the account it wants to access, so let's use text for that, above the two buttons.

By now this should be sounding very familiar ... It's the standard Online Accounts dialog! The only difference here is that we have to show the Web UI afterwards, so "Allow" should be "Allow…". That's all.

Now, I guess you're going to tell me that reimplementing that in Unity 7 would be far too invasive. If so, let me know how much you're comfortable implementing, and we'll see how close we can get.

Changed in ubuntu-ux:
status: Triaged → In Progress
affects: ubuntu-ux → unity-control-center (Ubuntu)

On 04.01.2016 20:59, Matthew Paul Thomas wrote:
> "the first time that these processes start using the newly created
> account, they need to be authorized by the user: this is not something
> that we can control, as it's a requirement from the remote server"
>
> Is this true on the phone as well? If not, how does the phone avoid
> this? And if so, the phone Online Accounts design needs changing too.

It is true on the phone as well: Once the user clicks on our "Allow"
button on the phone, we only authorize the application to use the Online
Account data which we have locally, but then when the application
actually uses this account's data on the remote server, the remote
server might want to send the user through a web-based authorization.
Usually this happens on the very first time the user wants to use this
application on his account: that is, if the account gets deleted locally
and then the user performs the same steps again, he generally won't be
asked to reauthorize the app, because the authorization is remembered by
the remote server (though, that's totally up to the remote server:
Google and Facebook generally remember the apps, but other services don't).

When this happens on the phone, most of the times these authorization
requests are initiated when the requesting app is running on the
foreground, so we simply show the "trusted session" UI on top of the
app, containing the webview with the remote service's autorization page.
This is usually not a disruption of the user's activity because it
typically happens after the user has explicitly asked the application to
perform some action.

I'd say that the problem only involves those system services which run
on the background; these are much more common on the desktop than on the
phone, but indeed the issue is not limited to the desktop only. See for
example bug 1507540.

[...]
> In this case we can't Just Do It. So, we should provide a button to do
> it. What should that button look like? We're allowing the service to
> access a particular account, so let's label the button "Allow". To make
> the alternative obvious, we should have another button for that, "Don't
> Allow". And of course we should identify the service and the account it
> wants to access, so let's use text for that, above the two buttons.
>
> By now this should be sounding very familiar ... It's the standard
> Online Accounts dialog! The only difference here is that we have to show
> the Web UI afterwards, so "Allow" should be "Allow…". That's all.
>
> Now, I guess you're going to tell me that reimplementing that in Unity 7
> would be far too invasive. If so, let me know how much you're
> comfortable implementing, and we'll see how close we can get.

As I explained above, the problem is different: this is about notifying
the user that an application *other than the active one* (so, it could
be a system service or an unfocused app) needs his attention. I don't
think we want to popup a dialog in that case.

Matthew Paul Thomas (mpt) wrote :

So bug 1507540 is basically the Ubuntu Touch equivalent of this bug? At least, it's unlikely that the design for that particular case will be different from the general design for (re)authorization.

Anyway, for the reasons I gave, I think it would be risky (and even aggravating) to present this in any way that doesn't have a button for fixing the problem directly. You make a good point that it's often going to be an app/service that isn't the focused app. But we have a long-standing mechanism for dealing with dialogs that don't belong to the focused app: focus-stealing prevention.

So my proposal is:
1. A dialog comes up saying “XYZ needs reauthorizing to access your {whatever} account”. Compiz decides whether it gets focus or not. If not, it sits in the launcher+switcher waiting for you.
2. If you choose "Continue…", that dialog closes and a new dialog appears containing the Web frame and a "Cancel" button.

Is that amount of change acceptable for Unity 7?

Alberto Mardegan (mardy) wrote :

On 12.01.2016 17:16, Matthew Paul Thomas wrote:
[...]
> fixing the problem directly. You make a good point that it's often going
> to be an app/service that isn't the focused app. But we have a long-
> standing mechanism for dealing with dialogs that don't belong to the
> focused app: focus-stealing prevention.

Do we have it? Even if such a thing is implemented, it looks like it's
working very poorly: I'm often disturbed by dialogs popping up out of
nowhere (apport and Thunderbird being the biggest offenders).

> So my proposal is:
> 1. A dialog comes up saying “XYZ needs reauthorizing to access your {whatever} account”. Compiz decides whether it gets focus or not. If not, it sits in the launcher+switcher waiting for you.
> 2. If you choose "Continue…", that dialog closes and a new dialog appears containing the Web frame and a "Cancel" button.
>
> Is that amount of change acceptable for Unity 7?

It can be done in time for the LTS, I believe. But before starting
implementing the changes, I'd like to be sure that the result is better
than what we currently have.
Do you have any references to how Compiz treats new windows?

Matthew Paul Thomas (mpt) wrote :

Here's a rough draft of the dialog and adjusted flow: the "PC version" dialog is the one relevant to Unity 7.

Focus stealing prevention isn't quite as reliable in Compiz as it is in other OSes, but yes, we do have it. Sam Spilsbury has written a summary of how it works. <https://www.reddit.com/r/Ubuntu/comments/y4w2m/why_compiz_fails_to_prevent_new_windows_from/c5t2ux7> Past bugs might have caused you to twiddle with Compiz settings in the past and later forget about it, leading to more false negatives than usual now. Or maybe you're one of those experiencing the so-far-undebugged bug 455241.

Matthew Paul Thomas (mpt) wrote :

Specification updated with a new flow diagram. <https://wiki.ubuntu.com/OnlineAccounts?action=diff&rev2=27&rev1=26>

I'm not sure I have it right yet, though. What if you set up two accounts of the same type, but you want an app to be authorized for only one of them? For example, if you add personal and work Google Accounts on your work PC so that you can see both their calendars, but you want to access only work e-mail.

Changed in unity-control-center (Ubuntu):
assignee: Matthew Paul Thomas (mpt) → nobody
status: In Progress → Triaged
Alberto Mardegan (mardy) wrote :

When an app wants to use an account, it first needs to be authorized by the user. This is an offline operation, which happens locally on the user's device. It's handled by dialogs in the second column of

  https://wiki.ubuntu.com/OnlineAccounts?action=AttachFile&do=get&target=online-accounts-flow-extended.png

(note that the dialog at the bottom, is the dialog that handles the account creation, essentially the same that the user would see if he created the account from System Settings -> Online Accounts: the only difference is that once the account creation completes successfully, the application is added to the whitelist of apps which can use the account -- again, it's just a local operation)

As soon as the application is granted the permission to use an account, typically it will try to get its password or authentication token; when dealing with OAuth, most of the times the very first time that this happens the remote server will run its own checks and require us to show a webview to the user, asking an additional confirmation (after which, the server remembers that this app has been authorized to use the account, and will return us an access token, which is specific to that app.

Now, access tokens do expire. It can be a matter of hours, but most typically it's months or even years. When that happens, we need to show the remote server's contents in a webview and the user will have to renew the authorization.

The dialogs you added on the right column cover exactly this case: it's when an app which is *already locally authorised* to use an account finds out that the access token is no longer valid (or password, if the user has changed it on the remote server -- think of UbuntuOne, which is not OAuth based).

I think that your design covers the needed cases, but I belive that the "Allow" and "Do not allow" buttons you have on the third column are misnamed: I would rename "Allow" to something like "Renew authentication". As for the "do not allow", I would either remove it completely or (better) rename it do "revoke authorization": it's effectly about *locally* toggle the "enabled" flag for the requesting application, so that it will stop ever trying using this account (and if the user opens the account in the System Settings, he'll see that the app is now disabled).

Khurshid Alam (khurshid-alam) wrote :

Is there any progress on this? Even after grant access twice I can not access google contacts in Evolution (16.04, 16.10). How does it work actually? I have to install and use gnome-control-center to make it work.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers