Able to reproduce the issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #63.0.3239.108 and latest canary #65.0.3310.0.
This is a non-regression issue as it is observed from M50 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

--Chrome Identity automated triaging--

This bug is Untriaged and has gone for two weeks without any activity, so it is being moved to Available. 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

This is terrible. Bumping up the priority and assigning it to David.

Hmmm, why is this so terrible? Some flags are always per-device, not per-profile, right? And a user could always just create a new, non-Guest profile, and change those same flags from there, correct?

This feels like it should be P3.

I find it terrible that a friend could come over, I hand them a Guest session and they turn on/off features for my profile. I think in a Guest session the user should not be able to turn of features that may be only half implemented and that could affect the security of my browser.

Profiles (and Guest mode) are never meant to be a security feature. Your friend could just as easily click in the top-right corner, select your profile to open it, navigate to chrome://flags in your profile, and then change whatever they want. It's more a convenience feature than anything else.

I strongly believe this should be a P3.

>Profiles (and Guest mode) are never meant to be a security feature. Your friend could just as easily click in the top-right corner, select your profile to open it, navigate to chrome://flags in your profile, and then change whatever they want. It's more a convenience feature than anything else.

Well that's exactly what password-protecting your personal profile is for, except that such isn't a feature. Making excuses isn't the solution.

We do not provide password protection for profiles because it would give users a false sense of security. Once someone else has access to your local machine, there is nothing Chrome can do to protect you from that user. See https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- for a more detailed description.

In general, if you want to provide a truly secure "Guest" experience for a friend or someone else borrowing your computer, you should make use of OS-level profiles.

If you were to use a separate Windows user account for your guest, then how would it be anyhow possible to force Chrome Guest mode to be used?

--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

Any updates on this?

I tested this, and it has the same behavior in incognito.
I'm renaming the issue to reflect this.

Lowering to P3.
I don't think this is an important problem.

chrome:flags is somewhat of "hidden" feature with low usage, so the number of affected users should be extremely low.

I also don't think it is a security problem (especially on windows) for the reasons outlined by ewald. If someone has access to your computer they could just create a new real profile and change the flags from there. As a general rule, if your computer has sensitive data, you should not give unsupervised access to it to someone you don't trust.

The current behavior creates user confusion about the flags and incognito mode, as it is quite expected the if a flag is changed in incognito, the effect would not be seen outside.

What do you think about this solution: If user goes to chrome://flags in incognito, s/he would be redirected to a page saying that this feature is not active in incognito/guest mode?

Hi Alexei,

As flags_ui owner, what do you think about #16?

Or, we add a notification bar when redirected from incognito/guest mode to regular mode, to make it more clear to the user that the changes will be applied to the whole Chrome and not only the incognito.

It seems incorrect to say "this feature is not active in incognito mode" since flags do apply to incognito. It seems like maybe there could be a warning at the top that says flags apply to the whole browser and not just to incognito mode when opened from incognito?

+maxwalker

I agree.

Max,
What do you think? Do you see any UX issues with adding such a notification?

We have an existing pattern for features that aren't available to Guest users. Chrome pages like History, Bookmarks and Extensions show an empty page with a "... is not available to Guest users" caption. What do you think about using the same pattern for the Flags page?

Regarding the scope of enabling flags (from a regular or an incognito window), we already have a prominent warning that explains this in the header: "WARNING: EXPERIMENTAL FEATURES AHEAD! [...] Enabled features apply to all users of this browser".

Deleted: Not available to Guest users.png 48.4 KB

	Not available to Guest users.png 48.4 KB View Download

Deleted: Flags warning.png 66.5 KB

	Flags warning.png 66.5 KB View Download

Thanks Max,

I had not noted the text in the flags page. I think as:
 1- We already have a warning that changing flags affects all users.
 2- Guest mode has no security guarantees which results in limited access.
we can leave it as it as.

I close this one, if anyone believes otherwise, we will open it again.