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 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.
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.
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.
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.
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.
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.
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."
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.
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."
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.
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 :)
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.
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.
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
"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.
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.
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.
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.
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.
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.
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.
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.
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?
> 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.
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.
> 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.
> > 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.
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.
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
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
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.
188 comments
[ 2.4 ms ] story [ 256 ms ] threadEdit: I guess maybe not.
> 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.
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 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)
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.
Here's a fork of chromium with the other google bits removed. https://github.com/Eloston/ungoogled-chromium
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.
Is it? Is chromium use more than a rounding error?
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."
Hiring Oracle managers is seriously starting to show it seems.
* Corruption runs to the top.
* The top is very careful to communicate verbally, through implications, or otherwise.
Dunno about 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.
If this happened it’s because they built or facilitated a culture that does these things.
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.
There. Google can thank me later.
The only reason given was literally ‘we suddenly want to enforce our policies’, which is really no answer at all...
At least I'd find that more polite
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.
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 :)
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.
Support? Isn't this google we're talking about?
I don't think it's a reasonable expectation from US corporations so we need to take their marketing with a grain of salt.
https://news.ycombinator.com/item?id=25801113
Does vanilla Chromium try to sync at all now? Does it silently fail, loudly fail, or just never try?
And even if not, since the client is OSS, it can be inferred.
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...
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.
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.
> 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")
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.
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
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.
What about for "collections"? Under the hood, it mustn't be so different from bookmarks.
Collections: Don't know, I'm not using collections.
https://floccus.org/
> 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.
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.
[0] https://github.com/Eloston/ungoogled-chromium#key-features
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.
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.
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.
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).
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?
(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.)
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.
> 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?
Service operators are not permitted in law to dictate client software, outside of copyright license terms.
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.
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.
The Supreme Court's upcoming decision in Oracle v. Google may also be relevant from what I gather.
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 :)
That's entirely unrelated to unauthenticated and public APIs and their possible ToS relevance.
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.
You can't have an account without agreeing to the ToS, so it's definitely a violation.
That's not how the law works today. Weev was still tried for accessing publicly accessible URLs.
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.
It reads to me like they're saying that him telling his users about it would be against the policy.
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.
[1]: https://support.brave.com/hc/en-us/articles/360047642371-Syn...
The official service hosted by Brave is only intended to be used with Brave Browser
It boggles my mind when people recommend Brave in a privacy/security context.
Source?
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
https://floccus.org/