feat: add --enable-api-filtering-logging command-line switch

[miniak]

Description of Change

Add --enable-api-filtering-logging command-line switch, which enables caller stack logging for the following APIs (filtering events):

• desktopCapturer.getSources() / desktop-capturer-get-sources
• remote.require() / remote-require
• remote.getGlobal() / remote-get-builtin
• remote.getBuiltin() / remote-get-global
• remote.getCurrentWindow() / remote-get-current-window
• remote.getCurrentWebContents() / remote-get-current-web-contents
• remote.getGuestWebContents() / remote-get-guest-web-contents

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR title follows semantic commit guidelines
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Added --enable-api-filtering-logging command-line switch, which enables caller stack logging for desktopCapturer and remote APIs that can be blocked or filtered.

[MarshallOfSound]

I feel as though there is a cleaner and less impactful implementation out there for this.

What if we captures the trace inside ipcRenderer.send and attached it to the event object itself. I.e. event.senderStackTrace?

[miniak]

@MarshallOfSound that seems quite intrusive as well, @nornagon what do you think?

[nornagon]

An environment variable doesn't seem like the right way to expose this functionality.

What problem are you trying to solve?

[miniak]

@nornagon when blocking the remote module, sometimes it's hard to figure out where it's being used from. especially when the renderer process is sandboxed, the preload script cannot be debugged easily to see where the exception is thrown.

I didn't want to make the stack available by default as I was concerned about the performance impact.

[zcbenz]

From past experience it is generally bad idea to change API's behavior with environment variables.

[miniak]

@zcbenz I agree with that. My concern is the performance impact of always capturing the stack traces if it's not optional.

[miniak]

@zcbenz what about not changing the API, but just logging the call stacks when the variable is set?

[zcbenz]

I'm good with current approach.

[miniak]

@nornagon modified getCurrentStack as suggested, should be ready to land

[release-clerk]

Release Notes Persisted

Added --enable-api-filtering-logging command-line switch, which enables caller stack logging for desktopCapturer and remote APIs that can be blocked or filtered.