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