The web clipboard does not currently indicate that its data originates from the web. This means that, unlike with downloaded files, native applications are unable to use such information to optionally provide defense in depth or other protections based on this information.
This explainer proposes a Mark of the Web (MoTW) for the Web Clipboard. This MoTW would be a format written in parallel with other already-written formats, which can inform native applications that the clipboard payload originated from the web.
- Provide an additional method for defense in depth, as the Downloads Mark of the Web does.
- Preserve user privacy/security.
- Require all native applications to check this MoTW (Like with Downloads, not all native applications must check this MoTW, especially at first).
- Discuss raw clipboard access design. (While the author of this explainer may also be considering raw clipboard access, this MoTW would be applied on all web clipboard data. It’s not advantageous to have a hypothetical, separate “sanitized clipboard MoTW” and “unsanitized clipboard MoTW”.)
Mark of the Web would add an additional format, written on every write from a user agent. This should not be visible on read for existing web clipboard APIs, but would be visible to native application clipboards, and could be accessible via the proposed raw clipboard access API. The data contained would simply be 'web', to indicate that the origin was a web site. In the future, this may be extended to also allow for 'installed-web-application', 'native-application', etc.
// NOTE: This is a hypothetical representation in JS,
// but Mark of the Web will not be visible in JS, so a
// web application developer may not see any change.
// Without Mark of the Web
await navigator.clipboard.writeText('hello world');
// clipboard contents after write:
// {
// 'text/plain': 'hello world'
// }
// With Mark of the Web
await navigator.clipboard.writeText('hello world');
// clipboard contents after write:
// {
// 'text/plain': 'hello world',
// // Only present on a clipboard write from a user agent.
// 'text/source-type': 'web'
// }This would potentially degrade privacy, by easily providing information to native applications regarding the type of source for clipboard data. However, native applications on many platforms are already able to view screen content and listen to keyboard actions, so this information is already displayed in some sense, and no new information should be exposed to native applications.
In conjunction with raw clipboard access, this may also expose new information. Web applications with raw clipboard access may learn new information through MoTW, in that some clipboard payload originated from the web. This should be a relatively small concern, as the data exposed is relatively safe compared to other data exposed by raw clipboard access, which a user must have explicitly given consent for (as well as secure context and active frame).
Providing a source url, or the url of the source of the clipboard data, could allow antivirus scanners or other native applications to detect websites that attempt to place malicious content on the clipboard, and has parity with the shape of Downloads MoTW, where both source url and referrer url are provided.
However, providing a source url is a privacy concern, as this is new information that was not previously exposed to the clipboard. In most platforms, any native application would be able to continuously read/poll the clipboard in the background, so this is introducing new information to native applications, which could be used by a malicious application to fingerprint a user (see which sites a user has visited and copied from). That said, native applications in some platforms can already passively view screen content (ex. remote desktop applications), so this may not be a significant privacy concern in most platforms (it simplifies this form of fingerprinting, but does not add new data).
A stronger privacy concern of this alternative is that, in conjunction with raw clipboard access, providing a source-url would result in more exposed data, as websites would have access to the origin of clipboard data, which would not be possible without this MoTW with source url.
An important distinction between the Clipboard MoTW and Downloads MoTW is that the Clipboard MoTW is provided on a raw clipboard data stream, which is accessible by all native applications (as well as raw clipboard access). Meanwhile, the Downloads MoTW is only stored in file metadata, and is therefore not accessible to web applications through Native Filesystem or similar APIs. Therefore, it's important to avoid providing the source url to the clipboard.
// With Mark of the Web
await navigator.clipboard.writeText('hello world');
// clipboard contents after write:
// {
// 'text/plain': 'hello world',
// // Only present on a clipboard write from a user agent.
// // Equal to ‘about:internet’ when in incognito or if the
// // url is too long. Note that this url is new information
// // not previously exposed to the native clipboard.
// 'text/web-source-url': 'https://www.example.com'
// }
Some implementations of MoTW also provide a referrer url, or the url of the page that "referred" the user to the current page. However, as with providing a source url, providing a referrer url is also a privacy concern, as this could inform a malicious listening native application of multiple sites in a user’s browsing history with each user copy. As the value of providing a referrer url seems fairly small, and is overshadowed by the risk, this explainer has opted to exclude a referrer url.
N/A
Many thanks for the valuable feedback and advice from:
- [email protected]
- [email protected]
- [email protected]
- Chromium’s Windows and MacOS implementations.
- Windows's URL Security Zones and a document describing it.
- MacOS's File Quarantine and a document describing it.