Google has turned off access to sync features for Chromium | Hacker News Reader

Google has turned off access to sync features for Chromium

bodhi.fedoraproject.org

430 pointsstsewd184 comments

Here is the discussion on the Chromium embedder-dev mailing list: https://groups.google.com/a/chromium.org/g/embedder-dev/c/NX...

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

The way Google is communicating in that topic is downright horrible - like talking to a corporate robot.

Hiring Oracle managers is seriously starting to show it seems.

Don't blame Oracle for this. Page/Pichai sign off on these plans.

I highly doubt this decision went all the way up to Page or Pichai.

I would be surprised if, given the antitrust sensitivity around chrome, these decisions aren't being approved at a very high level.

That would ruin their plausible deniability.

My experience from other organizations:

* Corruption runs to the top.

* The top is very careful to communicate verbally, through implications, or otherwise.

Dunno about Google.

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.

Ultimately the buck stops there, regardless of whether they were directly responsible.

If this happened it’s because they built or facilitated a culture that does these things.

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

This is terrible. I've never seen a Googler get thrown under the bus so publicly by one of their own. Just doesn't fit the company profile.

Perhaps there is a new profile.

Just be evil™

There. Google can thank me later.

What do you think the company profile was? This seems very fitting to me. Google seemed nice last maybe 10 years ago or so.

It ver much looks like the Google people there have zero clue about what the actual issue is, as well as how to communicate about it.

The only reason given was literally ‘we suddenly want to enforce our policies’, which is really no answer at all...

It's more likely that corporate has decided it's a liability to reveal their exact reasoning.

I wonder if it'd be a liability if they wrote: "we think it'd be a liability to reveal our reasoning"

At least I'd find that more polite

They no longer need to lure new users in, so they're revoking their gifts.

Calling Chromium features gifts is a bit generous - they're more like bait.

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.

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.

Sad to see Google become the old Microsoft.

Yet more bait and switch by google.

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

> 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 already don't support Chromium. https://chromium.googlesource.com/chromium/src/+/refs/heads/...

(I mean, they're Google, they don't support anything that doesn't require payment from the user and barely that, but that's beside the point.)

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

Doing so with unauthorized software is against their policies

That's not how network services work. If a person is authorized to make the API call, the person is authorized to make the API call.

Service operators are not permitted in law to dictate client software, outside of copyright license terms.

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.

> The only law I can think of that could get involved is the DMCA.

The Supreme Court's upcoming decision in Oracle v. Google may also be relevant from what I gather.

That's not quiet correct.

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

Actually the CFAA would say otherwise as far as someone using it without agreeing to your ToS.

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.

> If a person is authorized to make the API call, the person is authorized to make the API call.

That's not how the law works today. Weev was still tried for accessing publicly accessible URLs.

Disclaimer: IANAL

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.

It's even open-source.

You don't need to use the default https://api.xbrowsersync.org service but can also host it yourself.

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.

Does it work with chromium variants, like edge?

What about for "collections"? Under the hood, it mustn't be so different from bookmarks.

Chromium variants: Edge support is planned for v1.6.0. (https://github.com/xbrowsersync/app/wiki/Roadmap) v1.5.2 is the current version.

Collections: Don't know, I'm not using collections.

Floccus works with chromium variants like edge.

https://floccus.org/

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?

Yeah, it's sad that the author of xBrowserSync seems to be against implementing Safari support.

Looks good but I hope this part is optional:

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

I'm not too fussed about bookmark syncing, I don't really use the native browser bookmarks.

What I really want is history syncing and the ability to see what tabs I have open on other devices.

I've been looking around a little and I haven't found extensions with that functionality yet.

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.

This seems like a great alternative for Linux/chromium users. Thanks for sharing

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?

Agreed. Seems like a small intersection of users who would be genuinely inconvenienced by this.

Like me? I liked tje idea of leaving a tab open on desktop to find it later on my mobile device.

The point here is if you are using Chromium and signing in with your Google account you might as well just use Chrome.

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.

Chrome does not have Arm64 Linux packages. On Pi I have nice browser in repo patched so hw video acceleration works.

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

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.

Especially given that Chromium distributors had previously been given explicit permission to use the sync APIs.

This is actually a good thing. People shouldn't be syncing ANYTHING with google :)

Let people choose what to do.

They can choose to use chrome I guess. If you don't trust chrome, why would you trust google sync to save all of your data to their servers.

Chromium has open source value besides "not Google".

Pushing people to take uninformed choices is a so-called dark pattern.

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.

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.

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.

There's still Google features in Chromium, just not the features google doesn't want anyone looking at the source of.

Here's a fork of chromium with the other google bits removed. https://github.com/Eloston/ungoogled-chromium

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.

> The syncing part was open source

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.

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.

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

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.

Google doesn't need to store it; you POST it to google.com several times each month. They can get it whenever they need it.

Sure. But they do also allow a completely separate password.

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.

It seems rather trivial compared to Google's being able to read one's emails or Imgur having access to one's finest and most artistic of dick pics.

> which is precisely why Google is doing it.

Is it? Is chromium use more than a rounding error?

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.

Are you sure it's so widely used? I've personally never enabled any kind of sync feature in a browser. I save my links elsewhere when I want to.

Definitely. This will make Chromium less annoying to use as it won't keep nagging me to login/sync with Google. Always hated that "feature".

I'm very happy with this change as well. I just wish distros would go with ungoogled-chromium in the first place. This would be a non-event.

People should be able to sync however they want.

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?

[0] https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-...

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

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=463440

[3] https://groups.google.com/a/chromium.org/g/embedder-dev/c/NX...

The video hardware acceleration decode is finally in 88. It is behind a flag that you have to enable in chrome://flags, but it is there.

Things may continue to work:

> we'll limit the quota to the quota for development

It remains to be seen whether new API keys will be able to be generated.

Firefox have video acceleration on Linux, and it works great for me.

[2] is a really old bug. It should be enabled behind the #enable-accelerated-video-decode flag

Would Firefox Sync be an alternative?

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.

Potentially, but when I looked at Firefox sync to see if I could implement a custom version, the spec was kind of crazy complex.

GNOME Web has implemented it though, so that could give some hope that this is feasible for Chromium as well.

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.

[1]: https://support.brave.com/hc/en-us/articles/360047642371-Syn...

Brave will sue you if you try to use its services with a different browser. https://twitter.com/BrendanEich/status/1269890055822118912?s...

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

Brave literally injects code and alters the UI of sites you visit to sell dubious cryptocurrencies.

It boggles my mind when people recommend Brave in a privacy/security context.

> Brave literally injects code...

Source?

https://brave.com/tips/#:~:text=When%20you%20visit%20Twitter....

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

This is great. Never understood why that proprietary system was in Chromium to begin with.

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.

If the client implementation is public then there’s nothing stopping you from developing a server.

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

> There is no good reason for Google to do this, other than to force people to use Chrome.

Sounds like a good reason (for them) to me!

I've not used Chrome or Chromium for a while... nowadays it's between Safari and Firefox for me.

I'll keep using Chromium rather than Chrome.

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.

Just use Firefox, instead of contributing to ChromeOSiffication of the Web.

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.

[1] https://superuser.com/questions/614744/how-to-set-up-a-own-c...

[2] https://www.chromium.org/developers/design-documents/sync

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.

Previously on HN:

https://news.ycombinator.com/item?id=25801113

Why would anybody insist on using them? Isn't there enough of 3-rd party cross-browser bookmark/passwords/whatever syncing tools available?

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.

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.

I just share whatever I want with myself in Telegram.

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 alternatively do the same with Signal and the "Note to Self" conversation.

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

uh huh. 'proprietary approach' would exclude the majority of software companies in existence

It does. But there is still the other minority that one can work for.

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.

Embrace. Extend. Extinguish. All of this has happened before, and all of this will happen again.

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.

https://floccus.org/

This makes sense from a support point of view.

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.

>This makes sense from a support point of view.

Support? Isn't this google we're talking about?

they need two whole server racks to process the auto-delete function that runs their support email backend ;)

Do you expect Google (or any other publicly traded corpo facing pressure from shareholders) to finance hosting of competing products?

I don't think it's a reasonable expectation from US corporations so we need to take their marketing with a grain of salt.

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.

What support does Google offer for this?

There's nothing non-standard about this. The API keys to enable this functionality were provided by Google itself in 2013.

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.

This is probably a good thing.

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.

Huh? The title seems inaccurate to me, considering the page says:

> Google isn't shutting off the API access until March 15, 2021, but I have gone ahead and disabled it starting with this update.

So it seems to be that Fedora has turned the features off early, and Google has not (yet).

(at the time of writing the title says "Google has turned off")

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.

I won't miss sync (I don't use it), but I'll miss the Google Translate feature.

Does this mean Chromium will be "ungoogled"[0] by default?

[0] https://github.com/Eloston/ungoogled-chromium#key-features

Wait? There are people that willingly upload all their browser data to Google?

Does that means chromium people start to integrate with mozilla sync?

Time for you all to switch to Firefox or Brave like the rest of us!

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?

The affiliate autocomplete problem was acknowledged as a mistake and removed. More info at https://brave.com/referral-codes-in-suggested-sites/

thanks for the update

Is the sync protocol documented? Can you just use an alternative server of some kind?

Does vanilla Chromium try to sync at all now? Does it silently fail, loudly fail, or just never try?

Looks like it is? https://www.chromium.org/developers/design-documents/sync

And even if not, since the client is OSS, it can be inferred.

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.

https://github.com/infeeeee/chrome-sync-server

Though its since been replaced by some c++ fake server. https://chromium.googlesource.com/chromium/src.git/+/refs/he...

I only recently switched to the Brave browser. I guess this will affect any Chrome based browser?

I predict next comes cutting them from access to the play store.

No. Brave has its own sync and doesn't use Google services for that. This change mostly affects open-source chromium packages in linux distros.

I wonder if this is a reaction to Chromium-based Edge overtaking Internet Exploder as the most popular Microsoft browser.

Edit: I guess maybe not.

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.

Pretty sure Opera, Vivaldi and Brave does not sync to google servers. The syncing to their servers will still work fine AFAIU.

Yeah as far as I know every major Chromium browser has their own system. Why would they want to use Google's system?

Chromium would have to safely store and manage user data on their servers, which is an additional cost.

Can't speak for the others, but Brave uses it's own sync system and is not affected by this.

Vivaldi syncs with their own servers, and it syncs a lot more data - such as notes - like in the Opera 12.x days.

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.

Instead of running Chrome and Chromium, try Chrome and Chrome Beta (or Dev/Nightly)? You can run the same profile in both and have two instances open.

Thanks for the tip, worked like a charm. I was worried that the icons would be the same, but they are not, so it is same user experience basically.

What about chrome webstore access for chromium or other chromium based browsers(edge, brave, vivaldi, etc)

What to use for syncing between Chromium (Ungoogled) and iOS?

I was never interested in syncing to Google in the first place

firefox

It's really just bookmarks I'm missing.

Besides, Firefox isn't all that well integrated with iOS either

Does it mean the end of browsers like Brave?

Brave doesn’t use googles sync

No.

Is there a complete list of APIs?

I wish that they would remove everything Google related in Chromium... that's a start...

why don't the chromium forks switch to firefox? or is it that doing so would hurt their egos?

Man, the "don't be evil" days seem like so long ago.

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.

Reply on news.ycombinator.com