Neither refreshing the page and restarting Chrome make the problem go away.

Erik, do you have multiple user profiles? The failure is in the Chrome install script:
https://chromium.googlesource.com/chromium/src/+/c5af6de2b6499645244d173f841b4013f3c60a56/chrome/installer/mac/keystone_install.sh

Mark, this is similar to what we chased a few months ago. The internal bug is b/25746117.

Do you mean OSX users? No. I'm currently logged in as an Admin, and there are no other accounts.

Thanks, Erik. Can you run ksdiagnostics and send the results to borisv@. I suspect that you had a system Chrome ticket for Keystone that was somehow downgraded to a user ticket.

Done.

Eric, can you see the permissions of the file "/Applications/Google Chrome Canary.app/.want_full_installer"? Also, please check the memory pressure on the system. The errors that I see from rsync itself are 11 & 12 are EDEADLK and ENOMEM. Note also that 11 was EAGAIN in the older implementations (according to the 10.10 SDK sys/errno.h header comments).

This is what I am seeing as the first error in the log:
mkdir: /Applications/Google Chrome Canary.app/Contents/Versions/53.0.2757.0: Permission denied
			.keystone_install: dirpatcher of versioned directory failed, status 7
			/tmp/KSInstallAction.mrWxPYIHMx/m/.keystone_install: line 558: /Applications/Google Chrome Canary.app/.want_full_installer: Permission denied

Please ignore error 12, error 13 is reported EACCES. I am still curious about the permission of the files inside the Canary installation folder.

			rsync: mkdir "/Applications/Google Chrome Canary.app/Contents/Versions/53.0.2763.0" failed: Permission denied (13)
			rsync error: error in file IO (code 11) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-47/rsync/main.c(544) [receiver=2.6.9]
			rsync: connection unexpectedly closed (8 bytes received so far) [sender]
			rsync error: error in rsync protocol data stream (code 12) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-47/rsync/io.c(453) [sender=2.6.9]
			.keystone_install: rsync of versioned directory failed, status 12

erikchen@erikchen-macpro ~ $ ls -alh /Applications/Google\ Chrome\ Canary.app/Contents/Versions/
total 0
drwxr-xr-x@ 5 root  wheel   170B Jun  2 10:45 .
drwxr-xr-x@ 8 root  wheel   272B Jun  2 09:32 ..
drwxr-xr-x  4 root  wheel   136B Apr 10 21:33 52.0.2705.0
drwxr-xr-x  4 root  wheel   136B May 31 21:38 53.0.2754.0
drwxr-xr-x  4 root  wheel   136B Jun  2 08:34 53.0.2756.0
erikchen@erikchen-macpro ~ $ ls -alh /Applications/Google\ Chrome\ Canary.app/Contents/Versions/53.0.2756.0/
total 0
drwxr-xr-x   4 root  wheel   136B Jun  2 08:34 .
drwxr-xr-x@  5 root  wheel   170B Jun  2 10:45 ..
drwxr-xr-x  10 root  wheel   340B Jun  2 09:28 Google Chrome Framework.framework
drwxr-xr-x   3 root  wheel   102B Jun  2 08:34 Google Chrome Helper.app
erikchen@erikchen-macpro ~ $ 

Hmm, interesting:

ls -alh /Applications/
"""
drwxr-xr-x@  3 root      wheel   102B Jun  2 08:57 Google Chrome Canary.app
drwxrwxr-x@  3 erikchen  admin   102B Jun 15 01:26 Google Chrome.app
"""

Thanks, Erik. This explains the problem - all of the files are owned by root, while you have a user ticket for the canary, hence user Keystone tries to update it. Maybe you had system Keystone ticket in the past, but then you removed the Keystone folder altogether?

I have no idea. I've manually deleted Chrome Canary and reinstalled. 

Given that this case is pretty easy to detect, could we add logic to detect this, and add a new error message to better describe the problem, rather than a generic error 12?

Well, if deleting of the Keystone folder happened, this is a situation in which the user has messed up the installation. In this case, enabling updates for all users simply fixes the problem. I wouldn't add more code to detect this explicitly - there are many other ways in which Keystone can be disabled by the user.

That said, there are other cases where the user is not explicitly deleting folders. E.g. if Chrome had a system ticket and Chrome is the only Keystone app. In this case, when Chrome is removed, the system Keystone uninstalls itself, leaving the ticket behind. Subsequent installations of Chrome fail with the same error 12. However, in this case we detect the issue and warn the user to elevate, showing a yellow bar with a button to fix it.

Hm. I had another device where the Chrome Canary version was also stuck on 53.0.2756.0. I've deleted it manually.

Did you delete the Canary or the updater, Erik? Deleting the canary should be ok. Deleting the updater may require that system ticket/system Keystone is installed again (via the 'enable updates for all users' button).
Please check with me when this happens again - at least send me diagnostic reports first.

I deleted Canary on both machines. The next time I see this I'll grab a diagnostics. [I assumed it would be the same as the other machine.]

Erik, I am resolving this as "won't fix", unless we find a scenario that causes it.