I would vote for using (1) for consistency & good security practice.

kraynov@ my main questions are:
- how does telemetry get the right port and GUID ?
- Why this is a blocker for us (remote_dump / telemetry_mini) but not for telemetry does?
- Why telemetry just works without 1 and we need 1 (or 2)?

+perezju

Re #3, it looks like the corresponding Telemetry change to make this work was:
https://codereview.chromium.org/2989413002

Also from that change it sounds like this does not apply to Android. So there is nothing to change (at least within telemetry_mini)?

Correct, Android target doesn't seem to be affected (hence telemetry_mini isn't affected as well). Yes, corresponding Telemetry change cited in the original description [4]. It reads $CHROME_PROFILE/DevToolsActivePort to get port number and GUID of browser instance.
But I'm concerned about 3 problems:
1. DevToolsActivePort is not being written if port was specified (not using a random one).
2. On my recent build faced a problem when PathService::Get(chrome::DIR_USER_DATA, &output_dir) return empty string which prevented me to fix (1.). Will check it again, likely I'm holding this thing wrong.
3. How many tools like [1] (memory_infra_remote_dump) are not expecting GUIDs in WebSocket URL? Tool [1] can be fixed very easily.

> 1. DevToolsActivePort is not being written if port was specified (not using a random one).
> 2. On my recent build faced a problem when PathService::Get(chrome::DIR_USER_DATA, &output_dir) return empty string which prevented me to fix (1.). Will check it again, likely I'm holding this thing wrong.

Not a devtools expert here (+dgozman@) but this sounds like a bug in devtools then.


> 3. How many tools like [1] (memory_infra_remote_dump) are not expecting GUIDs in WebSocket URL? Tool [1] can be fixed very easily.

I would guess this is something that devtools folks thought before changing that, hence not something we should worry about.
Specifically memory_infra_remote_dump is a best-effort binary which has no test coverage, so we took the risk of being exposed to braking changes like this here. Not sure there is any other action required other than: let's fix it.

How about an option (3) where you parse SYSERR and get the port along with the full socket address?

dgozman is going further than that and is suggesting to never use the DevToolsActivePort file, but rather parse syserr all the time!

Uh Pavel can you expand / provide pointers plz? What do you mean with "parse syserr"? 
That decodes to me like errno.h but I am pretty convinced you mean something else here 

I think they meant to parse STDERR? e.g. when Chrome starts and prints:

DevTools listening on ws://127.0.0.1:9222/devtools/browser/8f4d72fd-67cb-412e-805e-4c1c9be24d03

Downgrading P2s that haven't been modified in more than 6 months, which have no component or owner.