API keys are now required to sign in to Google (e.g. gmail) in the content area

[Mihai Sardarescu]

Hi follow Chromies,

A couple of weeks ago I have landed the CL 1044210 that has enabled the milestone 2 of the Desktop Identity Consistency on developer builds. Starting with this CL, Chromium retrieves a refresh token for every Google account when the user signs in to Google in the content area.

The side effect of this change is that API keys are now required for Chromium developer builds in order to sign in to Google in the content area (e.g. signing in to gmail). Instructions on how to configure your API Keys can be found at https://www.chromium.org/developers/how-tos/api-keys 

Cheers,

- Mihai

[PhistucK]

This sounds like a pretty bad decision... A lot of people use Chromium for testing (or for sort of everyday use as an open source browser) and that is a major obstable in usablility.

Can it simply be disabled if there are no API keys instead?

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEPrgOP6jT9zGdqKaBhvDhqU6OxvFyBKZHb_yE0ZHfxtuX6BBw%40mail.gmail.com.

[Matthew Menke]

+1 to this.  As someone who works both on-and-off corp, this seems developer hostile, and actively discourages me from working off corp in certain areas.  As a user who sees no benefits from signing into Chrome (But would perhaps see modestly increased network use as a result), this doesn't seem too user-friendly, either.

[Avi Drissman]

As someone who works with the embedder community and the content layer, I'll echo those concerns, but am curious how this happens. The content/ layer is involved in standard web content, and Desktop Identity Consistency is a chrome/ level feature. How does Desktop Identity Consistency interfere with the ability of content/ to sign into a site?

Avi 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/8e52994c-cab9-434b-86bc-1b9bd3026afc%40chromium.org.

[Sylvain Defresne]

AFAICT, the interception happens in ChromeResourceDispatcherHostDelegate, so this should not affect other embedders nor content/.

-- Sylvain

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACWgwAZREjytwv9NGSeccR%2BzaTQHpz8adoRmfxBnO8%3Dhmxbc3g%40mail.gmail.com.

[Mihai Sardarescu]

Hi,

1. Desktop Identity Consistency is a browser-level feature with code in //components/signin and //chrome. Browsers that embed only //content will not be affected. Browser that only take part of the Chromium code will also probably not be affected.

2. Desktop Identity Consistency relies on a special protocol with Google Auth service that requires the API keys to be configured in order to sign in. We discussed extensively whether to disable the Desktop Identity Consistency feature if the API keys are missing on the client. The decision was to enable Desktop Identity Consistency for all developer builds for the following reasons:

* To avoid the cases when a developer would have different usages and behaviors depending on whether the API keys were configured.

* To avoid having to maintain long-term 2 different codepaths (Desktop Identity Consistency enabled and disabled), that have different UIs etc.

* Adding the API keys is a one-off configuration.

- Mihai

[PhistucK]

A one off configuration that requires subscribing to chromium-dev (many inadvertently subscribe with e-mails and start to complain) and going through the unintuitive API console wizard, as well as messing with environmental variables. I would not be surprised if you got many bug reports (that may never stop) about "Chromium not signing into Google anymore". It is hostile for an open source project of a browser to choose what it logs into and not based on web API capabilities.

:(

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/7303521a-46b4-43a2-a702-f84b3001835a%40chromium.org.

[Daniel Bratell]

Yes, I think it will have to have a better fallback than just not working, and it scares me that it comes very close to a setup where Google server developers might start assuming that Chromium based browsers will have access to this proprietary login method.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABc02_%2BjN3Gn4A4Er0An77LNWNX-UrT12iAbGSKxzcqazx1%3DyA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Adam Rice]

* To avoid having to maintain long-term 2 different codepaths (Desktop Identity Consistency enabled and disabled), that have different UIs etc.

But we need the other code path for incognito mode, anyway.

 

* Adding the API keys is a one-off configuration.

As someone who has created ephemeral Chrome checkouts before now, I can say that adding the API keys is a significant additional burden. 

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

[Michael Giuffrida]

On Tue, May 29, 2018, 8:31 AM Mihai Sardarescu <msa...@chromium.org> wrote:

Hi,

1. Desktop Identity Consistency is a browser-level feature with code in //components/signin and //chrome. Browsers that embed only //content will not be affected. Browser that only take part of the Chromium code will also probably not be affected.

2. Desktop Identity Consistency relies on a special protocol with Google Auth service that requires the API keys to be configured in order to sign in. We discussed extensively whether to disable the Desktop Identity Consistency feature if the API keys are missing on the client. The decision was to enable Desktop Identity Consistency for all developer builds for the following reasons:

* To avoid the cases when a developer would have different usages and behaviors depending on whether the API keys were configured.

Isn't your change causing *exactly* this scenario? Different behavior depending on whether API keys are available?

* To avoid having to maintain long-term 2 different codepaths (Desktop Identity Consistency enabled and disabled), that have different UIs etc.

How would disabling "identity consistency" (super orwellian name btw) cause a "different UI" to have to be maintained? //content will always be perfectly capable of displaying a sign-in form, right?

* Adding the API keys is a one-off configuration.

- Mihai

On Tuesday, May 29, 2018 at 4:09:06 PM UTC+2, Mihai Sardarescu wrote:

Hi follow Chromies,

A couple of weeks ago I have landed the CL 1044210 that has enabled the milestone 2 of the Desktop Identity Consistency on developer builds. Starting with this CL, Chromium retrieves a refresh token for every Google account when the user signs in to Google in the content area.

The side effect of this change is that API keys are now required for Chromium developer builds in order to sign in to Google in the content area (e.g. signing in to gmail). Instructions on how to configure your API Keys can be found at https://www.chromium.org/developers/how-tos/api-keys 

Cheers,

- Mihai

[Mihai Sardarescu]

On Wed, May 30, 2018 at 12:43 PM Michael Giuffrida <mich...@chromium.org> wrote:

On Tue, May 29, 2018, 8:31 AM Mihai Sardarescu <msa...@chromium.org> wrote:

Hi,

1. Desktop Identity Consistency is a browser-level feature with code in //components/signin and //chrome. Browsers that embed only //content will not be affected. Browser that only take part of the Chromium code will also probably not be affected.

2. Desktop Identity Consistency relies on a special protocol with Google Auth service that requires the API keys to be configured in order to sign in. We discussed extensively whether to disable the Desktop Identity Consistency feature if the API keys are missing on the client. The decision was to enable Desktop Identity Consistency for all developer builds for the following reasons:

* To avoid the cases when a developer would have different usages and behaviors depending on whether the API keys were configured.

Isn't your change causing *exactly* this scenario? Different behavior depending on whether API keys are available?

Not in Chromium. The Chromium code will be the same with or without API keys. The difference is the server that always expects a client ID to be present for request comming from Chrome with Desktop Identity consistency. 

* To avoid having to maintain long-term 2 different codepaths (Desktop Identity Consistency enabled and disabled), that have different UIs etc.

How would disabling "identity consistency" (super orwellian name btw) cause a "different UI" to have to be maintained? //content will always be perfectly capable of displaying a sign-in form, right?

//content is the same, but Chromium UI is more than content. For example the Desktop Identity Consistency affects the Chromium settings, the various sign-in to Chrome promos, the welcome screen etc.

- Mihai

[Alexei Svitkine]

On Wed, May 30, 2018, 7:12 AM Mihai Sardarescu <msa...@chromium.org> wrote:

On Wed, May 30, 2018 at 12:43 PM Michael Giuffrida <mich...@chromium.org> wrote:

On Tue, May 29, 2018, 8:31 AM Mihai Sardarescu <msa...@chromium.org> wrote:

Hi,

1. Desktop Identity Consistency is a browser-level feature with code in //components/signin and //chrome. Browsers that embed only //content will not be affected. Browser that only take part of the Chromium code will also probably not be affected.

2. Desktop Identity Consistency relies on a special protocol with Google Auth service that requires the API keys to be configured in order to sign in. We discussed extensively whether to disable the Desktop Identity Consistency feature if the API keys are missing on the client. The decision was to enable Desktop Identity Consistency for all developer builds for the following reasons:

* To avoid the cases when a developer would have different usages and behaviors depending on whether the API keys were configured.

Isn't your change causing *exactly* this scenario? Different behavior depending on whether API keys are available?

Not in Chromium. The Chromium code will be the same with or without API keys. The difference is the server that always expects a client ID to be present for request comming from Chrome with Desktop Identity consistency. 

Presumably the server code should still support other browsers being able to sign in? If so, can't it treat Chromium without API keys same as it treats other browsers?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEPrgOPFX22r24fhDeUhOxMAZ%3DOn8Deg-Z33sZ6MVgj%2B9sZewA%40mail.gmail.com.

[Mihai Sardarescu]

Jochen just made me realize that I remembered wrong my own CL (that's what happens when I send an email out 3 weeks later without re-reading the code).

So, if you’re not using API keys, nothing will change for (you will still be able to sign in to Google web). What changes is that if you want to test any of the API key protected features in chromium, the Google web sign-in flow will also use the API key to generate an OAuth refresh token.

Note that there’s no difference whether you do this on Google corp or not. It also doesn’t change the interaction with any other Google servers, in fact, this is similar to the sign-in model that Chrome on Android has been using for the last several years.

If getting API keys, or setting them up for a checkout is unnecessarily difficult, please raise this as a separate issue.

Sorry for the confusion,

- Mihai

On Tuesday, May 29, 2018 at 4:09:06 PM UTC+2, Mihai Sardarescu wrote:

[Harald Alvestrand]

I think this is what bit me a week or two back, when I built Chromium without API keys and tried to go to hangouts.google.com. The error message was ..... confusing; I never got to the sign-in flow.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/86b0e3d1-c8d6-4e28-be2f-c08f82dc690e%40chromium.org.

[Jochen Eisinger]

+ew...@chromium.org 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/86b0e3d1-c8d6-4e28-be2f-c08f82dc690e%40chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAOqqYVFmasCE4vSsV06R4sq3snAOTKio_Cm1EHA1The3MtE__w%40mail.gmail.com.