This would indeed be surprising, especially considering the underlying implementation.

I'm not able to reproduce this in either Chrome 61 or Chrome 62. Can you please upgrade to a current build and retry?

(Also, at step #5 and Step #6, can you please be specific about how you are exiting guest mode and how you are entering it again?

Just upgraded to Version 60.0.3112.90 (Official Build) (64-bit) (uptodate)
Still can reproduce the vulnerability.

update in step #5 and step#6
step #5: Exit guest by either click at guest and click at "exit guest" in drop down, or just close the guest browser window by clicking close "X" icon.
stpe #6: From the normal browser, click at guest icon near minimize button.

PS: Just for clarity, attaching file which shows current version and altering flash permission to allow.

Hope you find it useful.

Deleted: chrome_version.JPG 15.4 KB

	chrome_version.JPG 15.4 KB View Download

Deleted: chome_secure.JPG 28.5 KB

	chome_secure.JPG 28.5 KB View Download

Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm still unable to reproduce this in Chrome on Mac or Windows. 

The only way I can find to reproduce anything like this is to open *two* guest Windows, then exit only one of them via the red [X]. When any Guest window was left open, choosing Guest again from the non-Guest instance's Profile dropdown menu simply switches to an active Guest window in the same session as the closed Guest window. However, choosing "Exit Guest" from the Profile dropdown menu, it closes ALL Guest windows which means that the behavior you're seeing remains unexplained.

Steps to reproduce included as snapshots for ease.
Version 60.0.3112.90 (64bit) (latest uptodate for windows)
Steps reproduced in 4 steps for reducing number and size of attached files.
PS: No multiple guest windows used at same time.

Deleted: step1.jpg 48.1 KB

	step1.jpg 48.1 KB View Download

Deleted: step2.jpg 93.2 KB

	step2.jpg 93.2 KB View Download

Deleted: step3.jpg 55.6 KB

	step3.jpg 55.6 KB View Download

Deleted: step4.jpg 104 KB

	step4.jpg 104 KB View Download

Could you also confirm that you do not have any extensions installed?  Thanks.

No extensions installed. 
And if extensions supports in guest mode, it will make the private(guest) browsing baseless.

Thank you for providing more feedback. Adding requester "tsepez@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I can reproduce this on a Mac. Note the permissions were cleared when I restarted Chrome.

This only happened with Guest profiles, not incognito. Maybe this is WAI? If you want private browsing, that's what incognito is for.

+msramek - do ou think is this a privacy problem?

I consider it as privacy and security problem.
2 cases added below:
case 1:
A guest opens a website and changes a permission.
Next guest can check whether previous guest opened this particular site by checking the permissions which still persist.

case2:
Allowing pop-up, camera, JS, Flash etc for particular sites can be harmful for next guest.

Assigning to timloh@ and upping priority. msramek@ - please feel free to reassign / investigate / correct what I've said below if I'm misunderstanding.

I understand the concern.

The question is whether the expectation of guest mode is that shutting the last guest mode window is sufficient to wipe all user data. That is certainly the expectation of incognito, but I personally don't know if that is the expectation of guest mode.

Note that once on a computer you can see complete history, permissions etc. for all normal users. It could be reasonable to think of guest sessions as temporary profiles with some lifetime (e.g. session / browser process), in which case the current behaviour could arguably be defended.

Reading our public support page [1] it seems like the expectation is that exiting guest mode does remove all data, so it looks like this is a bug. In which case it is a worrying bug as there is probably other data being left around (e.g. local storage). 

[1] https://support.google.com/chrome/answer/6130773?co=GENIE.Platform%3DDesktop&hl=en

also security sherrifs - feel free to remove security restriction / change priority / set severity / do all the stuff you do :)

I can't reproduce this on my Mac, so this is a regression.

This is certainly not expected, and a privacy issue. Guest mode should not carry over state between sessions, let alone pieces of browsing history. Clearing on browser restart is not good enough.

Since guest mode is an Incognito profile over an empty persisted profile, this could be even a symptom of a larger problem, e.g. content setting writes from Incognito getting through to the normal profile. rahshancp@ or benwells@, could you maybe test that?

Given that we had a recent bug report about what looked like extension content settings leaking to user preferences, I wonder if it's related.

(that was  issue 750470 )

msramek@ benwells@
Issue occurs only in guest and not in incognito.
This should surely considered as a bug as guest is more private than incognito (incognito carries data like auto-fill, bookmark etc from user and guest wont carry anything).
And, this data clears when the "normal profile" exits. Which means it is getting through normal profile.
I assume this bug stores guest data (like SSL certificate permission) somewhere and not clearing, which can be be found somewhere in Appdata files which makes browsing history can be viewed by anyone who can find that file.

> This should surely considered as a bug

Yes, it is a bug.

> Which means it is getting through normal profile.

Not necessarily. It's possible that there's an in-memory cache or some other structure which isn't cleared. For instance, if the "Exit Guest Mode" command wasn't effective because a background process didn't exit, you'd see this bug.

Since you're able to reproduce this and I'm not, can you experiment to see whether the permission changes you're making in the Guest mode instance in any way "bleed through" to the normal profile? e.g.

0. Visit https://www.google.com in your normal profile and verify Flash is set to ASK.
1. Enter guest mode.
2. Visit https://www.google.com in Guest Mode
3. Set Flash to Allow.
5. Exit the Guest mode.
6. In regular mode, revisit https://www.google.com
7. Is the permission setting for Flash "Ask" or "Allow"?

>Not necessarily. It's possible that there's an in-memory cache or some other structure which isn't cleared.

I agree with you.
I can see a size variations in cache folders of guest mode when regular mode exits.(*\AppData\Local\Google\Chrome\User Data\Guest Profile)

The changes in guest mode is not reflecting back in regular mode. The changes persist only in guest modes, which clears only when regular mode exits.
I already tried the steps you mentioned. "Allow" gives in guest mode stays only in guest mode.
My current Version 60.0.3112.101 (may be you can reproduce in this version of windows) 


## Can you forward link to source code of incognito in chromium git?
   Just to compare with guest code :) 

Re #18: Thanks. So it doesn't look like things are bleeding from Guest to Normal, so much as failing to clean up the Guest profile at the expected time.

> Can you forward link to source code of incognito in chromium git?

Alas, the architecture isn't that simple. :) 

Whether a profile is "Guest" or not is tracked via a flag: https://cs.chromium.org/chromium/src/chrome/browser/profiles/profile.h?l=371&rcl=ab2028c1af8aef294c759cb832e40b8add559746

Most locations check a IsOffTheRecord flag which encompasses both Guest and Incognito modes. If a caller wishes to distinguish between them, additional checks are required: https://cs.chromium.org/chromium/src/chrome/browser/ssl/security_state_tab_helper.cc?l=51&rcl=ab2028c1af8aef294c759cb832e40b8add559746

The ProfileDestroyer is another interesting piece of code: https://cs.chromium.org/chromium/src/chrome/browser/profiles/profile_destroyer.h?sq=package:chromium

Hope you consider about the bug and fix it.
:)

PS:Thanks for links.

Bisect gives https://chromium.googlesource.com/chromium/src/+log/8bd4bd7..476d674, so presumably this was fixed by https://chromium.googlesource.com/chromium/src/+/86b6bc73fe which will be in M61 but not M60. Not sure if there's anything else to do here, maybe just close as WontFix?

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

msramek: can we mark this as fixed now as per #23?

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Assigning back to myself. Sorry, I meant to verify the statement in #23 when 61 Stable came out, but never got around to it.

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

msramek: I'm guessing it's safe to mark this as fixed based on the previous comments, but please reopen if there's still work to do.

I'm afraid the VRP panel declined to reward for this bug. Thanks for the report!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot