https://codereview.chromium.org/1512843002 attempted to lock --disable-web-security to --user-data-dir, but it didn't succeed.

Yes, ChromeContentBrowserClient::OverrideWebkitPrefs() now only sets WebPreferences::web_security_enabled to false if --user-data-dir is also set, buuuut *lots* of other places in the code *also* disable important security measures when --disable-web-security is used. And they *don't* check for --user-data-dir.

A search, https://cs.chromium.org/chromium/src/content/public/common/content_switches.cc?l=297&gs=kythe%253A%252F%252Fchromium%253Flang%253Dc%25252B%25252B%253Fpath%253Dsrc%252Fcontent%252Fpublic%252Fcommon%252Fcontent_switches.cc%2523yzLDik12y7C3QDFOB0AjN1JrDkgbZZ9tl%25252BCcVxrx070%25253D&gsn=kDisableWebSecurity&ct=xref_usages , finds that --disable-web-security is used to gate, in non-test code:

- CORS (content/browser/file_url_loader_factory.cc and others)
- origin checking (content/browser/frame_host/render_frame_host_impl.cc)
- CORB (content/browser/loader/cross_site_document_resource_handler.cc)
- origin checking in service workers (content/common/service_worker/service_worker_utils.cc)

and other places I don't understand. Clearly those people thought reading the switch was adequate, and it's not fair to blame them.

I see the only reasonable way forward to be *removing* the switch, so that future developers don't accidentally bump into this.