Google to block sign-ins from Chromium embedders

[Marshall Greenblatt]

Hi John,

According to [1] Google is planning to block sign-ins from CEF (and presumably Electron) starting in June. This will be a substantial problem for many Chromium embedders who use the project as a “normal” web browser similar to other Chromium-based browsers like Opera and Microsoft. From the announcement it’s unclear how this embedder block can be implemented without also blocking other Chromium-based browsers. Also, presumably, Google will not be blocking sign-in from Mozilla or other “less secure” browsers that are not based on Chromium.

Can you provide more details on this restriction and what, specifically, we should expect from the technical implementation?

And, finally, I would request that in the future you reach out to the embedder community before making these types of public announcements so that we can fully understand the issue and properly communicate it to our users before they see it as scary news headlines.

Thanks,

Marshall 

[1] https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+GoogleOnlineSecurityBlog+(Google+Online+Security+Blog)&m=1

[Avi Drissman]

This wasn't a Chrome decision; this is a change from the Google signin team.

Let me see if I can hunt down someone who is on that team so that you can have a discussion with them.

Avi

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To post to this group, send email to embedd...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/F74EC822-6026-4A61-83EA-7D758DECAD9F%40gmail.com.

[jer...@chromium.org]

It would also be great to know how this is detected, and whether there's anything that CEF/Electron could do differently that would make the signin team comfortable with re-enabling it.

Which is to say, please include me in that conversation :)

On Friday, April 19, 2019 at 7:06:42 AM UTC-7, Avi Drissman wrote:

This wasn't a Chrome decision; this is a change from the Google signin team.

Let me see if I can hunt down someone who is on that team so that you can have a discussion with them.

Avi

On Fri, Apr 19, 2019 at 10:00 AM Marshall Greenblatt <magree...@gmail.com> wrote:

Hi John,

According to [1] Google is planning to block sign-ins from CEF (and presumably Electron) starting in June. This will be a substantial problem for many Chromium embedders who use the project as a “normal” web browser similar to other Chromium-based browsers like Opera and Microsoft. From the announcement it’s unclear how this embedder block can be implemented without also blocking other Chromium-based browsers. Also, presumably, Google will not be blocking sign-in from Mozilla or other “less secure” browsers that are not based on Chromium.

Can you provide more details on this restriction and what, specifically, we should expect from the technical implementation?

And, finally, I would request that in the future you reach out to the embedder community before making these types of public announcements so that we can fully understand the issue and properly communicate it to our users before they see it as scary news headlines.

Thanks,

Marshall 

[1] https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+GoogleOnlineSecurityBlog+(Google+Online+Security+Blog)&m=1

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

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

[Daniel Bratell]

While CEF was specifically named in the blog post, I also don't know how it is different from any other Chromium based product (like Opera). Is this going to be controlled by the API key or similar?

/Daniel

On Fri, 19 Apr 2019 18:07:44 +0200, <jer...@chromium.org> wrote:

It would also be great to know how this is detected, and whether there's anything that CEF/Electron could do differently that would make the signin team comfortable with re-enabling it.

Which is to say, please include me in that conversation :)

On Friday, April 19, 2019 at 7:06:42 AM UTC-7, Avi Drissman wrote:

This wasn't a Chrome decision; this is a change from the Google signin team.

Let me see if I can hunt down someone who is on that team so that you can have a discussion with them.

Avi

On Fri, Apr 19, 2019 at 10:00 AM Marshall Greenblatt <magree...@gmail.com> wrote:

Hi John,

According to [1] Google is planning to block sign-ins from CEF (and presumably Electron) starting in June. This will be a substantial problem for many Chromium embedders who use the project as a “normal” web browser similar to other Chromium-based browsers like Opera and Microsoft. From the announcement it’s unclear how this embedder block can be implemented without also blocking other Chromium-based browsers. Also, presumably, Google will not be blocking sign-in from Mozilla or other “less secure” browsers that are not based on Chromium.

Can you provide more details on this restriction and what, specifically, we should expect from the technical implementation?

And, finally, I would request that in the future you reach out to the embedder community before making these types of public announcements so that we can fully understand the issue and properly communicate it to our users before they see it as scary news headlines.

Thanks,

Marshall 

[1] https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+GoogleOnlineSecurityBlog+(Google+Online+Security+Blog)&m=1

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

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

To post to this group, send email to embedd...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/F74EC822-6026-4A61-83EA-7D758DECAD9F%40gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

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

To post to this group, send email to embedd...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/0d27c900-a949-455e-8f7e-d097a708b7be%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Salvador Díaz Fau]

Hi,

I just wanted to add some more information about the consequences of this change in the Google authentication procedure. 

This change will not only affect all projects based directly on CEF but also all the projects based on CEF wrappers for other languages like CEFSharp, CEFPython,  JavaCEF, CEF4Delphi, CEFGlue, FPCef, etc. 

I don't have the actual figures of the amount of applications using CEF directly or using any of its wrappers but I do know that it's a really popular project. 

I'm mentioning all this because I'm the maintainer of one of those wrappers called CEF4Delphi and the developers using CEF4Delphi are really worried about this change because it breaks their applications.

One of those affected applications is a full web browser called BriskBard that I developed using CEF4Delphi. BriskBard is a humble web browser with a limited user base but this change affects many of its users.

Please, provide all the details you can about this change and possible ways to adapt a full web browser to the new authentication procedure without using external browsers.

Thanks,
Salvador Diaz Fau

[Avi Drissman]

Ok. Slight delay due to one of the involved people being sick yesterday.

The relevant people will all be in next week, so we're thinking about that time frame. In terms of keeping attendance manageable, I'm thinking Marshall re CEF, Jacob re Electron, Daniel re Opera to cover the main perspectives here.

I'm hammering this email on a phone while on a plane, so I can't work more on scheduling. I'll reach out individually tomorrow to figure out logistics, but I wanted to make sure I wasn't silent. 

Avi

On Tue, Apr 23, 2019 at 4:06 PM Avi Drissman <a...@google.com> wrote:

Thank you for your feedback and concerns. I'm in touch internally with the team who made this announcement and hope to be able to have something to say soon.

Avi

--

You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To post to this group, send email to embedd...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/975ff1b2-157a-453a-84c2-0f1dfcf39974%40chromium.org.

[Avi Drissman]

Thank you for your feedback and concerns. I'm in touch internally with the team who made this announcement and hope to be able to have something to say soon.

Avi

On Tue, Apr 23, 2019 at 3:01 PM Salvador Díaz Fau <bris...@gmail.com> wrote:

--

[Avi Drissman]

I have been in touch with the team who's working on this. Gears are turning and the plan is to have some things to share in a day or two.

My apologies for the delay. Please stay tuned.

Avi

On Fri, Apr 26, 2019 at 1:10 PM Ross W <ro...@sketchup.com> wrote:

We would love to get more information on how this is going to be implemented.

Within the SketchUp 3D modeler, we depend on CEF, and around half of our millions of users use Google sign-in when logging into our desktop clients.

We're worried that kicking our users into the system browser to complete login will be disruptive and alarming. We're also worried about hosting a web server on each user's machine to complete login. We imagine hitting firewall issues, and lots of other problems on corporate networks. We'd love to know if there's any way we can get an exception to this policy.

Thanks for any information.

On Tuesday, April 23, 2019 at 7:54:47 AM UTC-6, Daniel Bratell wrote:

While CEF was specifically named in the blog post, I also don't know how it is different from any other Chromium based product (like Opera). Is this going to be controlled by the API key or similar?

/Daniel

On Fri, 19 Apr 2019 18:07:44 +0200, <jer...@chromium.org> wrote:

It would also be great to know how this is detected, and whether there's anything that CEF/Electron could do differently that would make the signin team comfortable with re-enabling it.

Which is to say, please include me in that conversation :)

On Friday, April 19, 2019 at 7:06:42 AM UTC-7, Avi Drissman wrote:

This wasn't a Chrome decision; this is a change from the Google signin team.

Let me see if I can hunt down someone who is on that team so that you can have a discussion with them.

Avi

On Fri, Apr 19, 2019 at 10:00 AM Marshall Greenblatt <magree...@gmail.com> wrote:

Hi John,

According to [1] Google is planning to block sign-ins from CEF (and presumably Electron) starting in June. This will be a substantial problem for many Chromium embedders who use the project as a “normal” web browser similar to other Chromium-based browsers like Opera and Microsoft. From the announcement it’s unclear how this embedder block can be implemented without also blocking other Chromium-based browsers. Also, presumably, Google will not be blocking sign-in from Mozilla or other “less secure” browsers that are not based on Chromium.

Can you provide more details on this restriction and what, specifically, we should expect from the technical implementation?

And, finally, I would request that in the future you reach out to the embedder community before making these types of public announcements so that we can fully understand the issue and properly communicate it to our users before they see it as scary news headlines.

Thanks,

Marshall 

[1] https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+GoogleOnlineSecurityBlog+(Google+Online+Security+Blog)&m=1

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

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

To post to this group, send email to embedd...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/F74EC822-6026-4A61-83EA-7D758DECAD9F%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

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

To post to this group, send email to embedd...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/0d27c900-a949-455e-8f7e-d097a708b7be%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--

You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To post to this group, send email to embedd...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/d2b01405-11db-401a-88ad-ca20be60e28d%40chromium.org.

[Jonathan Skelker]

Firstly apologies for any anxiety or confusion caused by my blog post last month. To clarify, as of June we will start blocking sign-ins that are obviously automated; existing apps will not be affected. In hindsight the blog post is definitely unclear as to the scope of the June launch, and it would have been better to reach out to this group in advance.

The signals we use to detect automation are sensitive, so unfortunately we can’t share the raw data, but they have shown us clearly that a significant amount of malicious automation comes from CEF and other embedded frameworks. Over time this means that we can’t guarantee we won’t block a legitimate app from signing in if it implements sign-in using the same tools as a malicious app. Regardless as to whether an app appears suspicious or not, as part of efforts to make the web a safer place and better educate users, we want to eventually stop supporting any sign-in to Google from an environment that hides the URL.

Applications that require a Google sign-in should authenticate using OAuth via the system browser, even if they are embedding a browser engine, or consider migrating to Progressive Web Apps. We will be publishing more guidance and a timeline for migrating existing applications later this month. Meanwhile please reach out to me if you have questions or concerns about changes you need to make or the timeframe you’ll be able to make them in.

Jonathan

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/d2b01405-11db-401a-88ad-ca20be60e28d%40chromium.org.

[Marshall Greenblatt]

Hi Jonathan,

Thank you for the response. Can you share information (either on-list or privately) about how a Chromium-based application can qualify as "an environment that [does not] hide the URL"? Google Chrome is, of course, not the only "system" browser based on Chromium. Those other "system" browsers will want to continue supporting Google sign-in from within the Chromium-based application directly.

Regards,

Marshall

[Cristian Amarie]

(This is the message I posted on CEF forum, but it might be informative for other users like me if I'm posting here as well).

I am the maintainer of an application which is a browser, just not intended to be a system browser.

Though it can be used as a standalone browser (althoug it strips all extensions and plugins except the Flash, optional as well), its purpose is to mainly to let the user to perform the banking operations outside the regular browser. 

The application is a part of a security suite. 

Its use case is:

1. user navigates to a bank/payment URL in another browser

2. our network interceptor detects the navigation, scan the URL and prompts the flow if is it matches flags for banking/payment/business URL

3. depending on user settings, we prompt the user to continue navigation in our browser or launch automatically the URL in our browser (the user is still able to dismiss it and continue in the original browser)

4. user performs the banking/payment in our browser (executes in another non-hookable desktop, blocks malware URLs, perform more certificate checks, can opt-in to trigger our VPN solution on the duration of session on our browser etc. - all sorts of shielding implementations)

5. user closes our browser and returns to the default desktop.

Other than that, the application displays an address bar all the time, does not automate anything except being able to be launched initially with --url.

The obvious question is: in which scenario does this application fit, not being a system browser *and* embedding CEF, but still being a browser ?

Regards, 

Cristian

[He-Man]

In a practical and secure way, how would kiosk software do such a thing?

[Stanley Lim]

Well this took me a bit by surprise. Now I know the main motivation for this is security, but would anyone care to enlighten me as to how this will be a fool-proof solution to protecting users from phishing attacks. There is a blatant workaround through tampering with the rendering engine's user agent. I do not see how this is an effective solution proposed by the Google Sign In team.

[Andrew Snyder]

What is the latest on this. Is there a possible solution for legitimate applications to use CEF and allow a google signin?  

It seems like it would make sense to be able to set some compile time or runtime information into CEF. 

GOOGLE_API_KEY=your_api_key
GOOGLE_DEFAULT_CLIENT_ID=your_client_id
GOOGLE_DEFAULT_CLIENT_SECRET=your_client_secret

We are trying to use the google drive picker https://developers.google.com/drive/api/v3/picker and hosting it inside our CEF based desktop application.  If we need to do the recommend desktop auth how do we inject the auth information into the cef hosted picker? 

[Edward Newman]

Also interested to find a way to solve similar issues as this restriction has broken SAML based authentication using embedded Chromium. Not finding anyone who knows how to resolve, including both of the vendors that have broken products we use.

[Frode Hernes]

Are there any solutions, - it seems hard to get any answers on this, who can we contact?

This is also hitting the Vewd Browser for TVs, - available on 12-15M Smart TVs around the world. 
(Formerly called the Opera TV Browser")
It is not a "System Browser", as Android TV and Linux-based TV Platforms does not come with a system browser, but millions of users rely on this browser to brows for entertainment, - which means some of them may wish to read their email there too.

And of course, we do the "right thing" releasing with the latest Chromium, displaying the URL field with security information, mandating / blocking the same Ciphers and Certificates as Chrome does etc.

[PhistucK]

You can reach out to Jonathan, see this post.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/0245715e-38f2-4c96-a313-48a7682ebf41%40chromium.org.

[Mitch Capper]

I can say that I contacted them in Sept and while initially it seemed positive with them connecting us to another team it became quite the slow role before both stopped responding completely for months.   The "additional guidance" never appeared.

3rd party browsers that are trying to act as browsers can't really "auth via oAuth and a different system browser" as that doesn't then have any path to then using those credentials for non api access.

Google has essentially just stepped in and used its massive control of both browsers and the massive slew of internet services that use google auth to effectively ban any browser that hasn't worked out a secret deal with them with no public path forward.

~mitch (he, him)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CABc02_JSNhN-pwudDEd53gTS-CK%2BcvEfxvw6GuZ2oxcesLCB2w%40mail.gmail.com.

[Avi Drissman]

On Wed, Jun 3, 2020 at 10:10 AM Mitch Capper <mitch....@gmail.com> wrote:

I can say that I contacted them in Sept and while initially it seemed positive with them connecting us to another team it became quite the slow role before both stopped responding completely for months.   The "additional guidance" never appeared.

That is disappointing. Let me follow up with him.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CALn233pjoXphMH2FBz%3DVS4pag%3D7mDbnRF%3DdjKWwFa1XJqx0Jzw%40mail.gmail.com.

[Frode Hernes]

Thanks,

The link shared below just gets a 404 and Jonathan's account in the CEF forum does not contain any contact info.

Frode.

--

Frode Hernes
SVP Product Management
Phone: +47 45206020 

fr...@vewd.com

[Cristian Amarie]

I have contacted Jonathan more than one year, he moved away from that team, and I resent to the email he forwarded me. No reply as of today.

Cristian

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/DDBF6A7A-CF16-41C2-AD55-EB2CC9D5D7CF%40vewd.com.

[Frode Hernes]

Still no answers, several large TV manufacturers ask for progress. Is it possible to get in contact with someone so we can discuss the situation?

Frode

--

Frode Hernes

Vewd Software AS

[Mike Marynowski]

This is a completely assinine approach, as if nefarious actors won't immediately find workarounds or switch to a different embedded engine that isn't blocked...ugh. Yay for stifling browser competition I guess though.

[The Canine]

I have also contacted Jonathan about it this week to try and explain some of the other problems this approach brings and got a response this morning, responding with something similar, to what is written in the message he sent here. I already responded with more details, hoping some compromise can finally be reached here. Which is why I joined this group, hoping I can keep you updated, if it gets anywhere.

If any of you found out something interesting, that could help finally solving this, please share it here.

But I completely agree that this approach is asinine and there are workarounds, that I also mentioned in said email, as an example of their solution being ineffective. I will not share them here, as I still hope this can solved in good faith. The actions also seem very anti-competitive and according to a lawyer I know, might even be illegal, but that is something that I am not willing to continue either, as I am only doing this as a passion project and earn no money working on it, so I do not need to become homeless trying to sue Google, but it might be worth for the big companies, that might be effected, so I would advise Google to finally resolve this.

Dne pátek 12. února 2021 v 20:31:33 UTC+1 uživatel mi...@singulink.com napsal: