We may all have a disdain for Chrome – OSNews users probably use Chrome a lot less than the average public – but that doesn’t mean the browser doesn’t sometimes do interesting things other browsers should copy. Chrome is in the the process of increasing its release cadence, but getting users to restart their browser more often than they already do to apply these higher number of updates is going to be a problem. As such, Google is working on something that seems quite obvious now that they’ve talking about it:
Investing in “dynamic patching” that will eliminate the need for a full browser restart in most cases. By leveraging Chrome’s multi-process architecture, dynamic patching sequentially replaces background child processes (like the Renderer and GPU) with updated binaries on the fly. Stay tuned to learn more as we research and develop this feature.
↫ Chrome Security Team
Chrome was the first browser to use multiple processes, isolating tabs from one another so that if one website or tab went haywire, your other tabs would be unaffected. It makes perfect sense to have the browser use new, updated binaries for new tabs you open as soon as they become available, in a sort of ship-of-Theseus kind of approach to updating. Of course, you can’t postpone the inevitable forever, but this should provide real-world benefits to users. Neat.
The linked blog post goes into much more detail about other things too, like various low-level mitigations to prevent bugs and security issues from causing too much harm.
This definitely falls under the “I don’t like this program or the company behind it but I really like their ideas sometimes” umbrella.
A long time ago Google was an innovative company, it’s nice to see them actually innovating again. Too bad it’s for a browser that isn’t privacy-safe, but maybe this can trickle down to the better Chromium forks out there.
It’s worth mentioning that Chrome has finally received a version for AArch64 Linux, complete with Widevine running out of the box. A good solution for users of system other than RaspberryPiOS who want to watch DRM-protected media. A month late to the March announcement, but finally it’s available for a download using the direct link.
it’s going to be interesting when one process gets stuck on older version, files get corrupted by update or someone hijacks this mechanism for evil purposes.
all of which are going to happen, you know.
[email protected],
Yeah I think live patching is a bad approach for google to take here (assuming it’s what they actually mean and they’re not simply abusing the terminology). For OS kernels live patching is kind of unavoidable if you want the hardware to experience no downtime. However it’s rather risky while also being .limited in terms of the kinds of changes you can make. You’ll still have to reboot anyway at a planned time.
There is a better solution that doesn’t involve these risks or limitations, just like how we can migrate a running VM in real time to a new VM instance. The machine state persists and the VM software can be updated without limitation. The running state is effectively transferred from the old instance to a new instance that doesn’t have the bugs. IMHO this is the model Google should use for chrome. A user doesn’t care that the pre-patch and post-patch process must be one and the same. Just flip a switch when the migration is complete and kill the old process. Of course this takes some engineering, but amazingly it works!
Perhaps google did do it this way and someone just started conflating this with “live patching” even though there’s no live patching taking place.
Wondering why it took so long as code “hot-reloading” is a thing of the past :
https://www.youtube.com/watch?v=xrIjfIjssLE (starting from 7m to about 10m when the first call is still online)