As per comment #0, the issue seems to be a feature request. Hence, marking it as untriaged for further inputs from dev team.

Thanks...!!

This is a FR that's been coming up. Usually flags are reserved for experimental things and are temporary, which is why we are hesitant to make this happen.

There are also technical reasons why this is not easy to do (flags are loaded early on and are read-only).

We'll discuss this and see if we can come up with a plan that makes sense.

The organization I work for would like this as well.  There are some experimental features we want to leverage but pushing out flags or changing shortcuts for users is time consuming process.

#fill-on-account  is a big feature we want to take advantage of though it isn't an official feature yet.

I'm taking ownership to determine if we want to support this. Will update after we have consensus.

Hi,

We've discussed this and it doesn't look like something that should be supported. While we understand that setting flags across a fleet would be useful for some use cases, it also comes with some non-obvious but significant side effects.

Flags are not officially supported. They're intended for debugging and testing features that are in development, and as such, they are added, changed, and removed without notice, sometimes within a single release. Conversely, policies are supported and documented (see https://www.chromium.org/administrators/policy-list-3 and https://support.google.com/chrome/a/answer/7679408?hl=en) and are intended to be stable and predictable. A policy that directly controls flags would be built on an unsupported and shifting foundation. A policy like that might work when you set it, but may stop working or change behavior sometime in the future, without notice, and without explanation.

Flags may be dangerous. You'll notice that chrome://flags displays a prominent disclaimer: "WARNING: EXPERIMENTAL FEATURES AHEAD! By enabling these features, you could lose browser data or compromise your security or privacy." Having a policy to set them across a fleet would be a surface for such compromises, multiplied by each device in the fleet.

In general, features that admins would like to have control over should be implemented directly by policy, rather than through a flag enabled by a policy. This way, the behavior will be better documented, tested, and supported.

As such, I'm closing this specific bug as WontFix. However, the description more generally requests a way to stay on the latest version while disabling recent changes that cause conflicts with internal apps. This is a valid request, and something we're trying to support directly via policy. The enterprise release notes (https://support.google.com/chrome/a/answer/7679408?hl=en) list changes deployed in each version, and where applicable, describe how to revert to old behavior via policy. Hopefully this addresses your use case without resorting to flags.

Thank you for the update.  Hope those experimental features become features :)

Hi, 

We have a customer here who also sent a suggestion/request that the chrome://flags should not be available for stable channels since these functionalities are only experimental, these should only be available for beta or canary channel, in order to prevent any potential manipulation or bypass of certain policies.