The point of the post is that there is no way to opt out. We all understand more datapoints the better. But I also need to not be fucked with when I'm trying to work.
If you know the name of the field trial you should be able to opt-out on the command line provided you use the correct syntax with the --force-fieldtrials option.
However it was not established whether or not field trials (A-B testing) was even the problem merely that they existed on the chromium processes. Even the stable version of the browser will likely have these options on the command line.
> But I also need to not be fucked with when I'm trying to work.
But that's true of shipping any bug and isn't guaranteed to happen with a field trial any more than any new feature.
(and the OP doesn't seem to establish that it has anything to do with the field trial, just that the processes were run with that option? Admittedly I don't know how they actually work :)
I think the point is more about intentional performance degredation versus unintentional; it makes sense that you can't ship a 100% bug proof piece of relatively complex software, and some has to be patched out later, but such performance degredation or workflow interruptions can be planned for. But to intentionally enable an function which knowingly degrades performance or impedes workflows just for the sake of testing without the consent of the user is a bit rude. To repeat the author and other comments, if it were a beta-channel or test build where it was clear this was part of the intended functionality of the build, I don't think we'd be having this discussion.
Not to worry, chromium is open source. Just pop open a text editor and trace the code from the option parser to see where it's used. How hard can it be?
However it was not established whether or not field trials (A-B testing) was even the problem merely that they existed on the chromium processes. Even the stable version of the browser will likely have these options on the command line.