feat: add clipboard privacy options

[nmggithub]

Description of Change

This is my attempt to resolve #49466. I don't think it's quite ready, so I'm opening it as a draft PR. I welcome comments and critiques to help refine this.

I've added the ability to define the privacy of a write to the clipboard. While the original issue was requesting for the Apple platform, this PR should be cross-platform (to the extend that Chromium upstream actually uses the API's I'm depending on).

Upstream API's Used

(links pinned to Chromium 144.0.7559.60, the version used on the current major: Electron 40.0.0)

Our clipboard API uses the ScopedClipboardWriter class from upstream to manage writing to the clipboard. This class has a private member variable called privacy_types_ that holds an enumeration of privacy settings for a write to the clipboard.

Unfortunately, that member variable isn't writable directly, and the only mechanisms for manipulating it are the functions MarkAsConfidential() and MarkAsOffTheRecord(). To avoid patching Chromium, I simply take these and expose them as mutually-exclusive values for a privacy option in the clipboard writing API's in JS-land. I took the "privacy type" name for the name in of the enum in C++-land (even though it's now not really a one-to-one mapping) because I wasn't sure what else to call it.

Local Testing

Final note: while this does compile and build, I haven't fully tested if the behavior actually works as I expect it to. I plan to do so soon, though.

I have tested this briefly between my MacBook and my iPad and it seems to work well enough.

• PR description included
• npm test passes
• tests are changed or added
• relevant API documentation, tutorials, and examples are updated and follow the documentation style guide
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Added clipboard privacy options to clipboard writing API's.

[nmggithub]

I'm not a fan of using an impure function here, but it follows the pattern of GetClipboardBuffer.

[nmggithub]

A note on approach:

As mentioned, I didn't want to patch Chromium, so I tied this to the two (seemingly) different options provided upstream. However, in practice, it seems there isn't much of a difference between the two in ordinary use. MarkAsConfidential() does add one more flag (kNoDisplay) to privacy_types_ than MarkAsOffTheRecord(). Though, after perusing the Chromium source code, it seems that flag is only used internally to diverge behavior in one very specific circumstance:

1. When kNoDisplay is present in privacy_types_, Chromium merely sets a "flag" on the current clipboard item by way of a nil data payload for a custom type.
2. That status is only checked by a IsMarkedByOriginatorAsConfidential() function...
3. ...which is only ever used by code regarding the omnibox, which isn't a feature in Electron.

Perhaps privacy should just be a boolean. But I wonder if these two options will have more of a distinction upstream in the future.

[complexspaces]

While I'm not an Electron maintainer, I do maintain arboard, a popular Rust library for clipboard interactions. Given everything I've seen on the desktop OSes, I don't believe there will be a difference between these any time soon. If something is marked as confidential every platform treats that as a "don't store" signal which results in it never appearing in any type of clipboard history functionality. I would strongly recommend keeping it simple with only one "level" for now.

[nmggithub]

I appreciate your thoughtful response here. My wonder in my comment was based on the fact that the Chromium authors created these two distinctions in the first place. It does seem odd to me for them to have two functions that essentially do the same thing, although perhaps that can happen in such large projects and I don't know the history of these API's. I still fear the Chromium authors will do something in the future to further diverge these functions. I do agree with you, though, that using a boolean would be much simpler and would likely result in a nicer API.