Visiting chrome://signin-internals gives similar RED lines with "	Failure: Invalid credentials (1)" errors to issue 852021.

This profile was correctly logged into sync though, and transitioned to this red state without any interaction from me. I did not logout.

Something seems very wrong here if slowly all my profiles are being logged out of sync - and even if they are being logged out because of a bug, the certainly think that the modal dialog should definitely not be displaying.

From your description, it is clear that Chrome is in an auth error state (as explained in issue 852021, the refresh token is invalid). 

The dialog in comment #1 is the re-auth dialog that is shown when the user attempts to fix the sign-in error (user selects "Sign in again" from settings or from the user menu).

Chrome is not supposed to show this dialog without user action, except if an extension uses the chrome.identity API and requests an access token for an account that is an auth error state.
wfh@: May I ask you to open chrome://extensions, disable all of them and see if you can reproduce this issue?

I did not select "sign in again" from the settings menu, this appeared spontaneously.

The dialog hasn't appeared again, so I'm not sure how I would test disabling extensions and getting it to appear...?

as a data point, it just appeared again, and I was using Chrome Remote Desktop - so perhaps that is asking for signin?

I don't think that we should be enforcing people to sign into Chrome to use an extension like Chrome Remote Desktop.

If you look at https://developer.chrome.com/apps/identity#method-getAuthToken , the extension has the choice whether to present the authorization UI or fail if the user is not signed in (see the interactive argument). My understanding is that this was by design when the API was introduced. The reason would be that we do want the extension to be able to pup-up a sign-in dialog in the right context (user interacts with the extension, extension was just installed, Chrome is started etc.). I doubt that my team has time to re-visit this API decision in the near future.

Chrome Remove Desktop requires authentication and it my tests it uses the chrome.identity API for authentication. This in turn requires the user to be signed in to Chrome (just tested it and if I am not signed in to Chrome, then the extension opens the Chrome sign-in screen).

I just tested and confirmed on a non-signed in Chrome, installing Chrome Remote desktop you end up on the "sign in to Chrome" screen. This is certainly not the thing we want to do be doing, which is forcing users to sign into *SYNC* instead of just signing into Chrome to get the oauth token required to use Chrome Remote Desktop.

Why does Chrome Remote Desktop require that users are signed into sync?

once DICE is on, we only would do GAIA sign-in in this case, i.e., not sync, correct?

should I file a separate bug specific to Chrome Remote Desktop, or is this bug best?

This is the way the chrome.identity API has worked for the last 4 years. This API requires the user to be signed in to Chrome (so yes, signed in for sync).

Jochen: We did not change this with DICE, but we could look at it if we believe that is important.

do you know whether there are users of this API that actually need sync?

They do not need sync.

i guess i'd vote for dropping the sync part then.

I don't think this is a bug in Chromoting, just something that affects it.

FWIW, this is related to  Issue 731066 . We knew that we could improve the chrome.identity extensions API once we launched Dice (to have access to all the signed-in accounts, whether or not they're syncing), we just haven't had time to do so. To Mihai's point, this isn't a regression; this is how the extension API has worked for years.

I don't think we're going to have time to address this in the near-term with how swamped the eng team is with upcoming projects. I'm going to mark this bug as Available to make it clear that we don't plan to address this in the short-term.

 Issue 258515  has been merged into this issue.

Ok, the code is fairly trivial and we should have it ready quickly. The main potential issue that I could see is how to land this change without breaking the existing users of the chrome.identity API that may expect that chrome.identity.getAuthToken only returns an account when they are syncing.

Note that that the description in https://developer.chrome.com/apps/identity#method-getAuthTokeno does cater for this change though.

Jochen: Do you think we need to go through a finch rollout for this feature (basically do we need a launch bug for this)?

 Issue 731066  has been merged into this issue.

David is working on this bug.

The heavy lifting has been landed behind a feature flag. There are still a couple things to do:
1. Signing into an extension should simply add the account to the Chrome (currently it also set it as the sync account, but this is no longer necessary with dice)
2. Actually enable the feature. Most likely a Finch rollout.

Removing the M71 flag, the implementation is actually harder than expected, and probably needs support from Gaia. I'll start a design doc.