-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to specify ClipboardItem is sensitive in .write() and .writeText() #154
Comments
@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 @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 |
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. |
Cc @mozfreddyb to get his view about the concerns mentioned in #154 (comment). |
I have a few clarifying questions. If this is solely about providing this 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.. |
Amendment to @mozfreddyb's post above: https://www.mozilla.org/en-US/security/advisories/mfsa2021-48/#CVE-2021-38505 |
Yes I believe your understanding is correct.
Do platform APIs exist to let app developers know if the item has been marked as sensitive? I didn't spot any for Windows. |
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.) |
Given the different values ( |
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.
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.
Paste events don't need a user action to work? 🤔 |
@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. |
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). |
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:
You might not want to save a OTP in history, but you may want it shared to another of your devices. |
The Web Editing Working Group just discussed 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 |
Just to share another example here, there is a community-driven standard set of types used on macOS by many applications: http://nspasteboard.org/ |
@sanketj FYI. |
Feature Request / Proposal
To add a boolean property
sensitive
to aClipboardItem
: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
The text was updated successfully, but these errors were encountered: