Re: [chromium-packagers] Re: [Action Required] Update on Google API usage in Chromium

[Dirk Pranke]

The emails said that for questions you should ask on the +Chromium Embedders mailing list, but I don't see anyone asking about this there.

Is there someone on embedder-dev who can respond to this?

-- Dirk

On Fri, Jan 15, 2021 at 1:14 PM Eric Hameleers <al...@slackware.com> wrote:

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

Read: alien.slackbook.org/blog/

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:

As part of Google’s efforts to improve user data security, we are removing access to those APIs starting on March 15, 2021.

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 and google_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 and google_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 and google_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:

• Arch Linux Chromium (arch-linux-chromium)

If you have any questions or require assistance, please contact embedd...@chromium.org.

Sincerely,

The Google Chrome Team

Was this information helpful?

YES   NO
 

© 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.

[Evangelos Foutras]

Well, the main concern here is whether the Chromium builds shipped by numerous Linux distributions could continue to work with Sync, like they have for the past decade. Otherwise, as Eric said, the value of a Chromium package drops significantly and it becomes inferior to proprietary Chrome.

I would also be interested to know why this is suddenly a security issue, considering that Chrome's keys have been public since at least 2012 (and still to this day embedded in the chrome binary!). [1] [2]

The announcement makes it seem like our Chromium builds have been using API keys with unwarranted access, even though explicit permission to use them was provided back in 2013 when a member of the Chrome team contacted me about adding them to the Arch Linux chromium package:

(excerpt from the initial email follows)

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.

[1] https://chromium.googlesource.com/chromium/src/+/b08bf82b0df3/google_apis/google_api_keys.cc

[2] https://github.com/adobe/chromium/blob/master/chrome/common/net/gaia/gaia_urls.cc#L27-L36

[Jochen Eisinger]

Hey,

I'm sorry to be the bearer of unwelcome news, but this change will indeed happen.

We won't remove the API from your key, but we'll limit the quota to the quota for development. It's true that this will make the keys unsuitable for production use.

best

-jochen

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.

[Evangelos Foutras]

In that case, what's stopping us from switching our Chromium builds to use Chrome's keys? [1] [2]

And unless you obscure Chrome's keys, how does killing our keys improve user data security?

[1] https://chromium.googlesource.com/chromium/src/+/b08bf82b0df3/google_apis/google_api_keys.cc

[2] https://github.com/adobe/chromium/blob/master/chrome/common/net/gaia/gaia_urls.cc#L27-L36

[Jochen Eisinger]

I'm aware that you've been in contact with a Chrome team member about this, however, the Terms of Service don't allow this usage, and they didn't have authority to change the terms.

I'm also aware of the keys not being secret, but that doesn't imply that it's ok to use them for other products.

best

-jochen

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.

[Evangelos Foutras]

The keys being public implies that user data safety is not significantly improved by limiting the keys of Linux distributions shipping Chromium.

I honestly don't see the issue if a Chromium build were to use Chrome's keys. They have been publicly known since 2012 and have not been rotated even once during the past 8 years or so. Unless you are planning to obfuscate them in the chrome binary, this is nothing more than a security theater, in my opinion.

At any rate, good job throwing your colleague(s) behind the permission to distribute our keys under the bus, and in the process alienating a potential source of quality bug reports for Linux-related issues.

And with that, I'm out. Cheers.

[Jochen Eisinger]

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.

best

-jochen

On Tue, Jan 19, 2021 at 9:23 PM Robert Nagy <rob...@openbsd.org> wrote:

Hi

Just 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.

[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.

-- Dirk

On 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.

Eric

Op dinsdag 19 januari 2021 om 21:23:12 UTC+1 schreef robert:

[Jochen Eisinger]

On Tue, Jan 19, 2021 at 10:23 PM Eric Hameleers <al...@slackware.com> wrote:

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.

Eric

Op 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.

-- Dirk

On 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).

Guess I should have introduced myself, sorry about that. I'm a Director of Engineering at Google, working on Chrome since 2009. I'm also aware of and grateful for the work done by packagers, it's not my intent to alienate you. At the same time, I'm aware that this is unwelcome news, and I don't expect you to take it lightly.

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 not a security nor an infrastructure cost decision, but we're taking this action to ensure that the user of our internal APIs is in compliance with our policies.

 

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?

I think it would be good to let your users know once you've decided how you'll react, so they in turn have time to make their decisions.

 

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.

That would still be prohibited by our policies, and may be broken in the future without notice.

best

-jochen

[Jonathon F]

My question here is, since when has Chromium been third-party software?

Linux distributions are not embedding Chromium in third-party software  - it's being built as-is directly from the source tree. There are even specific (official?) instructions for building on Arch Linux: https://chromium.googlesource.com/chromium/src/+/master/docs/linux/build_instructions.md#Arch-Linux

I can understand an API restriction where Chromium's engine is being embedded in another browser-based project (e.g. Steam, mobile apps, ...) but I really can't see how building Chromium from source is the same as embedding it in third-party software.

J

[Dirk Pranke]

If you're asking in the sense of "why are we talking about this on embedder-dev@ and not chromium-packagers@", it's only to avoid cross-posting.

If you're asking in the sense of "why is Chromium considered third party software", it's in the sense that anything that is built and distributed by someone other than Google is third party (to Google), I believe.

-- Dirk

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.

[John Abd-El-Malek]

Folks: I'd like to remind everyone that Chromium has a Code of Conduct. While I understand people might not be happy with this announcement, please assume the best intent of everyone involved and there's no need to be disrespectful.

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

[Dirk Pranke]

On Thu, Jan 21, 2021 at 12:17 PM Jonathan Nieder <jrni...@gmail.com> wrote:

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

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.

-- Dirk 

[Adam Goode]

Can we talk about what the redesigned APIs would look like? If the old APIs are going to become restricted soon, it would be good to see if we can replace them with something that works for everyone. Distro-specific Chromium builds are important for many reasons.

Are there particular requirements that can be shared with the list?

Thanks,

Adam

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.

[Jochen Eisinger]

Unrelated to the upcoming limitation of API keys, we'll likely update the way the quota limitation is implemented in the near future which would break the flow you've described.

On Fri, Jan 22, 2021 at 7:09 AM Jonathan Nieder <jrni...@gmail.com> wrote:

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

[Jochen Eisinger]

Sorry, there are currently no plans to develop alternative APIs for these features.

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.

[Lord Anton Hvornum]

Seams odd to start dropping a large portion of peoples features for something a few people did.
Why not have a trusted tier model? Users & Communities who've earned a reputation over the years, shouldn't that mean something?

Or we stopped caring when we hit 50k+ users with a steady growth because more new users come in than the old ones care to stay?

(It really grinds my gears that society is punishing the masses more and more for every little thing a few shady people do.)

I hope my passwords still Syncs actively between browser sessions, otherwise this is a deal breaker (as with many other weird things Google have done the last two years that I've put up with).

[asmqb7]

Hi all, 

This has garnered a small but notable amount of attention over at https://news.ycombinator.com/item?id=25886218, which points to https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5, the release notes for the Fedora Chromium 88 package which clarify that Sync has been preemptively disabled in anticipation of the shutdown, likely to raise (necessary) awareness about the situation. As just another random Chromium user, I'm very curious about this unexpected change, like others are and even more will soon be.

The responses from the Chrome team add limited but helpful color to what appears to be a complex situation. I might be reading everything completely incorrectly, but I get the impression that Something Interesting has happened, possibly very recently, with regards to downstream consumption of the Chromium/Chromium OS open-source projects; a key consideration appears to be that every successful downstream use of the Chromium open-source project in particular has generally implemented independent sync services that do not take advantage of the existence of proprietary endpoints made available through Google servers for the purposes of adding value to Chrome and Chrome OS, and which until now have coincidentally also worked in Chromium and Chromium OS.

I have a few hopeful questions, which I understand might be based on incorrect assumptions or simply irrelevant at this point.

1. Might some EULA clarifications concretely frame the proprietary nature of the Sync Service and its licensed use being restricted to first-party, effectively unmodified versions of Chromium/Chromium OS?
   
   
2. Might it be useful to extend (1) to explicitly differentiate between Chromium and Chromium OS, such that distinct agreements can be applied to each?
   
   
3. Could it be effective to transition the preexisting Linux distribution API key agreement over to a limited-access arrangement that allows trusted package maintainers to roll new key sets for successive Chromium releases, with old keys expiring after (not a misprint) 2-4 weeks? (This would effectively funnel (Chromium,Sync,Linux) users into a first-class evergreen update cadence, which can't be bad for security, and it might even get distributions into a better place too.)
   
   
4. Given that a) the sync system is fundamentally proprietary, b) the BSD-licensed-but-effectively-source-available nature of the sync client implementation, c) all Sync features being opt-in, d) the existence of alternative browsers with first-class sync capabilities, and e) the amount of entropy that is necessarily transmitted when using Google services... might it be interesting to move the sync functionality into a proprietary add-on module that then leverages eg keybox tokens? The inspiration for this question comes from instances where I've observed Goog take a very effective spatula to authentication-related scenarios on the Android platform which (if I'm assuming correctly) may share similarities with this situation.
   
   
5. Is it possible that the sync client implementation will be moved out of the open-source Chromium codebase in the future? This new direction makes closed-source Chrome the only inbox consumer of the open-source sync client code, with other browsers (such as Brave) coincidentally taking advantage of the fact that the code just happens to exist and works.
   
   
6. Alternatively, would it be possible to further expand on sync/test/fake_server such that motivated individuals that wish to continue using Chromium would be able to reliably self-host their own sync services? The old Python sync server removed in 088b19e is admittedly much more accessible than the current C++ implementation, which I'm not even sure how to launch (it builds a static library?).

A couple of sidenotes/observations:

• Up to now, ignoring branding and license restrictions, a large proportion of Linux users use Chromium on their PC and Chrome on their phone, simply because Chrome gets handed to you by the Play Store (or is already preinstalled), and Chromium gets handed to you by your distribution's package repository. You type your credentials in everywhere, and... it just works, nothing to report.
  
  
• It's only possible to transit/export bookmarks to and from from Chrome on Android through Sync. There's no offline way to do it. Now I have to switch to Chrome on my PC if I want to coordinate the bookmarks, tabs and history on my phone going forward.
  
  
• For the past several years Chrome Sync has provided users of both Chrome and Chromium an effective baseline password manager that everybody within the open-source Linux community has had equal access to: immediately after setting up a new machine, pulling in whatever chromium package a user's distribution provides OOTB, entering Google account credentials, and waiting a bit for tabs etc and passwords to sync, users are good to go and ready to be practically productive in the real world, using an entirely FOSS stack. This is a noteworthy service contribution to open source integration and unilateral enablement - even Debian's Chromium builds support sync, because the sync code is open source. For those users that only have basic requirements (hi), Chrome's builtin *synced* password management is great.
  
  Further, Google's focus on privacy enhancement has recently integrated password management into proactive breach notifications. After browsing through password_manager/ and password_manager/.../leak_detection/, I'm of the (potentially-fallible) impression that the breach notification service (which is difficult to test/examine in action externally) may continue to work for everyone, but that password change prompts will only work for users that have Sync enabled. This does make sense from a feature flow perspective.
  
  From the perspective of long-tail social enablement, I think it can be fairly argued that the demographic of, for example, new Linux users that don't have the motivation and/or skill to independently pursue installing a discrete password manager a) likely also aren't yet at the point of maintaining proactive security hygiene with regards to password complexity and reuse and b) may simply stop using Sync in a couple of weeks when confronted with the relative complexity of installing Chrome. These users stand to benefit the most from both the autofill-sync support Chromium has been refining since version 6.0 ten years ago, and the more recent breach notifications that apparently only provide notifications without stepping users through proactive mitigations unless Sync is enabled.
  
  
• For some probably noteworthy number of users that hard-depend on Sync functionality for their workflows, Chromium is now going to take the place of Internet Explorer, and be installed just to have a way to click the Accept button on Chrome's EULA.

It will be hard to quantify the full impact of the network effects caused by this change.

While I'll be sticking with Chromium myself, it'll be interesting to see if the next few weeks/months bring above-average, statistically significant viewing with the browser market share stats.

With all the above considerations in mind, I propose that one effective solution to resolving the disruption and potential security implications caused by this change would be to provide privacy-focused users and groups appropriate first-class means to setup and maintain alternative sync services that are compatible with the sync client functionality currently present in Chromium.

asmqb7

[highbaser]

TL;DR

• Google has unreal, out of touch, idealist internal policies which they don't want to change because this is how they feel safe.
• Google doesn't want its APIs used by anyone but them, because it's not designed for external usage.
• Google doesn't want to rethink, refactor or replicate its sync API for external usage not because they didn't have their hundreds of billions of dollars to do so but because it's not their profitable interest. Less usable Chromium (without sync) means more installations of official Chrome --- which is closed-source BTW so it controls the user instead of letting the user control the software.
• Google has profited well of free labor done by the open-source community Chromium developers. Now it's time to spit them in the face and turn away from them, then focus only on corporate interests, policies and profit.

I'm kind of happy that this has finally happened as Chromium maintainers will need to create their own sync servers so that all of our personal data (browser history, account information, passwords, cookies, etc.) will go somewhere else than Google's servers where it's analyzed by their AI and used for our profiling, surveillance and manipulation through advertisements.

2021 is still holding 2020's beer. :)

Peace

[Eric Hameleers]

highbaser,  I do not know where you developed that idea that "Chromium maintainers will need to create their own sync servers". Chromium is being maintained by Google so your remark is irrelevant. If you meant to say "Chromium package maintainers" then your remark shows ignorance about what a distro packager actually does.

If someone starts a project to create a truly open Sync server for Chromium then I would consider packaging it for Slackware of course. The Brave project has built a Sync server for their Chromium-based Brave browser: https://github.com/brave/go-sync and it is open source but uses Amazon Cloud for their database backend storage. Understandable since they offer this for a potentially large group of users. But like Mozilla's original Weave sync server, I would like for a Chromium Sync server to be written in such a way that it can be self-hosted. I only trust myself.

Perhaps highbaser, you can start such a project. Put your money where your mouth is, so to speak.

Eric

Op zondag 24 januari 2021 om 13:23:40 UTC+1 schreef highbaser:

[Paweł Hajdan Jr.]

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?

Best,
Paweł

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.

[Jochen Eisinger]

Hey Pawel,

On Mon, Jan 25, 2021 at 10:18 AM Paweł Hajdan Jr. <phajd...@chromium.org> wrote:

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.

best

-jochen

[Lord Anton Hvornum]

Mind sharing what the blocker is for such a feature?

Is it the complexity of protecting users while still allowing sync functionality?

If I opt in by signing in with my Google account to enable sync, wouldn't certificate pinning (against google PKI) be a valid protection against evil logins wouldn't signing a browser binary and having a submission process protect the bulk if not all users?
If people create fake drop sites and removes the pinning and features etc, having a limited verification process for trusted communities and communities with perhaps a large amount of "followers" (like youtube has for their monetization plans) ensure no malicious miss-configurations are done. Users can ALWAYS circumvent this by creating fake versions of everything, including Google Chrome, but you have to trust someone - and I trust my maintainer group's official repositories. So should Google.

I doubt that <insert favorite Linux dist> would want to break these terms and risk being banned from all google related services such as indexing and potential hosting services.

---

tl;dr: What are we trying to combat with this "feature" really?

It's open source - why not source crowd ideas for solutions instead of just stone walling?

[Evangelos Foutras]

On Mon, 25 Jan 2021 at 11:35, Jochen Eisinger <joc...@chromium.org> wrote:

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.

So nothing is an option for you, other than shipping Chromium without Google functionality. Because only Chrome users are important enough to deserve unnecessary features such as "Safe Browsing". How awful of 2013's "legal, engineering, and VP-level management" to allow Chromium users to enjoy Safe Browsing and their data synced across their devices. Even more so, considering "they didn't have authority to change the terms" as you say.

Does the Chrome team seriously suggest it is OK to ship Chromium to users without Safe Browsing?

[Jochen Eisinger]

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 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.

[Evangelos Foutras]

On Mon, 25 Jan 2021 at 13:59, Jochen Eisinger <joc...@chromium.org> wrote:

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).

Safe Browsing API is listed at [1] and receives over 5 million requests per day according to the Cloud Console. It is not clear that it will continue to work after our API keys are limited and/or removed. Furthermore, "available to third parties for non-commercial use" is not sufficient for Linux distributions.

[1] https://www.chromium.org/developers/how-tos/api-keys 

[Jochen Eisinger]

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 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.

[Tony Ditchfield]

Hi All

For devs of Chromium OS, removal of the client_id and secret results in no ability to login at all. I appreciate this may need to be posted in Chromium OS Discussions  (cc'ed) but thought it better to continue the thread here rather than splinter it, since its the same topic we are discussing.

Lack of login is of course pretty fundamental ;-). Are Google saying that open source development of Chromium OS is now dead, unless just the guest account is used?

If we enable billing for the API noted in the email, would that allow use of the API fully again? Is there a process to become an official vendor of either ChromiumOS of Chromium to allow the continued use of the API?

Apologies for any duplication on questions etc, a bit late to this conversation!

Ref: https://chromium.googlesource.com/chromiumos/docs/+/master/developer_guide.md#optionally-add-google-api-keys

[Jochen Eisinger]

Hey,

you can continue to use the client id and secret for development, but not for distribution. Additional quota for first party APIs is not available for purchase.

best

-jochen

[Tony Ditchfield]

Thanks for the clarification Jochen, its appreciated!

[Eric Hameleers]

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.

I will not package and distribute a Chromium for Slackware if that package is crippled by absence of login to Chrome Sync. I will not package a Chromium build with Google's own ID and secret embedded. Instead I will do the right thing: advise people not to use Chrome but switch to Firefox, just like Fedora is already telling their users.

There's still an opportunity for you to come around and work something out with this community, but the window is closing. Start with telling the truth about why you are doing this to us packagers and the communities we serve. And stop selling the audit bullshit please. Pawel stated clearly that the agreement between Google and distro packagers was sanctioned by your own legal department and at VP level too. So I want legal statements from Google and a statement from a Google VP why you are disserving us now.

Eric

Op maandag 25 januari 2021 om 12:59:32 UTC+1 schreef joc...@chromium.org:

[Dirk Pranke]

Hello Eric,

Speaking now with my community-manager hat on ...

On Mon, Jan 25, 2021 at 1:32 PM Eric Hameleers <al...@slackware.com> wrote:

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.

You have been warned once already, but I will remind you again that we ask everyone on this forum to abide by the Chromium Code of Conduct. The statement above, and your statement below about "selling the audit" do not. 

I understand that this is a frustrating topic, but please refrain from personal attacks and please be respectful.

Best,

-- Dirk

[Evangelos Foutras]

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]

As a fun addendum, half of the responses so far read like "OK, too bad, so sad". [*]

[1] In my quick testing, Chromium without API keys fails to recognize links on https://testsafebrowsing.appspot.com/ as dangerous

[2] Not to mention the annoying warning with missing keys ("API keys are missing. Some functionality of Chromium will be disabled.")

[3] "Official permission to include Google API keys in your packages and to distribute these packages." seems pretty clear to me

[4] Unless, of course, the "legal, engineering, and VP-level management" of 2013 really "didn't have authority to change the terms"

[*] https://www.youtube.com/watch?v=5JZHgNNyzkc&t=9m35s

[Jochen Eisinger]

On Tue, Jan 26, 2021 at 1:56 PM Evangelos Foutras <evan...@foutrelis.com> wrote:

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]

The change affects first party APIs, you're welcome to continue to use third party Google APIs with your API key. You can configure which APIs you use with your key on https://cloud.google.com/console. The chromium code should fail gracefully if a given API is missing from the key, or if the API runs out of quota. The first party APIs are marked "private" in the API console, and in general only available if the owner of the project is subscribed to chromi...@chromium.org. I hear the feedback that a more complete list of APIs currently used by chromium and whether or not they're publicly available. I'll see to get that page updated.

The OAuth 2.0 credentials are used in chromium to get LSTs which are then used to mint tokens for other authenticated APIs. While not all authenticated APIs used by chromium are first party APIs, the one that gets the LST and that we'll restrict in mid March is a first party API.

To avoid using that API, it's sufficient to either not set the OAuth 2.0 credentials, or disabling the Google signin integration, e.g., via command line flags as described in the email you've received.

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]

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.

[Evangelos Foutras]

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 key

Are 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 quota

Safe 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.

[Evangelos Foutras]

And a fun fact: If you go to https://www.google.com/chrome/ and click "Download Chrome" it says:

  "Not Debian/Ubuntu or Fedora/openSUSE? There may be a community-supported version for your distribution here."

And points to this page: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/docs/linux/chromium_packages.md

"Some Linux distributions package up Chromium for easy installation." -- Yeah, back when you had different leadership I guess. 🙂

The Chrome download and the "Linux Chromium Packages" pages are going to need a huge disclaimer about the degraded functionality and security.

[Jochen Eisinger]

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 key

Are 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 quota

Safe 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.

 

[Tony Ditchfield]

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.

[Jochen Eisinger]

Let me try to clarify: The exceptions some distros got back then were sound back then, but after the most recent review, we concluded that we can no longer grant this exception. My point was that there wasn't a change in our official terms, they never allowed for that use. That doesn't imply that the exception given back then was not valid. But it also doesn't imply that we can't or shouldn't reconsider our position as the environment we operate in evolves.

On Wed, Jan 27, 2021 at 11:54 PM Ross Martin <ross....@ieee.org> wrote:

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?