Limiting Private API Availability in Chromium
blog.chromium.org
blog.chromium.org
Especially looking at how the announcement is worded?
"This meant that a small fraction of users could sign into their Google Account and store their personal Chrome sync data, such as bookmarks, not just with Google Chrome, but also with some third-party Chromium based browsers. We are limiting access to our private Chrome APIs starting on March 15, 2021."
That I understand as "you can use the open source chromium version, but we did what was necessary to ensure that in all cases and derivatives it will be inferior to closed Chrome".
Maybe a next move could be to disable the possibility to use the chromecast from Chromium?
Alternatively, "you can use the open source chromium version or a derivative, but we won't operate as a free host for our competitors."
Regardless of their motivations, from my perspective this doesn't have any of the ethical questionability of actions like penalizing non-AMP pages; they seem to be well within their rights (and not in a "technically that's allowed, but they're still kind of shitty" way like some of the stunts that Nintendo pulls with copyright law).
What competitors are using chrome sync? Other comments mention Brave and Vivaldi, but they both have their own sync systems. Edge has Microsoft accounts, ungoogled-chromium has sync disabled completely...
Chrome is handicapped by the need to support Google's ad business. Open-source, and potentially freemium browsers do not have this limitation. Non-google browsers can block most trackers, auto-fill privacy settings to be the best for the customer and hell, maybe even auto-deny cookies for websites that function fine without them.
This makes the internet noticeably faster, but the con is that there is more browser lock-in than before due to features like stored passwords, credit cards, search suggestions and other tedious to enter information.
Now we are given 2 months to develop a completely new solution.
> Note that the keys you have now acquired are not for distribution purposes and must not be shared with other users.
> Many of the Google APIs used by Chromium code are specific to Google Chrome and not intended for use in derived products. In the API Console (http://developers.google.com/console) you may be able to purchase additional quota for some of the APIs listed above. For APIs that do not have a "Pricing" link, additional quota is not available for purchase.
The notice has been there since 2013, when the page was first archived:
https://web.archive.org/web/20131211101458/https://www.chrom...
Why put it in the console then? Why have tool tips that say “Access to this API is enabled.”
There’s no improvement to security. This will be a cake walk to reverse engineer.
I don’t see how my point is invalid.
You mean right in the instructions on how to acquire them?
> It’s also worked for years too.
It was tolerated for years, but it was always on very shaky ground. Now Google pulled the rug. I'm annoyed because that means my Chromium AUR package stops working, and I'll have to pry the tokens from a release build, but this isn't unexpected.
> Why put it in the console then? Why have tool tips that say “Access to this API is enabled.”
For outside developers who want to work on Chromium. This is also CLEARLY stated in their docs.
> There’s no improvement to security. This will be a cake walk to reverse engineer.
They didn't say it was about security.
maybe its good after all to have a different service that provides a private store ( in dropbox etc) for bookmarks.
Dropbox (and others) can take care of the syncing.
This has been happening more often lately, in my experience. Sure, you could say that the website is broken and not the browser. But from a user’s perspective, it used to work and now it doesn’t. Users don’t care whose fault it is.
But big corps don’t care if less than 0.1% of users are impacted. Even if that means 100,000 people. So it’s ok to break a few eggs.
As a website owner myself, I’ve had to make changes about once a year to keep things running properly in Chrome due to deprecated APIs. This is for a website that has not changed at all otherwise in 5 years, and I built without using any external dependencies so that I can avoid updating things.
Compare this with other environments: Windows apps usually can run for 20 years without issues; Linux apps even more. Not to mention document formats, like PDF, which are pretty much guaranteed to be accessible forever. Adobe got at least one thing right.
The only good thing I can say about this disregard for backwards compatibility is that it gives web developers good job security.
Browsers that don't use Google services (such as ungoogoed chrome, Vivaldi, and Brave for example) will be fine. A rebranded Google chrome fork will not.
I reread the article, but it doesn’t seem to state it explicitly.
Does this refer to standard Web APIs or Chrome-specific and more or less experimental interfaces?
What is this “Click to Call”?
Looks like you tap a phone number on a web page and it opens the dialer app
and it's probably a html living standard.
It may be referring instead to the Chrome feature that allows users to open tel links using their phone (from their desktop).[2]
1. https://www.ietf.org/rfc/rfc2806.txt
2. https://www.androidpolice.com/2019/11/05/chrome-beta-78-desk...
If you can’t move bookmarks, passwords, extensions, history, it requires more effort for the user to switch.
Not too mention, interop to sync on mobile.
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
Edit: Unrelated to what's above, but searching around I came across chrome://sync-internals/ I wasn't aware that existed in Chrome. It's a pretty complete admin type view.