Chromium Updater: Omaha 4
The Chromium Updater, or Omaha 4, serves as the mechanism responsible for automatic updates in browsers like Chrome and Edge, which are built on the Chromium framework. This guide offers a broad understanding of its functioning. Through a basic application example and an actual update server, we'll demonstrate how you can employ the Chromium Updater to update your software seamlessly.
How the Chromium Updater works
The Chromium Updater operates as a distinct application on the user's device. It autonomously scans for updates and installs them in the background at intervals of every five hours. Furthermore, it accommodates manual update checks upon request. As an instance, you can initiate a manual update check in Chrome by navigating to chrome://settings/help.
The Chromium Updater operates as a distinct application on the user's device. It autonomously scans for updates and installs them in the background at intervals of every five hours. Furthermore, it accommodates manual update checks upon request. As an instance, you can initiate a manual update check in Chrome by navigating to chrome://settings/help.
Operating as a separate application offers numerous benefits. Firstly, the Chromium Updater can execute updates even when the browser is inactive. Secondly, it can operate with elevated privileges, crucial for updating applications across the system. Thirdly, it's capable of updating multiple applications like Chrome and Google Earth simultaneously. Lastly, it has the ability to rectify broken application installations. For instance, if Chrome experiences severe issues preventing it from launching, the Chromium Updater can still function and restore its functionality.
When the Chromium Updater operates as a distinct application, it relies on each application to register itself for updates. This registration process involves storing associated information in different locations depending on the operating system. On Windows, this information is stored in the registry, while on macOS, it's managed through a configuration file. If you're interested, you can examine the configuration file for user-specific installations of Chrome located at ~/Library/Application Support/Google/GoogleUpdater/prefs.json. Within this file, you'll find an entry resembling the following: {"apps":{"com.google.chrome":{"pv":"123.0.6312.58" ...
This says that Chrome is installed at version 123.0.6312.59. Another application you will see listed is {44fc7fe2-65ce-487c-93f4-edee46eeaaab}. This is the entry which the Chromium Updater uses to update itself.
The background schedule of the updater for per-user installations is configured in ~/Library/LaunchAgents/com.google.GoogleUpdater.wake.plist.
This can for example look as follows:
When the Chromium Updater operates as a distinct application, it relies on each application to register itself for updates. This registration process involves storing associated information in different locations depending on the operating system. On Windows, this information is stored in the registry, while on macOS, it's managed through a configuration file. If you're interested, you can examine the configuration file for user-specific installations of Chrome located at ~/Library/Application Support/Google/GoogleUpdater/prefs.json. Within this file, you'll find an entry resembling the following: {"apps":{"com.google.chrome":{"pv":"123.0.6312.58" ...
This says that Chrome is installed at version 123.0.6312.59. Another application you will see listed is {44fc7fe2-65ce-487c-93f4-edee46eeaaab}. This is the entry which the Chromium Updater uses to update itself.
The background schedule of the updater for per-user installations is configured in ~/Library/LaunchAgents/com.google.GoogleUpdater.wake.plist.
This can for example look as follows:
<key>ProgramArguments</key>
<array>
<string>…/GoogleUpdater</string>
<string>--wake-all</string>
<string>--enable-logging</string>
<string>--vmodule=*/components/update_client/*=2,*/chrome/updater/*=2</string>
</array>
<key>StartInterval</key>
<integer>3600</integer>
This file specifies the path to the updater binary and tells it to wake up every hour. If five hours have not yet passed since the last run, then the updater simply exits. The file also enables logging. This is very useful for debugging. You can find the log file for Google's updater in its installation directory, at ~/Library/Application Support/Google/GoogleUpdater/updater.log.
<array>
<string>…/GoogleUpdater</string>
<string>--wake-all</string>
<string>--enable-logging</string>
<string>--vmodule=*/components/update_client/*=2,*/chrome/updater/*=2</string>
</array>
<key>StartInterval</key>
<integer>3600</integer>
This file specifies the path to the updater binary and tells it to wake up every hour. If five hours have not yet passed since the last run, then the updater simply exits. The file also enables logging. This is very useful for debugging. You can find the log file for Google's updater in its installation directory, at ~/Library/Application Support/Google/GoogleUpdater/updater.log.
Installing a new version
Upon execution, the updater references the initial configuration file to ascertain the installed applications and their respective versions. Subsequently, it transmits this information to the update server. Should a newer version be available, the server replies with the URL directing to an installer capable of updating the application. The updater proceeds to download and execute this installer, thereby updating the application to the latest version.
It's noteworthy that the updater doesn't require any specific knowledge about the applications it updates. Its functionality hinges solely on knowing the location of the configuration file and the update server. This design simplifies the process of integrating new applications into the updater, as there's no need for extensive application-specific configurations or adaptations.
Installers can manifest in various formats depending on the operating system.
Need Help? Ask us a question.
Upon execution, the updater references the initial configuration file to ascertain the installed applications and their respective versions. Subsequently, it transmits this information to the update server. Should a newer version be available, the server replies with the URL directing to an installer capable of updating the application. The updater proceeds to download and execute this installer, thereby updating the application to the latest version.
It's noteworthy that the updater doesn't require any specific knowledge about the applications it updates. Its functionality hinges solely on knowing the location of the configuration file and the update server. This design simplifies the process of integrating new applications into the updater, as there's no need for extensive application-specific configurations or adaptations.
Installers can manifest in various formats depending on the operating system.
- For Windows, they might be .exe or .msi files.
- On macOS, they could be .dmg files containing a shell script named ".install," among other possibilities.
Need Help? Ask us a question.
Once the updater has downloaded the updates, it stores them in the system waiting to be installed. At this time, if you go to the chrome://settings/help page, you will see a message that the updates are ready to be installed
Rent update servers
In addition to developing and hosting update servers on your infrastructure, we provide the option to rent an update server and use our reliable Omaha 4-enabled servers to update your product. This can be useful if you don't want to invest in your own infrastructure and save time like dozens of our customers. Get an update server.
In addition to developing and hosting update servers on your infrastructure, we provide the option to rent an update server and use our reliable Omaha 4-enabled servers to update your product. This can be useful if you don't want to invest in your own infrastructure and save time like dozens of our customers. Get an update server.
Client Update Protocol (CUP)
Current CUP communications are secured by an ECDSA key pair. The client has the public key hardcoded into the application binary. The server signs request-response pairs with the private key, and the client verifies using the public key.
In Chromium, CUP keys are rotated annually. Each key pair has a corresponding version number. To interoperate with old clients, the server must keep all historical versions of the key, and be prepared to sign with any of them. The client should only keep a single version (whichever was most recent at compile time).
Current CUP communications are secured by an ECDSA key pair. The client has the public key hardcoded into the application binary. The server signs request-response pairs with the private key, and the client verifies using the public key.
In Chromium, CUP keys are rotated annually. Each key pair has a corresponding version number. To interoperate with old clients, the server must keep all historical versions of the key, and be prepared to sign with any of them. The client should only keep a single version (whichever was most recent at compile time).
Summary
The Chromium Updater, alias Omaha 4, emerges as a robust, cross-platform solution for application updates. Through this tutorial, we've explored its functionality and demonstrated its utilization for updating custom applications.
We trust you found this guide helpful. Should you have any inquiries or feedback, feel free to reach out to us via the button below.