The information I find most useful (and what is included in the NetLog dump) is a serialization of the active field trial groups, as per:

   base::FieldTrialList::GetActiveFieldTrialGroups(&active_groups);

This lets you quickly answer the question of whether a particular experiment was enabled.

FYI the hashes on chrome://version can be decoded via go/finch-hashes internally.

The reason we show hashes are that studies are supposed to be blind - if a user knows an experiment they're in - they might behave differently. For example, if I see "NewSpellingSuggestionUI" in the list, I might be tempted to try to trigger it and try out. Which would show increased usage of the feature that is orthogonal to the feature itself.

The second reason is currently experiment names are considered potentially sensitive. Teams have expressed this last time this was brought up.

Note: The change to add the human readable names to net-internals was never reviewed and approved by our team. So it was a rogue feature. :\

Yeah, I suspected this may have been an intentional design choice.

I wonder if there could be some compromise? E.g. some chrome:// page that tells you the active group name if you fully type the experiment name? I feel like that addresses both issues somewhat.

There has been at least a few times when I have debugged an issue without easy access to the internal hashes (e.g. on mobile).

> Note: The change to add the human readable names to net-internals was never
> reviewed and approved by our team. So it was a rogue feature. :\

You were part of that discussion here:
https://bugs.chromium.org/p/chromium/issues/detail?id=426474#c7

If today's thinking is different the feature can certainly be amended, however it has been very useful when investigating network bugs.

My point regarding chrome://version/?show-variations-cmd is that the textual descriptions are already there, however the format is hard to search through.

eroman: Thanks - you're right it seems I was part of the discussion. Sorry for mis-stating things.

However, I think as part of that discussion, my assumption was that they would only appear in the net-log dump that users upload with bug reports, rather than in the UI. I think if that was discussed in more detail and I was aware that they'd show up in the UI, I would have pushed back.

The second point about it being in chrome://version/?show-variations-cmd is an implementation detail. We actually discussed making a change there for a different reason (sometimes the command line would be too long for Windows) that would hide them there too - i.e. providing a gzipped/base64-encoded string instead so it would be smaller.

By the way, as a specific anecdote about why it's harmful to show these to end users (not developers), read this blog post where the author sees some field trial strings in child process invocations and makes an incorrect assumption about them being the cause of some problems they were experiencing. Since then, we've changed how field trials are delivered to child processes so they wouldn't show up in this way (which had other benefits too).

Sorry, forgot to link to the blog post above, link to the blog post with the incorrect assumption about field trials causing the author's problem: http://raeknowler.com/wtf-chromium