I'm not sure if they meant that. Pretty sure that is standard and also works in os's where the link from the browser will be forwarded to the os, which directs to the default dialer application of the os.
That's right. The tel protocol is described in RFC 2806, which was written in 2000, although the proposal to make it an Internet Standard did not succeed.[1] It is certainly not a proprietary Google Chrome feature.
It may be referring instead to the Chrome feature that allows users to open tel links using their phone (from their desktop).[2]
Xmarks was great for that. It just worked, and I liked that it was independent of the browser in question, so the same bookmarks could be shared and synced with Firefox and Chrome. But it disappeared... we cannot have nice things!
xBrowserSync is not as nice (frequent full re-syncs) but still syncs bookmarks between Chrome & co. and Firefox. Had to switch to it after Xmarks was discontinued.
Vivaldi have their own accounts, and so does Opera and Edge. The biggest impact is for Linux distros which have Chromium in the repos, since they can't redistribute Chrome.
They can get it working but they choose not to because they want to be the source for all software. On fedora I can see chrome in the gnome software app and it says the source is googles own servers.
Personally I don't like these features, but can't this official move being seen as way to curve competitors?
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?
> 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
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).
> but can't this official move being seen as way to curve competitors?
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...
You're not really a "competitor" if you are using Google's sync backend, for one Google has no obligation to provide that to you for free, for two, if Google is storing and controlling the users data you aren't getting any value from it and the backend also won't be compatible with any feature changes you make.
It's good that Chromium is degoogle'd more, however did they really notice it thanks to an audit? Probably anyone in the organization could have pinpointed this situation existing for years. Or are they just fed up with the (somewhat) popular forks gaining traction? I understand Google's point of view but the phrasing it as a result of an external audit seems funny.
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.
Worked for years. Even showed up in the GCP dashboard as having access. Had no idea it “private”. We just plugged in credentials from Google as per chromium build instructions. They knew we and others were using it because there are stats.
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:
Buried in depths of their documentation? It’s also worked for years too. Google has docs that are completely outdated and neglected. Chrome Extension docs didn’t get updated for 5+ years until recently.
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.
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.
Yikes, if that's actually how they end up doing it, that's a big reduction in the amount of Chrome that is open source... Chrome has always been closed source but if they do that it's going to be quite far from Chromium...
Sad. I have often switched to Chromium whenever a Chrome update was breaking various websites I used. Chromium is lagging a bit behind in repositories; some delay is enough to let the website owners update. Then I can switch back to Chrome for that site once again.
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.
I don't think any web developer needs to be concerned. It's about chromium based browser developers, who will find their browser cannot use these private Google APIs anymore.
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.
Having recently tested the waters of Firefox after using chrome for the last 10 years. Firefox was just a faster, and better experience.
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.
You should be able to move them, just not directly sync them with Google. GDPR etc. took care of that. It's on the third party developers to make importing data as easy as possible.
The main reason for me to use Chromium was hardware accelerated video on Linux. Can they finally sort that out or force users into a degraded experience?
50 comments
[ 1.3 ms ] story [ 117 ms ] threadWhat 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...
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.
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...
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.
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.
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?
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.
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.