Most interesting to me is that even though the Chrome team specifically provided API keys for open-source Chromium builds to use back in 2013, they are now claiming that "the Terms of Service don't allow this usage, and [the previous developer] didn't have authority to change the terms."
He is not an ex Oracle PM. He’s an old time chrome engineer who switched to management, he said it himself on the thread.
But this kind of corporate robot attitude is common for Google. It’s always the same story with them: they deprecate some service, write a heartfelt message about how they are aware this might destroy some projects/businesses and how difficult it was for them to make this decision, but they’re gonna do it anyways. Thank you very much for doing business with Google, have a nice day.
I get that it's frustrating but I don't understand what the real issue here is, or how this relates to anti-trust as some other comments are suggesting. They are under no obligation to offer any further explanation for why they won't operate a free service forever. It's a business, you can safely assume the explanation is always "because money."
They've already been sued! Lawsuits already claims that chrome, with eg 60% US marketshare, is used as a distribution channel for google!
Any plausible deniability they have had is gone, and lawyers are in the loop for all sorts of decisions now. Not least because having counsel on a thread can help prevent that discussion from being subpoenaed.
The response of the Director of Engineering towards the slackware package maintainer comes off as very arrogant.
I guess this is the end of the open source project. Chromium was never truly open source, more like free source, but now it’s not even that. It’s just another proprietary software.
Only recently was there discussion about how they used free access to widevine as bait while pushing EME, and now they conveniently ignore licensing requests...
More fuel for the ECs antitrust investigation I guess :)
That key thing always seemed really weird to me. You had to join some special Google Group and then they would magically show in Google Cloud Platform. And you could set the OAuth name to whatever you wanted.
> 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.
The unfortunate (for Google) reality is (as had already been pointed out to this fellow multiple times before he said that): whether they turn off these Linux distros' keys, people can still write third-party software to (ab)use these APIs, using Google's own keys. The CFAA is only going to keep legit uses from using Google's keys. This does not, in any way, fix the issue that Google is claiming it fixes.
I think you misunderstand Google's intention. They want to prevent competitor browsers from using these APIs so people are forced to use Chrome (and it probably relieves some backwards compatibility work too).
Yes, you can steal Chrome's keys, but Google can easily update those in Chrome. Are you going to write an automated system to extract the keys from Chrome on every update? Doubtful.
This stops browsers like Opera and Brave from using the APIs.
Brave and Opera both use their own solutions for syncing.
In fact, can anyone name a browser except Chromium that uses Chrome's sync servers for syncing? Because I can't.
Also your point about backwards compatibility doesn't really make sense as Google has plenty of ways to detect browser version and capabilities of the sync engine (the sync engine sends that info to the sync server voluntarily right now).
Also Google can't just disable it's own API keys every time there is an update because this would shut down a large number of it's own users too. They would need to wait at least 1-3 months to avoid larger disruptions and this would give others more than enough time to fetch the latest keys (and if there is interest, there will always be someone who does that and posts them).
> Also Google can't just disable it's own API keys every time there is an update because this would shut down a large number of it's own users too.
It can because the official Chrome auto-updates very reliably. They only have to support a few versions back. They could even force updates if they wanted.
None of that is true for Chromium. Do they really want to support the 10 year old Chromium from Debian stable?
> They want to prevent competitor browsers from using these APIs so people are forced to use Chrome
That is not, in ANY way or by ANY stretch, their argument, although I'll agree it is clearly their intention. Their argument is very clearly based on a security perspective.
> Yes, you can steal Chrome's keys, but Google can easily update those in Chrome. Are you going to write an automated system to extract the keys from Chrome on every update? Doubtful.
Really? You think malware authors won't take such a simple step as that if it makes them money?! You're insane.
Besides which you don't (currently) have to do that because they've never changed!
> This stops browsers like Opera and Brave from using the APIs.
No, their terms of service do that. Otherwise, Opera and Brave could just go pull the keys out of the source and use them.
It would take require changes to Chromium (with regards to authentication), but Brave's sync server is open source and protocol-wise mostly compatible (client side encryption is enforced):
https://github.com/brave/go-sync
I doubt Chromium authors would accept changes to authentication (even if you put guards around it like `#ifndef GOOGLE_CHROME_BRANDING`). If there were a 100% compatible service available, you can change the service URL using CLI arg `--sync-url`
There is also a local sync backend which is interesting as it writes to disk. You could potentially sync this via OneDrive or something similar. You can enable with the CLI arg `--enable-local-sync-backend`. Directory settable using `--local-sync-backend-dir`
You can watch the data being synced via chrome://sync-internals
> > 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.
How on earth would that possibly be prohibited by their policies? Google's users using Google's service for personal use consistent with Google's terms is prohibited by their policies?
While that would be a great law to have I don't think it exists. If I make an API for my own client software and put in the terms that you can only use my system in the combination in which I provide it, I think you're out of luck.
The only law I can think of that could get involved is the DMCA. If my client implements usage/content restrictions (very stupid design) you using the API with another program in violation of the terms could be considered circumventing the content restrictions and that's illegal due to the DMCA.
You seem to be conflating the DMCA, which regulates copying of copyrighted material, and the CFAA, which criminalizes unauthorized access.
I don't think there is any case law related to "which client was used" applications of the CFAA.
I can't really imagine any reasonable circumstance where someone would be authorized with one client and unauthorized with another. It's not really a reasonable position; if you offer a free network service on the internet, and anyone is authorized to use it, I don't know of any legal basis for gating that authorization on "user of your software".
Perhaps some internet-clueless judge will one day disagree, but that's not how the mores and norms of the internet work today. Signal doesn't get to declare me a criminal if I write my own client software to talk to the Signal API servers (or use some other open source software I found), regardless of Moxie's squeaking. Either your service is public and open to everyone, or it isn't.
This is reminiscent of anti-scraping lawsuits: "you may only access LinkedIn using the LinkedIn web application; it is a violation to access it using curl". Ironically, Google's position in that regard is likely to bite them here, where someone else wants to use unconventional clients.
Just because you write it in your ToS doesn't mean that users agreed to it.
If your api is publicly readable (without any auth which you could only have by agreeing to the ToS), then whatever they write into their terms is irrelevant.
This doesn't apply here however, because you can only sync with Google servers if you have an account, which means you must've agreed to the ToS.
It's also the user that's breaking the ToS, not the developer of the competing browser... But that's irrelevant here in guess :)
after verifying on Wikipedia I can only conclude that you somehow misinterpreted my comment, as it addresses misuse of api by circumventing authentication, rate limits etc.
That's entirely unrelated to unauthenticated and public APIs and their possible ToS relevance.
That's not how it's been interpreted in courts in the past, they've taken it to mean that a violation of the terms of service can be a violation of the CFAA, https://www.rcfp.org/scraping-not-violation-cfaa/
Some cases have been found to not be a violation given a public API, but in the case of sync like this, it is not a public API. It's a public facing api but it requires authentication (the keys in question) in order to be used, this means that using google's keys without authorization from google to use them for that purpose would likely be seen as a CFAA violation by the courts.
If I run a service, I can add pretty much any requirements (barring anti-discrimination, accessibility laws, depending on your jurisdiction) I want for use of that service.
If I saw you can't use my service unless you do so while wearing a chicken hat and humming God Save the Queen, I have every right to do so and every right to kick you off if I discover you were wearing a turkey hat instead, because it's MY service. I may have a hard time enforcing such requirements, but nobody has a LEGALLY ENFORCEABLE RIGHT to use my service without my permission, no matter how dumb my requirements are to be granted that permission.
Note: The above obviously doesn't automatically apply to existing legally binding contracts such as with a paying customer, though in most cases either party is free to break the contact at any time assuming they are willing to pay the penalty specified in said contract.
Right, but their policy is that individual users can still get keys for personal use. So given that, how could individual users getting keys for personal use be a violation of their policy?
I highly doubt that an individual using software personally with their own API keys is against their policies. If that is the case, then why do they offer the API keys for "personal use" to begin with?
It reads to me like they're saying that him telling his users about it would be against the policy.
If you want to synchronize your bookmarks across devices and even browsers, you may want to look at https://www.xbrowsersync.org/.
It doesn't require registration. The clients you would like to sync just need to enter the same sync id and password. If I understand right, the password is used to encrypt your data on client-side. The server (called "service" in xbrowsersync lingo) only sees an anonymous sync id with a binary blob it can't read.
If a sync id is not used for a while, the associated stored data gets deleted. That's it. There is no "account" in the traditional sense. I really like this simplistic approach.
I'm using it and it works quite good. Every now and then sync fails, but I think I narrowed it down: It fails only when you create a bookmark in a just-created directory. But am not sure and didn't file a bug report, though.
> xBrowserSync does not only sync but also enhances your productivity by enriching your native browser bookmarks with the addition of descriptions and tags, and an intuitive search interface enables you to find, modify and share bookmarks quickly and easily. xBrowserSync even adds descriptions and tags to new bookmarks for you automatically.
Native Firefox is really good at this, in addition to bookmark and password sync. It also allows sending tabs from device to device and syncs plugins and configuration options.
I'll add that it works well across chrome/brave/firefox.
You can self-host it with 3d party https://github.com/ishani/xSyn
Which is written in go so it's as simple as running a binary.
I wish there was somethng similar for Safari. Love to sync bookmarks between my personal and work laptop without needing to use iCloud as I can't use my personal one on my work laptop.
Would a web page (that you could bookmark) you could browse from your work computer, rendered from your bookmarks, be a good replacement for your use case?
I don't understand why people are upset by this. The one reason I use Chromium instead of Chrome is reduced Google interception. If you really wanted Google sync you'd just use Chrome, why bother with using Chromium when you're going to let Google in anyway?
> If you really wanted Google sync you'd just use Chrome, why bother with using Chromium when you're going to let Google in anyway?
Because chrome isn't an option (for example on hardware a chrome build doesn't exist for), or your distro's package manager has a chromium package but not an official chrome package, or you want to apply a patch that isn't (and possibly never will be) merged upstream.
My guess is some people still think you can sip from the Google fountain without getting tainted. Sort of like people who think you can safely syphon gasoline by sucking on the end of a hose.
I can safely siphon gasoline by sucking the end of a hose but it didn’t come without gas in my mouth many times first. And don’t inhale you are priming it with creating a negative pressure in your mouth but don’t actually inhale. You should not be getting gas in your mouth if done correctly. I have had a lot of cars die on a full tank of gas and not wanting to waste have had my share of syphoning. A clear hose helps as well but often lack the rigidity to get around corners or bends before the tank. Now they have Gastapper a gas transfer pump that runs off 12 volts. It comes with everything to take that gas even the stuff needed to bypass the springs and such newer cars have blocking hoses.
This. Why use Chromium if you actually want to use the Google APIs pro-actively? If you are that kind of customer you should be using Chrome and not Chromium.
Geolocation. That's the only reason I care and I don't trust Google's implementation, but sometimes I'm forced to use Chrome/Chromium to access a site and some manager has decided geolocation is mandatory.
"Users of products that are incorrectly using these APIs"... This might be the right thing for them to do but what an incredibly arrogant way to word the e-mail.
it's a bad thing. Most users are going to ditch chromium for chrome which is precisely why Google is doing it. A browser without cross device sync is not going to have a meaningful audience.
A browser and its bookmarks are my personal window to the world, I wouldn't enable a feature like sync for love or money. What a crazy idea: hey ad company, here is everything I bookmarked that I wouldn't dare even mention to my closest confidants
Firefox Sync encrypts all data client-side; Mozilla has no way to read it. Chrome also supports client-side encryption as an optional feature using an additional passphrase.
FWIW, although this isn't on by default, Chrome can be configured to encrypt all sync data, either with your Google password (which Google hopefully doesn't store) or a separate, offline, password.
You're making an assumption that doesn't make sense. If someone is using Chromium directly on Fedora, chances are they know WHY they're using it and this won't have any affect on them other than switching to another browser or continue using Chromium without the sync features as they probably never used them to begin with.
Isn't Chromium exactly Chrome minus Google extras? I was under the impression that the difference between the two was exactly said Google-specific features that were apparently only cut off now.
Its chrome without the closed source bits. The syncing part was open source I guess but required an API key. I wonder if they could in theory just grab the key from chrome.
Well depends on your definition of open source. Most of the code for the sync, as well as these other internal APIs, is on Google's backend and is very much closed source. The thin client code calling these APIs may have been in Chromium, but as a general rule of thumb, I wouldn't really call Google Translate and Sync open source.
Google provides the code for Chromium, but I'm not sure why there's an expectation that they should also freely provide internal APIs which require backend servers. What other open source software provides such guarantees?
> I wonder if they could in theory just grab the key from chrome
I saw some discussion of that in the discussion group. I believe it would break their terms and services for distros to do it, not sure if an individual could on their own though.
I mean if everyone who used Chromium switched back to Chrome when they can’t sync to their google account anymore, why use Chromium at all? People who care enough to use the open source version deliberately probably won’t be sad to see this feature go. I know I never personally wanted to log into sync.
but make certain choices easier, much easier. just use chrome, it's just less of a hassle.
I dubbed this "convenience herding". nobody is forcing you to do anything; they are just making some things very very inconvenient relative to how easy it's to just put it all in their servers or use their software (the cloud is an euphemism for not your computer)
Yes, but they have been simultaneously making it very hard not to use their sign-in your browser and sync everything.
If they actually revert chromium to not having any of this, they have the problem that they are building a path that works for a lot of people and takes us further away from chrome. It will be politically bad if they dead end that path, but a politically bad end is not unlikely.
If I'm reading this right, it means the custom Chromium build I use[0] won't work like I want it to anymore. Although not required if you want to be "ungoogled" which many here do, I personally set up all the required API keys against my personal account as per their guide[1] so that Chromium works like Google Chrome as much as possible, since that's the browser I otherwise use. The issue is that now I can't have hardware-accelerated graphics on Chrome on Linux (since they refuse to put that in their mainline build[2]) and have it be synced in the same way as the official browser, since they're removing syncing from Chromium.
After reading the email[3] they sent out to Slackware devs, it's not clear if they are just removing this ability for builds that have keys built in, or if they are completely removing the ability to add your own keys to Chromium like I have in my example above. Could someone help clarify this?
It could allow transparent use of Firefox and Chromium data with the same account with history, passwords, bookmarks shared and the rest of the options and add-ons segregated by browser.
Firefox sync also has "Send Tabs", which -to me- is a great feature.
Yes. I'd love to see a Firefox Sync implementation for Chromium, which would make it easier for people who use Firefox but occasionally need to run Chromium to open something that doesn't bother to handle browser compatibility.
Brave Sync would probably be a better fit. Brave is already built on top of Chromium, it's open source, and they recently "rebuilt [it] to be more directly compatible with the Chromium sync system" [1]. It's also E2EE and doesn't require an account.
I think what you're describing are the "Tip" buttons which can be added on a few supported sites (which can be disabled). They aren't selling anything- it's a feature which people can use if they like.
The server implementation for sync is mostly compatible with Chromium and can be used without Brave. Someone could clone https://github.com/brave/go-sync and stand up their own server. It would require some patches on top of Chromium (similar to what is done in Brave) to implement the authentication - but once that is done, all of the Chromium tools like chrome://sync-internals work just fine
The service itself is open source and can be hosted by a community. It has a different authentication scheme (ex: not Google accounts) and enforces client side encryption by default. See https://github.com/brave/go-sync for more information
The official service hosted by Brave is only intended to be used with Brave Browser
Yeah. For users that had to worry about disabling these features for privacy, now they can rest assured the features won't work even if they wanted to.
To be fair, it's a helluva lot more work to reverse engineer the server implementation from the client than it is to build a client for an open source server.f
I don't need sync that badly. If enough people are fed up by Google's cut, they will probably build an open alternative soon...
But we can see a pattern: if you rely on companies (either as a paying customer or as a user of their open free APIs or source offering), you may be let down. Can't happen to open community projects like Wikipedia (happy birthday, btw!).
So a major reason (for anyone, certainly for me) to use open projects is continuity! Anythink proprietary can go anytime.
i'd be lovely to see a write up on what the implementation does, how it transfers data. is there grpc? i feel like there's going to be grpc. what kind of endpoints does it talk with?
can anyone find the old #xmpp based sync-code in the source code archives? it'd be fun to compare how sync used to work on the old semi-xmpp based platform versus how it works now. that this sync used to built somewhat around xmpp always fascinated me but i never dug in. there's got to be some neat interesting morsels in the code, around this, if we go looking for it.
there also used to be a very unsophisticated demo sync server one could run themselves[1]! i kept thinking/wishing people would take this & run with it, stop sending their core data to google, own the stack, own their systems, take responsibility, possibly expand & innovate openly on sync. it always seemed logical & obvious, but i didn't ever do it myself, & best i can tell, no one else really did either.
fwiw, the interfaces are part of the open source code[2], then & now, i believe, but the specific implementation is unavailable.
I occasionally get frustrated with bugs, missing features, or sites that don't work on Firefox, and toy with the idea of switching back to chromium, then there is stuff like this and manifest v3, and Firefox starts looking pretty good again.
Because I can share pages between my phone and my laptop with a few taps, without copy/pasting the links between different services.
Edit: just to clarify, I have an iPhone, and I run Linux on my laptop. Whenever I tried using Firefox on my phone, I had a bunch of problems with it, so it is quite limited what I can use to sync between my two devices.
Can't you just "share" the page via email, a messenger or a cloud drive? This is what I usually do. I use Vivaldi and Brave but I've never used sync feature of any browser I've used.
Same here. But the Katsura's comment suggests that's because we never tried. I use a messenger too but I wouldn't mind if this felt more seamless, required less clicks/taps but didn't come with extra cons like more unnecessary dependency on Google.
I have Android on my phone and sending a page to it isn't as seamless as I'd expect, like it sometimes either takes a while or I have to go in my Firefox Sync settings and force a refresh to get the page.
That... I should have thought of that a long time ago.
FF is great but the "send to device" feature has not worked for me in years. I suspect it got confused when I migrated my Apple profile to a new phone.
I hate to bring up the "don't be evil" mantra. That seems long in the past, however I do wonder what the impact is on hiring and retention.
Many people I know have certain moral beliefs that mean that they would never work for certain companies, examples would be:
- military
- pornography
- social manipulation (i.e. Facebook)
- work practices and worker rights (i.e. Amazon)
- proprietary approach (i.e. Apple)
- lack of open source contributions
I know I'm just one data point, but I've been turning down recent Google attempts to hire me precisely because of situations like this. And no, I don't mean just "Hey, we have a few openings, want to interview?", but specific requests because of my skillset.
If you would have told me 5 years ago that today I would hold this opinion of Google, I would have laughed in your face. Today, Google is in the same tier as Facebook, my never companies.
Floccus is a good self-hosted open-source alternative for syncing bookmarks across browsers. There is a docker available to use their WebDAV, or you can use your own.
Supporting non-standard configurations costs money (both in direct and indirect ways, such as developer attention and time lost triaging bugs, etc.), they don't want to spend the money on it.
All the major Chrome-like competitors like Brave and Edge already uses their own sync engine, so the only users they're punishing are the users of Chromium.
If you want to use a Google account and Google sync/other services you may as well just use Chrome anyways. To me the entire point of packaged Chromium is that it is Google-free.
It's entirely the point until it isn't, such as when you (or the distro package maintainer) want's to change something only available in compile time. E.g. up until recently I had to compile with certain options to be able to pass the runtime flag for native Wayland integration.
Or of course the many benefits of free software that many champion yet strangely never use and simultaneously become confused at when someone else do.
The number of times I've seen Reddit's r/linux users react with confusion to ire when someone actually makes changes to the source code to suit his own personal needs is bizarrely large.
This may be a positive in the long run. Google continues to disproportionately piss off people who the power to do something about it, by making Chromium less appealing. Of course many will go back to Chrome, but hopefully a significant amount of people will work on technology outside Google, making the internet a better place.
If you're not using Chrome proper, you likely have a reason for using Chromium, and Google's sync is not, by default, end to end encrypted (the key is derived from your Google account pass phrase which Google regularly has access to).
We really should be decoupling the use of Google software from Google services.
The difference is somewhat meaningless. It will be gone very soon regardless of what fedora does. Cutting it off early means they can time it with a release so people get the release notes rather than it just stopping working without having updated.
Isn't Brave yet another adware? I thought they had identifying tokens and were editing urls to put their affiliates codes? Or did they stop doing those horrors?
There used to be a Python sync server used in the Chromium project that was used to test sync functionality. Someone discovered this and yanked out the relevant code to enable self hosting.
Pretty sure Chromium based edge does not sync to google
> The reasoning given for this change? Google does not want users to be able to "access their personal Chrome Sync data (such as bookmarks) ... with a non-Google, Chromium-based browser.
I actually use this for having one google profile running in two browsers on one computer (one with a proxy, one without).
Sucks quite a bit as this is the primary sync system for Chromium. You can run your own but that is not quite that nice.
Didn't Microsoft replace all Google APIs with its own alternatives? This change probably will have bigger impact for other browsers built on Chromium, like Brave, Opera, Vivaldi etc.
It has been like that in (my) Linux for a long time? This isn't new by any means.
Lemme check.
Current version:
Version 88.0.4324.50 (Developer Build) Ubuntu 18.04 (64-bit)
It looks like I installed this OS in July of this year, which means Chromium would have been installed in July of this year - the 5th to be exact.
When started, it gives a warning about not having certain APIs and lacking functionality because of this.
It has done that since at least July of this year. I'm sure it did so before that, but I can only show that I've had this installed since July of this year.
This isn't even remotely new. Whatever version it was that I installed back in July did the same thing, or should I say didn't do the same thing? It hasn't had sync enabled since day one.
I currently have Lubuntu 18.04 and Chromium is installed by way of .deb channels - not a snap.
Most interesting to me is that even though the Chrome team specifically provided API keys for open-source Chromium builds to use back in 2013, they are now claiming that "the Terms of Service don't allow this usage, and [the previous developer] didn't have authority to change the terms."