The issue seems to be related to ForceEphemeralProfiles policy via Admin Console and GPO which is out of scope for ET. Hence adding TE-NeedsTriageFromHYD and requesting someone from Inhouse team to look into the issue, tentatively adding Enterprise component.

Thanks.!

Julian, would you know who to assign this to?

Thanks!

This is an unfortunate limitation of the way ephemeral profiles are implemented on desktop. The profile is marked for deletion when its windows are closed but only deleted on next start of Chrome. If the deletion is not happening even after restarting the browser the this should be treated as a regression. If the profile is deleted after browser restart than this is WAI. The profile is not available to Chrome right after its last windows is closed though even if other profiles are open at the same time.

norikob@ Could you respond to comment #4

This looks like we should have a conversation with Chrome identity

Comment #4 does not agree with the docs here:
https://support.google.com/chrome/a/answer/3538894?hl=en

Matt and Julian, how does that link and comment #4 reconcile? 

Good question. It looks like we may need to update the help center. I've created this bug (https://b.corp.google.com/issues/120507481) and assigned it to my colleague Lia Adams (AKA theflash@chromium.org)

Just remove the word "immediately" or replace it with "eventually" and it will be correct. :)

Thanks. With documentation being updated, I'm going to close this as Working as intended. Lia, please see comment #4 and ensure documentation updates reflect that.

Thanks everyone for the attention to this --- of course not the ideal implementation to not have the profile immediately deleted.   This might come back as a FR from others who would like to use the policy and have the behaviour be to immediately delete the profile upon closing.  

Noriko, I think the optimal behavior is to keep all data in RAM instead. If we do store it on disk like it is done now, nothing prevents a user from making a copy of it while it is still present or that files get locked by another application (e.g. an AV) and can not be deleted so the risk is still there. 

When I was building this feature a couple of years ago we were evaluating the option to create a RAM-disk like storage but we decided that the only way to achieve this (back than on Windows XP and 7) would have been a kernel device driver which was considered overkill for Chrome. A dedicated administrator that wants to make sure data is not persisted permanently can still install their own RAM-disk driver (there are a few available) and then redirect the Chrome profile there. 

That sounds like an even better implementation. By no means am I stuck on the how, just more about the overall outcome.  Appreciate the extra context.