Today, I received the same email for my Chromium package for Slackware Linux.When I started building Chromium for Slackware, I reached out to Google to formally arrange a Google API key/id/secret combination for use in my Chromium binaries that allow people to login to their Google account *and* use Google sync (passwords, bookmarks, history etc).From the email I received I understand that the ability to use Google Sync will be removed from my API keys used to build this Slackware Chromium browser binary. The value of the Chromium package for endusers will drop right to zero if that is true.I honestly see no reason to continue compiling and packaging Chromium for Slackware if the Google developers present in this group confirm this policy change by Google.Which would be a shame since there is no 32bit Google Chrome and I have been offering 32bit Chromium packages until today for the most recent releases of Slackware. Yes, 32bit OS-es are still being used.Developers, please comment.Eric Hameleers--Op vrijdag 15 januari 2021 om 19:39:29 UTC+1 schreef evan...@foutrelis.com:Does this mean that Chromium builds shipped by Linux distros will no longer have access to Sync (e.g.: saved passwords and bookmarks)?Or would removing "google_default_client_id" and "google_default_client_secret" allow our Chromium builds to continue to function normally?On Fri, 15 Jan 2021 at 20:06, The Google Chrome Team <chrome-...@google.com> wrote:![]()
Hi Chromium Developer,
We are writing to let you know that starting March 15, 2021, end users of Chromium and Chromium OS derivatives using
google_default_client_id
andgoogle_default_client_secret
on their build configuration will no longer be able to sign into their Google Accounts.What do I need to know?
During a recent audit, we discovered that some 3rd-party Chromium-based browsers had keys that were allowed to access Google APIs and services that are reserved for Google use only. Chrome Sync is the most notable of these APIs.
In practice, this means that a user would be able to access their personal Chrome Sync data (such as bookmarks) not just with Chrome, but also with a non-Google, Chromium-based browser. Please note that users would only be able to access their own Chrome Sync data, and only a small fraction of users of Chromium based browsers were impacted. We have no reason to believe that user data is being abused or accessed by anyone other than the users themselves.
As part of Google’s efforts to improve user data security, we are removing access from Chromium and Chromium OS derivatives that used
google_default_client_id
andgoogle_default_client_secret
on their build configuration to Google-exclusive APIs starting on March 15, 2021. Guidance for vendors of Chromium derivative products is available on the Chromium wiki.What does this mean for my users?
Users of products that are incorrectly using these APIs will notice that they won't be able to log into their Google Accounts in those products anymore.
For users who accessed Google features (like Chrome Sync) through a 3rd-party Chromium-based browser, their data will continue to be available in their Google Account, and data that they have stored locally will continue to be available locally.
As always, users can view and manage their data through Google Chrome, Chrome OS, and/or on the My Google Activity page, and they can also download their data from the Google Takeout page, and/or delete it from this page.
What do I need to do?
To avoid disruption, follow the instructions for configuring and building Chromium derivatives in the Chromium Wiki (link provided above).
Possible ways to implement this are:
- Removing
google_default_client_id
andgoogle_default_client_secret
from your build configuration.- Passing the
--allow-browser-signin=false
flag at startup.Your projects that may be affected by this change are listed below:
If you have any questions or require assistance, please contact embedd...@chromium.org.
Sincerely,
The Google Chrome Team
© 2021 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043
You have received this mandatory service announcement to update you about important changes to Google services you use.
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/8f555d67-bc0e-48c0-91f4-881fa0ea6a9an%40chromium.org.
Note that the public Terms of Service do not allow distribution of the API keys in any form. To make this work for you, on behalf of Google Chrome Team I am providing you with:
- Official permission to include Google API keys in your packages and to distribute these packages. The remainder of the Terms of Service for each API applies, but at this time you are not bound by the requirement to only access the APIs for personal and development use, and
- Additional quota for each API in an effort to adequately support your users.
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/CAEoffTByYuVk%3DOSDfFWjbbLnzKM1Pd%3DfdXR5OP%2B5esHnr6LVbQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAA407mzzXY-4QsGYB7rTUD3zdux71%3DQx5Z7ZVueLk%3DRT-39bMA%40mail.gmail.com.
HiJust as a note, this will also affect all BSDs shipping chromium.On 2021. Jan 19., at 20:59, Tom Callaway <spo...@gmail.com> wrote:This is a really unfortunate result, especially for those of us (most of us) who have been maintaining chromium for our respective Linux distributions since the beginning.Is there really no way for us to continue to access the Sync (and the other "Google Exclusive" APIs) in our Linux distribution packaged Chromium builds?Tom
--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAA407myqUJjxkpsT4c5hJ1WVA3H_FmUawzM0Gyroxba6%3DSgYuA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CACp8ZrJDzy4LOcU6MSJYocRWLBJR5fOR0GOTsSo2RS%3DXGWst%2Bg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/6EAE783C-6350-4FE9-BC83-AFA5E2E2E6EA%40openbsd.org.
Well, it is obvious that this Google employee called jochen (no idea about his legal status) is adamant at alienating a community of distro packagers who for many years have been providing a service both to distro users (I repeat, the latest Chromium for Slackware is still available as a 32bit build) and to Google themselves (offering people an alternative to the Open Source Firefox and thereby increasing the number of consumers of the Google platform services which will surely have been very profitable).Frankly, I find his statement insulting to us distro packagers and an offense to his colleagues who have collaborated with us for a long time through this Google Group to provide stable native binaries for our distros (thanks guys, really).I can understand that Google wants to do something about abuse of their resources by commercial 3rd parties who ship embedded Chromium in their products and thus saving on infrastructure cost, but we are providing these packages for free, as a community service to users of our Linux distros which are also free. Please explain to me why this is a good thing jochen.This is only going to convince people to switch to Firefox. At least that browser can be built from source without effort, and its users are actively encouraged to use Mozilla Sync. When the advantage for Chromium users to be able to access their data across all platforms (Linux, Windows desktops, Android phones) is taken away from us, there is no point in continuing to provide native distro builds. The value of 'just another browser' is zero.Jochen, should we start telling the users of our distros what is happening and point them to the Mozilla alternative?Also, I am surprised at the deafening silence of our friends of the Google Chromium team. Are we all left to hang out and dry here? Is this an internal political struggle or power grab?I am considering an alternative approach to just stopping with my Slackware packages - and that is to inform my users about the public availability of Google's own API keys, plus the fact that you just have to export them in your shell environment as values for the GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET variables before you start Chromium.EricOp dinsdag 19 januari 2021 om 21:23:12 UTC+1 schreef robert:
Hi Dirk,Good to hear that you are all in alignment over there at Google, but please address my actual questions, remarks, frustrations and doubts and ignore the sarcasm.EricOp dinsdag 19 januari 2021 om 22:02:00 UTC+1 schreef Dirk Pranke:
jochen@ represents the Chrome team on this (including the Google members of the Chromium team, which includes myself), so we're attempting for this to not be a deafening silence. This change should also not be interpreted as the result of an internal struggle or power grab.-- DirkOn Tue, Jan 19, 2021 at 12:56 PM Eric Hameleers <al...@slackware.com> wrote:Well, it is obvious that this Google employee called jochen (no idea about his legal status) is adamant at alienating a community of distro packagers who for many years have been providing a service both to distro users (I repeat, the latest Chromium for Slackware is still available as a 32bit build) and to Google themselves (offering people an alternative to the Open Source Firefox and thereby increasing the number of consumers of the Google platform services which will surely have been very profitable).
Frankly, I find his statement insulting to us distro packagers and an offense to his colleagues who have collaborated with us for a long time through this Google Group to provide stable native binaries for our distros (thanks guys, really).I can understand that Google wants to do something about abuse of their resources by commercial 3rd parties who ship embedded Chromium in their products and thus saving on infrastructure cost, but we are providing these packages for free, as a community service to users of our Linux distros which are also free. Please explain to me why this is a good thing jochen.
This is only going to convince people to switch to Firefox. At least that browser can be built from source without effort, and its users are actively encouraged to use Mozilla Sync. When the advantage for Chromium users to be able to access their data across all platforms (Linux, Windows desktops, Android phones) is taken away from us, there is no point in continuing to provide native distro builds. The value of 'just another browser' is zero.Jochen, should we start telling the users of our distros what is happening and point them to the Mozilla alternative?
Also, I am surprised at the deafening silence of our friends of the Google Chromium team. Are we all left to hang out and dry here? Is this an internal political struggle or power grab?I am considering an alternative approach to just stopping with my Slackware packages - and that is to inform my users about the public availability of Google's own API keys, plus the fact that you just have to export them in your shell environment as values for the GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET variables before you start Chromium.
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/658b0ade-e1b8-4dc6-9bdb-d7582d416f63n%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAEoffTAonpUTmnQiwnrPQRgH6QFd4XbhjGBn9RxFLOtcAXB2mA%40mail.gmail.com.
Hi,
> To reiterate, the APIs were not designed to be used by third-party software, so short of a complete rewrite, there is no unfortunately no option.
This looks to me like a change in approach: in the past, the Chromium project was supportive of Linux distributions building a copy of Chromium from source for people to use.Is that no longer a goal?
Puzzled,Jonathan
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/CALjhuieH6fB4KK%3DFNffJxm267BW0sDiN-gAMFoVt9XzXmNfuZg%40mail.gmail.com.
Dirk Pranke wrote:
> There has been no change to the browser source code per se, and you can still build a perfectly functional browser, except that now it can't use Google/Chrome Sync.
>
> We know this affects users on platforms where there isn't a supported version of Chrome, and probably other users as well.
Thanks, Dirk.It sounds like this means two things for packagers:- any high quality package will need to provide affected users with instructions for generating personal API keys. That way, Chromium's support for these features can still be useful, though it would require more fuss to make use of it. This makes the terms behind the API keys less murky, which seems valuable regardless (e.g., for users who plan to make use of their freedom to further modify the package they received from a distributor).- we'll need to find a way to provide a reasonable experience for users who haven't done that yet, and to make this more discoverable.We have a month and a half or so to work on it, which is not ideal but is better than it coming without warning.Thanks,Jonathan
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAOf41NmAU%3DYzsOAUTJ%3D9d378XE%3Dk%3DmYUqDW7TXd-PtpCw1f1MQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/2cd70dcd-1e0b-4186-bc55-9465d2858660n%40chromium.org.
FYI, the 2013 special terms, additional quota, and exact wording of the email I sent to packagers passed the internal approval process, including legal, engineering, and VP-level management.
If this reversal was better communicated, we could have a less confrontational, more productive conversation. I recognize that everyone seeks to do the right thing though: protect user data, and offer users a great web browser experience that is 100% open source.
How about giving users an option to allow Chromium access (opt-in) - is that a possible path forward?
Unfortunately, this is not an option (Jonathan also suggested that somewhere up thread). If I had a better option to offer, believe me, I would have shared that already.
--
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/CAA407mz6-bWT7n6V%2BYoc2CdheNM4q2-_Cjecc4U%3DhrHy_M2GCA%40mail.gmail.com.
The change we announced impacts the ability to "Sign into Chrome" and consequently first party features that depend on being signed into Chrome. This does not include Safe Browsing, which doesn't depend on being signed into Chrome, and is available to third parties for non-commercial use (cf https://developers.google.com/safe-browsing).
--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAA407my9xjqw2EwUM7LBF4dtjnX2CKVuFN_S7ndFyexF8tmcaw%40mail.gmail.com.
I see relevance in the fact that if I look at my Cloud Console and open the page for Chrome Sync API, what does the the API description say?I quote: "Google Chrome Sync API for use in Chromium."You can keep replying with empty words all day long but in the end you're just throwing all of us Chromium distro packagers under the bus jochen.
This is a (partial) list of APIs Chrome depends on, including APIs available to third parties. The changes we announced affect the OAuth 2.0 client id and secret which are used for signing into Chrome, not the API key.
On Mon, 25 Jan 2021 at 21:16, Jochen Eisinger <joc...@chromium.org> wrote:This is a (partial) list of APIs Chrome depends on, including APIs available to third parties. The changes we announced affect the OAuth 2.0 client id and secret which are used for signing into Chrome, not the API key.You have maintained that our Chromium builds are prohibited from using Google APIs. This includes the API key, in addition to the OAuth 2.0 credentials. Unless you are now saying that the API key is fine to keep (based on which section of the Terms of Service?), then you are directing distribution maintainers to ship Chromium without Safe Browsing (among all the other lost functionality). [1] [2]
You can't randomly pick which credentials you want to limit, which go against the ToS and which are fine. Either Chromium is no longer a viable package for Linux and BSD distributions, or the Chrome team needs to come up with a way to keep these Chromium builds functional. If you don't want to bother with the latter, Chrome's keys can be used instead, which is allowed by the ToS exception given to us in 2013. [3] [4]
you're welcome to continue to use third party Google APIs with your API key
The chromium code should fail gracefully if a given API is missing from the key, or if the API runs out of quota
We never granted permission to use Chrome's API key for third party software.
Also, the OAuth 2.0 integration was introduced in Chrome 69 in 2018.
On Tue, 26 Jan 2021 at 16:06, Jochen Eisinger <joc...@chromium.org> wrote:you're welcome to continue to use third party Google APIs with your API keyAre you sure about that? The Terms of Service seem to prohibit it (unless you take into account the exception from 2013 which you said they didn't have the authority to give). You also wrote that Safe Browsing is free for non-commercial use, for which Chromium used in a work environment might not qualify.Fedora also dropped all keys so I'm guessing their users are now getting Unsafe Browsing after the Chromium 88 update.
The chromium code should fail gracefully if a given API is missing from the key, or if the API runs out of quotaSafe Browsing does not work without an API key so as far as I'm concerned, the Chromium code by itself will only be good for Chromium development after March 15.We never granted permission to use Chrome's API key for third party software.Is Chrome's API key a Google API key? Then we have "permission to include Google API keys in your packages and to distribute these packages".
You said you're not a lawyer and can't give legal advice. I'm not a lawyer either but the above permission seems good enough to me.Also, the OAuth 2.0 integration was introduced in Chrome 69 in 2018.Both Arch's and Chrome's OAuth 2.0 Client IDs date back to (at least) 2013. I'm not sure where you're going with the 2018 year.
Was this 2013 email really backed by a Google Vice President with full company vetting? It seems like the truth of this is agreed upon by all parties. Wow. It's hard for me to imagine a more real-seeming commitment than that.Yet according to the Googlers in this thread, the apparent commitments in these 2013 emails were not real commitments, however real-seeming. (I hope I have accurately summarized the position.) Yet doesn't taking this position seem a little like opening Pandora's Box?If Google continues with this, every Open Source project will have to ask the question that if these emails for Chromium are not considered to be a real commitment by Google, then are Google's commitments to their project real? What would a real commitment from Google even look like, that it might be stronger than these 2013 emails? I don't know what actions each Open Source project might take to protect the Open Source community from Google after that, but certainly any actions taken won't be in Google's favor, and considerable ill-will will be generated towards Google where there was none before.I wonder: Has Google approved this action with full knowledge of the existence of the real-seeming commitments it had made, how denying those commitments might affect its relationship with the larger Open Source community, and how poor relations with the Open Source community might affect more of its customers and products than just Chrome?Perhaps these other aspects should be considered for a while before implementation?
RE: "Again, we're not asking you to change the API key, but to either build without the OAuth 2.0 client id and secret or to disable the Google signin integration. "So we are OK to disable all the API calls marked as private and can still embed the API client_id and secret? We aren't distributing the id and secret as such since its embedded within the binary.
On Wednesday, 27 January 2021 at 15:46:55 UTC joc...@chromium.org wrote:Hey,On Tue, Jan 26, 2021 at 6:34 PM Evangelos Foutras <evan...@foutrelis.com> wrote:On Tue, 26 Jan 2021 at 16:06, Jochen Eisinger <joc...@chromium.org> wrote:you're welcome to continue to use third party Google APIs with your API keyAre you sure about that? The Terms of Service seem to prohibit it (unless you take into account the exception from 2013 which you said they didn't have the authority to give). You also wrote that Safe Browsing is free for non-commercial use, for which Chromium used in a work environment might not qualify.Fedora also dropped all keys so I'm guessing their users are now getting Unsafe Browsing after the Chromium 88 update.I asked the Safe Browsing API team to clarify on their public documentation that the use of the SB API in chromium browsers continues to be permissible.Again, we're not asking you to change the API key, but to either build without the OAuth 2.0 client id and secret or to disable the Google signin integration.The chromium code should fail gracefully if a given API is missing from the key, or if the API runs out of quotaSafe Browsing does not work without an API key so as far as I'm concerned, the Chromium code by itself will only be good for Chromium development after March 15.We never granted permission to use Chrome's API key for third party software.Is Chrome's API key a Google API key? Then we have "permission to include Google API keys in your packages and to distribute these packages".I'm not sure where you're trying to go with this question. I think I've made myself sufficiently clear.You said you're not a lawyer and can't give legal advice. I'm not a lawyer either but the above permission seems good enough to me.Also, the OAuth 2.0 integration was introduced in Chrome 69 in 2018.Both Arch's and Chrome's OAuth 2.0 Client IDs date back to (at least) 2013. I'm not sure where you're going with the 2018 year.Sorry, you're right about the OAuth 2.0 client id existing before. I was referring to the API we currently use to get LSTs (the one we're changing) which was introduced in 2018.
--
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/e5d20c24-8231-41e1-864a-b97dd817b83bn%40chromium.org.
OK Jochen. My company need the Chrome Sync API sincerely.For using the restricted API, What should third-party do?
Have to pay? or should become official partner of Google?Could you tell me contact information for payment or partnership?
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/a6c58a3a-d7e9-4b0d-8974-eac23bf65efen%40chromium.org.
On Friday, January 29, 2021 at 6:17:04 AM UTC+9 joc...@chromium.org wrote:
Yes, for Chromium OS you'll indeed need to set the client id and secret to be able to log in with a Google Account. The --allow-browser-signin flag only affects chromium, on chromium os, the browser gets the LST from the OS.Note, however, that the restriction to only use this for development still applies.
@Jochen. Can I ask exact meaning of the restriction?Do you mean that using google_default_client_id google_default_client_secret with the --allow-browser-signin=false flag in Chromium OS is allowed only for development/test? not allowed for Chromium OS derivation distribution?