Discussion: private fields and util.inspect

[jasnell]

Now that we have support for private class fields... we need to figure out how (and if) we want to support them with regards to util.inspect()...

Right now, those properties are hidden from the output even when showHidden is true...

class F { #foo = 1; }
const f = new F()
util.inspect(f)  // returns 'F {}'
util.inspect(f, { showHidden: true }) // returns 'F {}'

How should we handle these with inspect?

[devsnek]

https://chromium-review.googlesource.com/c/v8/v8/+/1546559

[BridgeAR]

@jasnell I definitely think we should add support for these behind the showHidden option. We can visualize them with the hash sign just as they are defined using a colon as separator as we do for all other properties as well.

But I guess your question was also (or mainly) in the direction of how to retrieve the information. I personally think the work by @joyeecheung looks very promising (while I agree that we could just extend the existing API as discussed in the comments of the reverenced PR).

[jasnell]

Yep, thank you for linking the V8 issue @devsnek .. I knew that conversation was happening but I had lost track of where it was. I opened this issue largely just so we could track the discussion and see if there were any actual objections to including those fields.

[cjihrig]

FWIW, I'm in favor of including private fields in util.inspect() output.

[joyeecheung]

From the feedback we've got from https://chromium-review.googlesource.com/c/v8/v8/+/1546559 I think we should try using the inspector to implement the inspection of private fields for a start. It could be built on top of #27110 for more readable interactions with the inspector.

[domenic]

As a library author I would prefer if these were not exposed through util.inspect(). I am trying to hide my implementation details, and in the case of jsdom, emulate native classes. You do not get to see the private fields of Date, or ArrayBuffer, or Map, when you util.inspect() those.

But with this in place, people could read my private data easily at runtime:

class X {
  #secret = generateSecretNumber();
}

const x = new X();
const secret = /#secret: '([^']+)'/.exec(util.inspect(x))[1];

console.log("no longer a secret: ", secret);

Introducing this into Node.js would force me to avoid using private fields, and use WeakMaps instead, since those cannot be discovered by util.inspect() in this way.

In other words, this feature effectively makes private fields no longer useful, as they're just symbols that require different awkward contortions to access (grepping through util.inspect output, versus using indices into getOwnPropertySymbols).

I would prefer that private fields only be visible to users of the inspector, not to unprivileged Node.js code.

[devsnek]

I would prefer that private fields only be visible to users of the inspector, not to unprivileged Node.js code.

the inspector itself is also available to unprivileged node code, and returns the private fields as a nice object you don't need to use regex on.

[domenic]

My understanding is that you need to be started with a flag to include the inspector, per https://nodejs.org/en/docs/guides/debugging-getting-started/. That would be "privileged" code then, in my (admittedly imprecise) terminology.

[cjihrig]

You can start the inspector at runtime via inspector.open().

[domenic]

Oh :(. Then I guess Node.js is just not a feasible runtime for writing encapsulated code.

[joyeecheung]

@domenic I don't think we are going to implement what the snippet shows exactly - this is supposed to be only available when showHidden: true is passed to util.inspect(). Also, util.inspect() is capable of inspecting weak maps entries with showHidden: true as well - provided that you are able to get hold of the weak map, but then you may be able to use inspector to um, inspect that scope chain to get hold of it.

FWIW you can break encapsulation of any runtime that embeds v8 with post-mortem support by using the JS API of llnode - take a core dump via gcore (or something else that capture a core dump) and then iterate over the heap to find your object, then you can even break closure encapsulations by inspecting context that references your objects. It's just too slow to do this hack though.

[domenic]

I am just used to the browser where we have actual encapsulation from other code. It is sad and disappointing to find out that Node does not have the same level of encapsulation.

But given that it doesn't, I guess I don't have much more to add to this conversation.

[joyeecheung]

@domenic Node.js has a history of treating all user code (third party or not) as trusted and equal, I think that's what makes its privacy model different from the browser.

Would it help if we make inspector part of the experimental policy? Although whether it can be made opt-in or opt-out depends on how much breakage the ecosystem can take since inspector.open() has been out there since 8.x.

It would be quite hacky to use inspector to implement this (either in core or in the user land) though, as you need to inspect your own scope chain which means you need to tell the debugger to pause at your code and do a lot of stuff that depends on the exact shape of the functions in the call stack.

What's your primary concern about thing encapsulation being broken? That the users get to see the fields or that they get to use them programmatically? It would be quite difficult to use these programmatically if the private fields are not primitives, as the inspector would only give you a preview of them, and doing all these hacky things would bring a lot of overhead as well.

[ljharb]

Please do not show private fields anywhere, just like you wouldn't show closed-over variables when you log a function. This is the domain of debugger, not console.log.