Node: chrome devtools appspot.com? security concern!

[MasterJames]

_Nodejs: 8.1.3 on Ubuntu Server and Chrome: 60 on Windows_

I noticed when using chrome devtool that if you visit this site chrome://inspect/#devices
When I run a VM with nodejs it will appear in this list.
I noticed if you follow the 'inspect' link it opens a dedicated window (I don't want that I want them it tabs can't get the link etc).

Still it shows remoteBase=chrome-devtools-frontend.appspot.com
I was deeeeeply concern about this!
I went as far as to add it and it's tld to my 'hosts' files successfully blocking it from the VMs, because of concerns nodejs is sending something abroad?!
I also did the same from my chrome devtool desktop which the VMs are running via VirtualBox, multiple Ubuntu Server instances with multiple nodejs instances forked for the number of CPUs.
Still bizarrely it is able to open the link? and access the nodejs server instance in the chrome devtools (dedicated window? I prefer tabs ) inspector.

All I really want is to set on CLI or disable the access string at the end of the url you see when using node --inspect.
And see all the inspectors in TABS not multiple dedicated windows of the chrome devtools.
The other problem or reason for all this is I loose the dev link shown at launch because of all the logging that spews when it starts, but also because of forked instances for the multple per machine CPUs so the logs of multiple versions of nodejs are stacked in the Ububtu console pushing away debug links.
I could also write my logs to other files tail egrep for the links and dump them to a separate file to see the coded link etc. [ also excessive and painful for what it is ].
I can see it's kind of a rare usage most people probably have 1.

Anyway now you understand the situation better you might start rethinking all this madness?
Is there a concern that there's this appspot.com involved? Again I totally blocked access via hosts files pointing to 127.0.0.1 so host not found pinging, but the inspect devices panel still works with remoteBase in the inspect URL.
I'd like someone to explain what the heck appspot is doing and therefore reassure it's not an invasion of my privacy. (Even just when I launch node is a disturbing thought for me.)

When developing I'd like to not need the stupid secure random string in the url as long as the whole world doesn't have access through some weird appspot server etc. while I'm developing?

Please help me to understand this better, thanks. Also consider my use cases and possibly consider the option to at least customize by including the secure part of the url when launching (and allow all instances to have the same one). It complains about the port if I add a path to --inspeck(-brk)= where I'm suggesting it should go. Finally what code can I hack for a PR to make it so?

[refack]

/cc @nodejs/v8-inspector @nodejs/diagnostics

[benjamingr]

Hey, thanks for raising that question, and I am sorry Node did not communicate what is happening more clearly.

Basically, since your version of Node runs independently of Chrome - whenever you debug a specific Node version - opening the debugger will grab a version of the DevTools you're using from Google.

Note that this will happen when you enter the devtools - and no download will happen from Node's side (in general, Node speaks to third parties only when you explicitly request it).

Now that the debugger protocol is more stable - this might not be required - (see https://github.com/nodejs/node/issues/11910) but it sounds completely reasonable to me.

This is just a version of the devtools frontend UI. It is a hint to Chrome on what frontend to use - and it enables the good debugging experience the new debugger has.

You can debug with VSCode, WebStorm or any other tool that understands the debugger protocol without using about:inspect.

[benjamingr]

In addition - if after the explanation you are still unhappy about what Node is doing here in order to get the debugger to work. I'd like to emphasize that the project is always open to discussing these things and to contributions.

I think a documentation change here explaining what people are seeing and asserting Node does not itself talk to third parties like that from your code might be in order.

Since you mentioned writing a PR - If you would like to get started with contributing code to Node (with or without regards to this issue) and would like assistance - let us know and we'll find someone to pair you with to make the on-boarding smoother :)

[MasterJames]

Okay well I still don't get why it works with the site blocked (via hosts entries) it's as if Chrome does it's own fallback for DNS lookups, which on one hand sounds great but also seems really wrong to me as well?, if it's doing that to get there even though I've resolved *.appspot.com to localhost 127.0.0.1?!

It seems like it uses an external server to find the correct auth token that is in the URL (so it reloads automatically when restarted, very cool.), so it must send this per launch access token to appspot.com even though I've blocked it, so maybe it sends it to another domain I'm unaware of which to block.

Otherwise okay so what your saying is it's trying to get a possible update to a nodejs version specific devtool version, which it doesn't need and can't be getting since I blocked it. Still it gets access to the node server? remains mysterious to me or it's all unnecessary overhead, and the url that the inspect panel opens is essentially bogus, again I've blocked the domain and pinging resolves locally and the domain shows appropriately not found via browser.

I've hunted for the code obviously in C I swore I'd never need to touch it since the early 1980s and that remains true so not beyond me more desired and categorized as beneath me.
searching repo for PrintDebuggerReadyMessage
https://github.com/nodejs/node/blob/6e2c29bcabb0507262167494a1fd9bc583cae690/src/inspector_socket_server.cc#L102
really here
https://github.com/nodejs/node/blob/6e2c29bcabb0507262167494a1fd9bc583cae690/src/inspector_socket_server.cc#L428

I'm guessing on GetTargetIds but really that's going to need a link to a modified --inspect argument.

Tracing breadcrumbs to to targets_
https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/test/cctest/test_inspector_socket_server.cc#L121
Seriously isn't somebody else familiar with this?
targets_ created here...
https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/test/cctest/test_inspector_socket_server.cc#L152
Now maybe it's target_id so StartSession?
https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/test/cctest/test_inspector_socket_server.cc#L98

Now it seems maybe that's called here...
https://github.com/nodejs/node/blob/6e2c29bcabb0507262167494a1fd9bc583cae690/src/inspector_socket_server.cc#L301

so actually SessionStarted? called here...
https://github.com/nodejs/node/blob/6e2c29bcabb0507262167494a1fd9bc583cae690/src/inspector_socket_server.cc#L531

so HandshakeCallback path?
https://github.com/nodejs/node/blob/6e2c29bcabb0507262167494a1fd9bc583cae690/src/inspector_socket_server.cc#L523

called from? no passed to inspector_accept
https://github.com/nodejs/node/blob/6e2c29bcabb0507262167494a1fd9bc583cae690/src/inspector_socket_server.cc#L512

Okay so it feels like this isn't getting me there or I wized past https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/src/inspector_socket.cc#L562

hunting on http_parsing_state is state here...
https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/src/inspector_socket.cc#L399

Looks like maybe the string is stored in SEC_WEBSOCKET_KEY_HEADER? no that's just the header not the value?
I guess the "at"tribute is set on 405 https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/src/inspector_socket.cc#L405

via header_value_cb
https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/src/inspector_socket.cc#L396

That seems to be used only here https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/src/inspector_socket.cc#L557

during init_handshake
https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/src/inspector_socket.cc#L545

This is going no where...
https://github.com/nodejs/node/blob/1b7372f2fb55f704b885e1097e2ec0381068c855/src/inspector_socket.cc#L562

Okay how about searching the "--inspect" option?
https://github.com/nodejs/node/blob/ecf6a46d98a5d73fb9f98f10a634c786b60aea09/src/node_debug_options.cc

Anyway there's ParseOption
https://github.com/nodejs/node/blob/ecf6a46d98a5d73fb9f98f10a634c786b60aea09/src/node_debug_options.cc#L63

so here it parses the --inspect strings argument
https://github.com/nodejs/node/blob/ecf6a46d98a5d73fb9f98f10a634c786b60aea09/src/node_debug_options.cc#L117

so one would append somethnig after this...

    if (host_port.second >= 0) {
      port_ = host_port.second;
    }

like...

    if (host_port.third >= 0) {
      path_ = host_port.third;
    }

[Note you probably need to adjust whatever parses too and that changes example above]
path_ is defined here
https://github.com/nodejs/node/blob/6e2c29bcabb0507262167494a1fd9bc583cae690/src/inspector_socket_server.h#L85

Then I suppose if _path is already set don't write something else random (auth token aka key) in there?

Okay so where to from there? Can someone follow this up with the C dev env setup etc. please and thank you?

I use WebStorm but I think Chrome is the right place for the debug inspection, since again nodejs is running in multiple VMs. I feel like somebody/everybody there seems to have overlooked what is in my opinion a more typical dev env? In production you'll need multple CPUs per machine. I'm not using cluster etc. but either way you might need to run multiple debug session connections to multiple nodejs instances on multiple VMs, and so this seems important to me. To allow the auth token to be set as the complete path url for the --inspect cli option.

[kfarnung]

@MasterJames To clarify a bit further, there's no inspector-specific connection from node to any external server, it only communicates with the Chrome developer tools over a local websockets connection. What you're seeing is the Chrome DevTools client make a connection back to Google to get the latest version of the client tools. That's why blocking that DNS lookup on the VM hosting node isn't having any effect. Even if you were to block on the machine running Chrome it's likely that it would just get an error and use the copy of the tools already loaded on your local machine.

[MasterJames]

Okay thanks for clarity.
Who can say something about this idea of allowing your own auth token as a full url to --inspect cli argument? or at least is semi responsible for the code involved as I tracked it down some (above).
[I'm really not sure about my pseudo example code and the parser's code in C having a 'third' function etc. nor I'm I setup to make that change submit a PR there.]

[TimothyGu]

Who can say something about this idea of allowing your own auth token as a full url to --inspect cli argument?

I think that's possible, but not for your use case of having several different Node.js instances point to the same address. The original purpose of having a UUID in the URL is to prevent that.

[MasterJames]

Right, but it's all done behind a firewall so I'd prefer to just turn it off otherwise. It should be up to the developer to protect their dev environment or auth token. Randomly generating it is fine if it auto opens on the same machine, but it seems pretty probably people are running nodejs in VMs these days, and so accessing can become problematic as is. IMHO

[bnoordhuis]

Closing, looks like this has been answered.