 is this personal protocol session and it just covers some, it's very difficult to use cases in production and we will discuss some issues what we have right now. So, issues. The most exciting part. I mean, first issue is that, I actually, it's my main issue for me right now, just because I'm trying to go this debugger for Node.js, it's not about production, but it's partially about production, but you use child processes, it's actually how to debug child process. The problem is that, this third protocol is exposed to using WebSocket and it's better by itself try to generate some port and by default it is one port, it definitely doesn't work, if you have multiple processes, but it can automatically generate random port if you pass zero. And after you pass zero, the main question is how to get this generated port back to actually connect. And right now the approach is super ugly, it's only works when you can control how Node is started, you just parse a CD error and get this WebSocket, we are out of CD error. But if child press mute a CD error or something like this, it will not work. So, have anyone debug child processes? Okay. Only deep button in the tests, but that's like already painful. Okay, it's already painful. So the possible solutions here, it's the main problem is how to actually discover this port, how to report this port. It's probably we can use some alternative transport to report this port. For example, diagnostic report that will just introduce an experimental, and maybe if you have some other ideas how can report it and can be easily consumed by a tool, it will be nice. You're so like, I know VS Code allows you to attach to, like Node processes that don't even explicitly open the inspect port yet, when we did list them all. So maybe look through how they did that. Yeah, they actually use signals, they can send signal and then open DevTools socket actually. The problem is at least now the sound cloud environment actually prohibits using signals. So, yeah, but that's the next point. I will take a look again, maybe they introduce something better. Okay, that's probably the main problem. The main and biggest topic actually, the problem raised by Ali by all robots actually secures is how is it secure to use protocol and production? From one point of view, as long as you are not leaking WebSocket URL, it should be fine. But at the same time, I remember the second part of security is not exposing too much information as possible. Right now, if you leak WebSocket URL, someone get full access to protocol, it can, someone can debug it, someone can execute remote code and anything like this. I think we even had a security, some vulnerabilities that we text because people complained about it. Yeah, that is being predictable. Yeah, the idea, one of the problems was that we actually provide default export protocol using 0000 interface on some predictable port and it was too easy to connect. I've actually seen this in a while, like people exposing the debugger randomly and then other people connect into it and exploit it. Yeah, it's very good point. First of all, there are some very simple layer of security right now that you need to get full WebSocket URL to connect, actually. But unfortunately, by default, note on the port, on the inspector port, note you'll expose JSON endpoint where you can go and get this full WebSocket URL. So the first measure, very straightforward, I actually have four requests to introduce a flag that actually disables JSON endpoint. And then port won't be enough to actually get access to protocol and you don't need to brute-file this magic long token. That should be not possible actually. So just a question around that. Is it, I'm not fully familiar with how WebSocket works. Is it only a problem when you expose all of your ports to the web? So if you, for example, if you have some kind of, you're using a computer and you only bind, I don't know, C1000 or something like that. If you're not exposing any ports and you're only around trusted jobs to code somehow, or you don't use actual NPM dependency or you verify all of them, then yes, it works. But if you run on trusted code, then it can, for example, then you run two nodes with the same instance, one node can connect to another node. What is the security vector in NPM? I mean, I'm not ready to answer on this kind of, I mean, security problem is when you run two nodes and you have to somehow compromise some NPM package and use this NPM package to brute-force all ports and connect to another node the instance of your machine action on the ground. You could also like your NPM module could open the port, right? Yes, because you can programmatically start the inspector. Yes, so. So first problem is actually leaking this WebSocket URL. If you can avoid leaking, it will be fine, but I mean, if it's finally leaked, another problem is actually exposing too much information. And one of the suggestions by Ali and Eugene was that we need to white-list the minds that's actually available in nodes. It might work. I mean, if you need to own the profiler or if you only need some part of protocol, it possibly work. But at the same time, protocol by itself was not designed to be right in this environment. For example, you need runtime domain for a lot of inspection. And if you enable only profiler, you cannot get it. If you enable only key profiler, it's much harder to get actually few objects without runtime domain. It's something that we can work on, but it's often questioned how to solve it. If you can find the idea, by the way, there's the link and there are a lot of discussion happens there. And please join and share any of your comments. Has there been any discussion about you make this flag default in a text-making version? Not yet. I mean, no endpoint is not merged yet. And I wish to have it enabled by default, but I'm not sure about the code to build. Maybe because I expect like most of the security issues we see today, where people accidentally expose this is because they don't know about it. And it's not gonna help having a flag to disable it because they're not gonna know about it. Yes, I agree, but at the same time, I mean, visual studio calls, for example, I see all that you have this endpoint. Yeah, it's a programming text. Like if you built a programming text to find you know the process. Yeah, that's how it just goes. Yeah, that's how it goes. I think you've already had to turn on something. Yes, you need to pass a final inspect. You can pass a second point there. But can it, for example, make it so that if you turn on debugging with the signal, it doesn't expose the endpoint? We can do it. I mean, yes, we definitely can right now remove as much possibilities as possible. This final time, yes. But if, for example, visual studio calls your signal, they expect to have those parts. I think the other thing is it's still, like security was brought up as one of the issues. I guess it's still the making the case that turning this on in production is gonna be acceptable. Security's one thing, but for other reasons as well. And performance overhead, there's no more. I think people are uncomfortable because of the bunch of nuts. People aren't comfortable with material in production. It's great for debugging locally and on either. These are the sort of issues without this. I'd like to say that the protocol, if we just make a step from security, protocol was designed in a way that it is ready from production, from performance point of view, from, I mean, mostly from performance point of view, and actually used to automate Chrome a lot and to use by different companies. And from the, I mean, the only aspect that was not to remind when protocol was designed was security. I mean, security was the point where it's not easy to get a port, it's not easy to get full WebSecret URL, and it's enough for our use case. But in production, I easily can imagine that we'd like more security and more control over everything. So I'd like to say that performance is solved, kind of nothing is solved, finally. I know, but it's mostly solved. If you need something, you definitely need to pay for something like profiler, there are some overhead, but if you don't need profiler, you need something else, you only pay for this little business unit. So is that something like Netflix is already, or are you using it internally, become comfortable with it? Not yet, it was just stressed, Chris. You were saying that the runtime domain is required for certain other domains, is that required by the provider? Because as I understand, the providers are just, you know, possibly filled in like 30 provider medias, so yeah, like is the runtime domain required for the clients? It's required when you use protocol, I mean, as it demands you some concept from runtime domain. For example, if you capture heap snapshots and you like to get objects back, then real objects back, runtime domain is actually, domains are exposed for object inspection, implement everything about inspection, object inspection. So you can get heap profile back, you can load it or automatically analyze it, but if you'd like to inspect it get better picture of what is actually new heap in the runtime domain, and something like this. I mean, I believe that most stuff will work and you will be able to get a lot of meaningful data out of it, but it was never actually considered. So protocol was never built with idea that it can be used with different domains. We check also PM2 because I know that he is back, they know the compliance view and memory and so on. So they apply the same solution as code, for example, to understand which part was there. PM2, it's like a process manager, that's money to some process manager. I definitely need to take a look. I never saw this project before, and I don't know what they use, but as far as I know, right now there are two solutions how to get profile information out of node, is some flex that you can use. We used to have some JavaScript bindings to get profile out of node. I mean, to get profile out of node process, I think there are some APIs. There are some APIs. They're black and vinyl. Black and you can use the inspector API. Yes, inspector. And if you really want to do it, you can like install some new add-on that involves the API. So yeah, they use vinyl too. Most likely they use inspector, but I need to check it in. And now the possible solution for the security problem is don't use WebSocket and use alternative transports, like pipes that just develop locally. And the inspect pipe is actually working progress by region. I will help you to finish it, and it will solve some problems. For example, Chrome, when exposing protocol, use pipe when it requires some kind of security. But again, it's two different problems. How to access protocol and what protocol expose. Problem to how to access protocol is much easier to solve. So what would you like to expose? And this pipe is the kind of pipe in node, as in like in pipe on the nodes and you need to make something on the next. I need to double check how it's actually implemented. I know that Chrome actually have implementation of pipe for each platform, and I need to actually map it to node implementation. I'm not sure. But yeah, it's possible solution. I don't know. And so something not about issues, but fishy request, network inspection. I go from during the conference and people start to use inspector. They very fast go to the point where they'd like to have some way to inspect network. And then my problem is how we can inspect network and what we should do. I mean, we're out of time already. I tilt well. And then yeah, it's just, if you'd like to talk about network inspection, if you need network inspection and if you'd like to help us to do something there, please join. I will open diagnose secretions soon. And right now I'm going to feature across against NDB. That's it.