I need to understand more the context. What do you need here? 
A) being able to get traces from another process (as the big title seems to suggest) 
B) being able to get traces from within javascript. 

If A, hjd and I already checked in a tool in
https://github.com/catapult-project/catapult/blob/master/tracing/bin/memory_infra_remote_dump

Which essentially relies on the existing devtools --remote-debugging switch and talks the websocket protocol (similar to the telemetry controller to be clear) 

If B : can you clarify a bit more why we need this? If we really need to, is there any way to expose the existing Chrome.debugger extensions API? 

Or, if really B, caseq : is there a way to expose the web tools websocket to js? I would like to avoid exposing yet another tracing API endpoint unless we really really need it 

To #1: it's B. The idea is we want to get trace within Javascript context in a page. We need this so that performance tests in https://cs.chromium.org/chromium/src/third_party/WebKit/PerformanceTests/ can also use trace data for detailed breakdown (see design doc in https://docs.google.com/document/d/1feawFQpadFCcXEsVqz9z7ucSBIQBgFc23z873g69rKc/edit)

So we're talking of tests that run in content_shell, right? We already expose TestRunner::ShowWebInspector (https://cs.chromium.org/chromium/src/content/shell/test_runner/test_runner.cc?rcl=6810f4a0e51ff154c73f1540772f8b65ce117acd&l=616) which in theory should be sufficient for what you're trying to do. This is how DevTools' layout tests work BTW.

caseq@: interesting! However, I would want to apply this for all chromium build, because we also run these tests in non content_shell.

Do we need to be able to start and stop tracing from JS, or do we just need a way to record a trace per page visited?

To #8: we need to be able to start & stop tracing from JS, because the code that compute metrics based on trace will be part of the JS test. This is so that people can just open test pages in webkit/PerformanceTests/.. in browser (with flag) & see results right on the page.

Ned, is running with --disable-web-security an option?
If that's the case I just realized you can just talk to devtools from within JS by just running chrome with:

--remote-debugging-port=5555 --disable-web-security
And then using a WebSocket on ws://localhost:5555

The websocket will allow to start/stop tracing and get the json back.

Running with "--disable-web-security" seems like an option to me. Though requiring users to also specify the devtool debugging port seems a bit inconvenient.

+esprehn@: thoughts?

> Though requiring users to also specify the devtool debugging port seems a bit inconvenient.
Can we just make a fixed choice in the test runner and hence, just tell people: the "official" devtools port for perf tests is 1234. hopefully that would be just a constant somewhere, right?

Specifying a fixed port has the risk of the port already been used. It's not a big problem for local workflow but a big one for bots, so we use ephemeral port in Telemetry. 

I wonder if we can make "--disable-web-security" also expose the devtool port number in somethings like "chrome.devtool_port".