Chrome 137.0.7151.56 Windows 10 Unsandboxed Chrome profile is signed in, as expected. then Chrome profile won't automatically sign in (red box), not expected. Always working fine prior to updating to the latest Chrome version. I know it's something that changed in this diabolical browser
It's been happening to me for some time (months), usually after I haven't checked email for a while. I haven't yet determined the length of time before it does that, but it feels like 5 or so days have to pass without me checking and then it will ask. Edit: it has also happened after I've been logged in for many days in a row, checking email each day. That length of time seems longer, like 10 days in a row maybe? I hadn't really paid attention.
@DavidXanatos Again, it's happening on Chrome 138 https://youtu.be/UIDEljzmxb0 David, I'm frankly disappointed, tell me why are you still ignoring me. What's going on.
Sorry I was away the last 2 weeks and i missed the Therad in May. If the issue starts with a particular chrome version than its a change they did, that said doe sit work ok in a yellow or green box? If so that perhaps we need to allow some additional syscall in the red box.
Sure that is, all is good on Chrome 136 and previous versions. No, it doesn't work in any type of box.
not even a green box that is odd... are you using on the same machine one chrome sandboxed and one not, booth logged in?
Chrome 136 is installed (not portable) on the machine. Several profiles as usual on this machine. All profiles signed in as usual. If I run an unsandboxed chrome profile it remains signed in as expected. If I run the same chrome profile launched with a shortcut for SBIE, it works and remains signed in as expected. After I upgrade to Chrome 137 or now 138: If I run an unsandboxed chrome profile it remains signed in as expected. If I run the same chrome profile launched with a shortcut for SBIE, it says: "Verify it's you" Look: https://youtu.be/UIDEljzmxb0
and this happens also with a red one that has a full own clean copy of the profile i.e. no files shared or coped from/with host? How does it behave if you would not use the host instance only run chrome in the box log in verify etc and then re run it a few times? I think it may be something like chrom trying to avoid replay/session stealign attacks
Can't believe I'm the only one with this issue. I mean, it's Chrome browser, the most preferred browser by many. Hard to believe you David or anyone hasn't found the solution. I'm going to install on a spared SSD a Windows 10 system from scratch, Sandboxie and Chrome to see if it works or not.
Nope, it did not work. David I can't believe you haven't looked into this. What's going on? I don't think I'm the only one sbie + chrome user with this issue. Help please, I'm stuck on chrome 136.
I do not have a solution to that issue yet, it seams to only affect a very particular use case: A chrome profile shared between host and sandbox which is logged in into google. When the sandbox has an own profile it stays logged in, when the sandbox has a copy after the first repeated login it also seams to stay logged in, only when the sandbox has an open path on the profile each time then the profile have been used on the host something gets changed and the sandbox needs a repeated login. A green box with open COM also does not have this issue: Code: NoSecurityIsolation=y Template=RpcPortBindingsExt OpenIpcPath=*\BaseNamedObjects*\__ComCatalogCache__ OpenIpcPath=\RPC Control\OLE* #OpenIpcPath=\RPC Control\LRPC* OpenIpcPath=\RPC Control\epmapper Of cause this is not quite secure. So it seams chrome starting with 137+ uses some windows feature accessible through COM to safeguard the login token in some "more secure" way, one that fails when the com interface is sandboxed and possibly will fail for sandboxed tokens if the data is secured in the users scope. To attempt to resolve this issue I first need to identify the com interface used and then hope it will work for a sandboxed token, alternatively I would have to re implement that interface fully and proxy it through an unsandboxed user process. This is not a quick fix and I don't recall seeing other users complain about this behavior, it probably is not that common of a use case.
@Mr.X It took me the whole day but i have a solution for you, on the host system disable GoogleChromeElevationService, it is normally stopped but it starts for a second when chrome starts, when it is set to Startup Type: Disabled it can not start even when it wants to. This results in the existing chrome login on the host being broken, and requiring a re login, but the login token is stored without the service's help and remains valid for sandboxed com closed instances of chrome.
