Explain how hiding will actually work

[FrameMuse]

Maybe I didn't notice it in the README.md, but I don't really understand how this will help to conceal sensitive code if you either get the packages via npm i, which retrieves npmjs.com or you use some kind of CDN services directly on a webpage, which also retrieves a remote service.

How is hiding possible while already having all the code in hand?

[ljharb]

It’s not about concealing code from humans, it’s about concealing it from JavaScript.

[FrameMuse]

Isn't this part about concealing a code from humans?

The "sensitive" directive is intended to be expanded in the future as new security-impacting information leakages are discovered or added to the language.

Also this one

They (callers) can also extract secret values from the source text to compromise an application's attempts at encapsulation.

From README.md

How does hiding an implementation will help to resolve this problem if a source code is always open?

My concern is that by removing one convenient way of retrieving certain function will not solve the problem because people, who actually wants to do so, will anyway be able to access functions by creating their own tools or changing browser behavior to reveal hidden code after all.

I understand having this proposal (which can be revealed by using a revealing method - #42) to help implementers to outline that this code can be changed in future or shouldn't be relied on. But I don't see this proposal as sensitive information concealment or a security measure.

[ljharb]

Because the attack vector isn't from humans reading the code, it's from code attacking or exfiltrating. "callers" means "javascript functions", not "humans reading things".

[FrameMuse]

Because the attack vector isn't from humans reading the code, it's from code attacking or exfiltrating. "callers" means "javascript functions", not "humans reading things".

Yeah, make sense, though I'm talking more about sources, theoretically you can write a function that will extract source code without using .toString because for web pages the only way to load resources - using script tag, no one will restrict that.

As for server-side I'm not sure if the proposal is useful. I can't imagine how something can access a server and inject something in code, usually there is no active console for that and if something have access to a server, it's already late.

From the side of libraries, usually they are open or scoped to an organization you work on, so if something's wrong, you know who you should blame. I doubt open libraries would sacrifice their reputation to inject something in your code.

From the side of viruses, they may attack your browsers, but I doubt they would target specific websites, usually they just stealing your account creds and that's enough. But again, if we have close one way of attacking (that eventually will harm debugging), we come to the beginning of this comment.

I've read something about probable optimization because of hiding a function string representation. If it would be so, we should think about always hiding function string representation and expose it only for debug purposes (i.e. errors and logging).

---

Maybe I got your point wrong, please unfold more what you mean by saying "attack" and where it may come from.

[ljharb]

Servers run untrusted third party code all the time, as do browsers. Open source libraries have many documented incidents of bad actors hijacking a package and sneaking in malicious code.

Either way, the readme explains the primary motivation - anything that's observable about your API risks becoming part of it, including the string representation of your functions. They can't just be hidden by default, but this proposal provides a way for a function author to opt in to doing it.