Option to specify ClipboardItem is sensitive in .write() and .writeText()

[runofthemillgeek]

Feature Request / Proposal

To add a boolean property sensitive to a ClipboardItem:

const passwordBlob = new Blob(["secret"], { type: "text/plain" });

await navigator.clipboard.write([
    new ClipboardItem({
      [passwordBlob.type]: passwordBlob
      sensitive: true
    })
]);

// ...and maybe an options param to `.writeText()` as well?
await navigator.clipboard.writeText('secret', { sensitive: true });

Why

Operating systems with built-in clipboard managers or browser's with clipboard managers (and maybe userland extensions?) could choose to not add such items to their history.

A real-world scenario that I've faced is while using 1Password on Windows 11, with Clipboard History enabled (Win + V). Using the native 1Password Windows app to copy a password/OTP doesn't persist it to Clipboard History. Not sure how they accomplish this.

But the same thing, when done via the 1Password extension, comes up in the Clipboard History. I'm not sure if the 1Password extension uses a different API that's available to extensions or utilize Clipboard API for this. Either way, being able to label items like this and if browsers handle this case appropriately, Clipboard Managers (and similar applications) can operate safely and not be prone to leak sensitive info.

Concerns

• Such items would be easy targets for an existing malicious code
• Some users might prefer to still keep these items in their history. But that's up to the browsers to decide if they'll provide such an option.

[BoCupp-Microsoft]

@snianu is there anything that would stop us from using the UWP APIs on Windows to specify whether an item should be added to the clipboard history or not based on a ClipboardItem option like @sangeeth96 has proposed?

@whsieh there are also MacOS content options that control some pasteboard behavior like whether the clipboard content can be roamed to another device. Would it make sense to let the web author opt out of that behavior using a ClipboardItem option?

[BoCupp-Microsoft]

Note that on Windows it looks like roaming and history entries can be controlled per format. I imagine its a performance feature so that large formats don't need to be realized and stored or transmitted over the network.

[mbrodesser]

Cc @mozfreddyb to get his view about the concerns mentioned in #154 (comment).

[mozfreddyb]

I have a few clarifying questions.

If this is solely about providing this sensitive flag to the underlying operating system, so that other applications (e.g., cloud sync) can choose not to store them, then I think it's not a bad idea. Firefox is already setting this sensitive flag on certain platforms when copying passwords from the built-in password manager.

Do I also correctly understand that the browser wouldn't behave differently when reading a sensitive ClipboardItems, i.e., web sites would be able to have the same discretion for sensitive items?

It seems this whole issue is orthogonal to a different problem that's worth solving, which I want to explain for a second: An evil web page that is trying to paste indefinitely in the hope of scraping some passwords from the clipboard. It would be nice if we could agree that browser shouldn't web expose sensitive items through the read API without additional user interaction..

[mbrodesser]

Amendment to @mozfreddyb's post above: https://www.mozilla.org/en-US/security/advisories/mfsa2021-48/#CVE-2021-38505

[BoCupp-Microsoft]

If this is solely about providing this sensitive flag to the underlying operating system, so that other applications (e.g., cloud sync) can choose not to store them, then I think it's not a bad idea.

Yes I believe your understanding is correct.

It would be nice if we could agree that browser shouldn't web expose sensitive items through the read API without additional user interaction.

Do platform APIs exist to let app developers know if the item has been marked as sensitive? I didn't spot any for Windows.

[annevk]

I'm not sure about the shape of this API. Is the problem here that this particular cloud implementation doesn't do end-to-end encryption? It seems a lot safer to assume that all data is sensitive unless the application explicitly indicates otherwise. Opting everyone into the "not sensitive" bucket seems bad? (It's also not entirely clear to me how an application would go about determining whether something is sensitive.)

[mbrodesser]

Given the different values (ExcludeClipboardContentFromMonitorProcessing, CanIncludeInClipboardHistory, CanUploadToCloudClipboard) of https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats#cloud-clipboard-and-clipboard-history-formats I wonder if the same level of granularity would make sense for clipbboard.write() and clipboard.writeText().

[runofthemillgeek]

If this is solely about providing this sensitive flag to the underlying operating system, so that other applications (e.g., cloud sync) can choose not to store them, then I think it's not a bad idea.

Yes, this was my intention. Passwords, API keys and anything that I as a developer firmly believe shouldn't go into a "Clipboard History" application, OS-provided or built-in can respect such a flag. Or, the browser can (if possible), signal this intention. Ideally, would prefer any such application could choose this for themselves. Plus, it could be a configurable option for these Clipboard managers whether to keep sensitive info in history or not. It's useful sometimes to copy these across devices but I understand that could pose a security risk too.

Do I also correctly understand that the browser wouldn't behave differently when reading a sensitive ClipboardItems, i.e., web sites would be able to have the same discretion for sensitive items?

This is interesting. It could be helpful maybe to prevent accidentally sending a sensitive information in say a public forum. Websites could alert the user about it. Not entirely sure about the security implications besides a bad actor finding it easy to filter for these specific items.

...An evil web page that is trying to paste indefinitely in the hope of scraping some passwords from the clipboard.

Paste events don't need a user action to work? 🤔

[runofthemillgeek]

@annevk I totally agree with the "encrypt everything" point. But, if I take the example of Handoff and similar cross-device feature offered by other Clipboard management tools, I find it very convenient to copy passwords or OTPs like that. So, if I could choose as a user whether this should be allowed or not, that'd be awesome. Plus, if I'm screensharing and want to copy from my Clipboard manager a password I copied previously, having such a flag (and allowing copying of these) could let the Clipboard manager mask the password with *.

So, I personally think there's value in having something like this as a user and a developer.

[mbrodesser]

@sangeeth96

Paste events don't need a user action to work? 🤔

They need. That's also covered by the spec: https://w3c.github.io/clipboard-apis/#dom-clipboard-write. However, browsers currently don't behave exactly the same. Perhaps that might be clarified in #158; see also #158 (comment).

[BoCupp-Microsoft]

So, if I could choose as a user whether this should be allowed or not, that'd be awesome.

That's a good idea. I could imagine a setting that would cause the UA to ignore these hints from the author. I could also imagine UX that allows the user to override any author supplied hints at the time of copy.

Also, I think there are two hints that should be allowed separately as opposed to just one "sensitive" hint:

• history - controls which formats are saved
• roam - controls which formats can be shared across devices

You might not want to save a OTP in history, but you may want it shared to another of your devices.

[css-meeting-bot]

The Web Editing Working Group just discussed ClipboardItem is sensitive in .write/.writeText().

The full IRC log of that discussion

<Travis> Topic: ClipboardItem is sensitive in .write/.writeText()
<Travis> github: https://github.com//issues/154
<Travis> BoCupp: This is an option that allows one to specify whether clipboard items roam and/or are included in history
<Travis> .. a common feature of various platforms.
<Travis> tilgovi: https://meet.google.com/pdx-dnmm-cen
<Travis> BoCupp: This is something that we [Microsoft] could take up and write an explainer for?
<Travis> Anne: My main concern is about the default values (which ones should be correct)?
<Travis> BoCupp: Defaults should be what the user has configured on the platform.
<Travis> .. [cites how Windows-clipboard prompts on first-use...]
<Travis> .. There may be exceptions for privacy modes, or copying from a password field (context specific)
<Travis> Anne: Is it OK for websites to override defaults?
<Travis> BoCupp: I think so.
<Travis> .. specifying per-format allows imposing limits. (e.g., large bitmap roaming)
<Travis> Anne: How will a website make the right decision? Do expose the user preference?
<whsieh> q+
<whsieh> q-
<Travis> BoCupp: I don't think we would expose the user preference--the implementation would configure this as desired.
<Travis> .. We might add additional restrictions
<whsieh> q+
<whsieh> q-
<Travis> BoCupp: We can continue discussion in the issue... when we're ready to draft a PR we'll revisit.
<snianu> https://github.com//pull/162

[oliverdunk]

Just to share another example here, there is a community-driven standard set of types used on macOS by many applications: http://nspasteboard.org/

[snianu]

@sanketj FYI.