That only works if the apps are compatible with future releases of Chrome. If that was acceptable, there would be no reason to bundle a specific version of the runtime with each app. As several people in this thread have already pointed out, apps break between versions; this implies that the "security update plan" in practice will be to ignore security updates.
The app author controls the update channel. At their own pace, they'll bump up their Electron dependency to a newer version and make sure their app is still compatible with the latest Electron. When they're ready to release that new combination of app and Electron, they can push out the new version to everyone as an auto-update.
Where does Chrome come into it? Who will be ignoring security updates?
Consider the next time there is a serious vulnerability in Chrome. Maybe it's a TLS problem and network requests cannot be authenticated. Maybe it's a buffer overflow in something that renders data from a remote source. Chrome needs to be updated to a newer version immediately.
Is every app author going to push out an update that includes the latest Chrome with the relevant security fixes? Or are they going to irresponsibly leave the vulnerability unpatched until their app is updated to support the new version of Chrome?
The very idea of using old versions of Chrome (via Electron) - which is the stated reason for bundling Chrome with each app - tautologically means at least some apps will be using vulnerable versions of Chrome.
> At their own pace
That's the point; browser bugs don't happen at the app author's pace.
Jeez, I guess. In practice the Electron authors would presumably issue point releases for critical security vulnerabilities. If so, this is no different from shipping OpenSSL with your app and needing to get an update out for that.
