Proposal: UWP apps should have to ask for user-consent for accessing the clipboard even when in the foreground

[Felix-Dev]

Proposal: UPW apps should have to ask for user-consent for accessing the clipboard even when in the foreground

Summary

The UWP Clipboard APIs currently allow read/write access to the clipboard without asking for user-consent when in the foreground. In other words, as long as a UWP app is the foreground app it can read clipboard data without the user noticing this and thus be able to prevent it.

This becomes especially concerning when the user additionally has the clipboard history enabled in Windows Settings. In this case, the foreground app can access plenty of previous clipboard data which might include data such as website links, document excerpts, images or even passwords and other security credentials.

(The clipboard history feature enabled in Windows Settings)

I have created a sample app showcasing the current behavior. Below you will see an image of the app showing you clipboard data the app can have access to. The app is written in a way that as soon as the app is launched and activated, the clipboard data is read. The data read includes both the clipboard history (if enabled in Windows Settings) and the current clipboard content (which gets pasted by pressing Ctrl + V).

with the following clipboard history content:

This demo app is attached as a VS project below. Simply build the app and then launch it. You should then see your clipboard content listed (if any). For simplicity, the demo app only reads data classified as text.

As you can see in the posted images a UWP foreground app currently can "just read" the clipboard history and thus obtain private data of the app user. There is no additional security check triggered right now before a foreground app accesses the clipboard history. While the Clipboard History access API does come with a possible access operation result of AccessDenied, I haven't yet found out how to actually deny an app foreground access to the Clipboard history.

I am thus proposing the UWP Clipboard History API to follow the common UWP permission request model. A call to Clipboard.GetHistoryItemsAsync() would now show a user-consent dialog first in case the user has not currently granted the app clipboard history access permission. This will let the user notice when the app - even in the foreground - is trying to access the clipboard history and deny the request if so desired. If the user already has granted the app access permission at the time of the Clipboard.GetHistoryItemsAsync() call, no user-consent dialog is shown and the app can read the clipboard history.

The user will be able to manage clipboard history access permissions on a system level and additionally an app-by-app basis in Windows Settings as is the case for many other privacy-related settings in Windows 10. Conceptually, the clipboard history privacy settings page in Windows Settings could look like this:

Allow apps to access the clipboard history - On/Off

Choose which apps can access the clipbord history
[App 1] - On/Off
[App 2] - On/Off
[App 3] - On/Off

Rationale

Give the user the power to regulate clipbord history access even for a foreground UWP app. Prevent apps from being able to read the clipboard history undetected while in the foreground and thus obtain private data about the user.

Additional Remarks

While I initially also wanted to put read access to the current clipboard item and clipboard write access behind a user-consent guard, it was suggested that this might not really be feasible. The issue here is that WinUI inbox controls like TextBlock and TextBox already come with in-built copy/paste support and it would be detrimental to the user experience if they cannot, for example, just copy some text displayed in a TextBlock without being interrupted by a user-consent dialog. Additionally, as presumably nearly every app out there uses TextBlocks and/or TextBoxes with copy/paste support, the clipboard access user-consent dialog would be shown for nearly every single UWP app in existence. Such a situation could easily overwhelm the user and in the end contribute to them simply clicking 'Yes' on the user-consent dialog without giving it further thought, thus defeating the prupose of this proposal.

Scope

Capability	Priority
UWP foreground apps will to have to ask for user-consent before they can access the clipboard history.	Must
The user will be able to manage clipboard history access permissions both on a system-wide and an app-by-app case in Windows Settings.	Must
This proposal will show a user-consent dialog when UWP foreground apps attempt to read the current Clipboard item or write to the Clipboard.	Won't

API Details

I believe the current clipboard history read access API can be used here as it already is async (great to show a user-consent dialog) and returns a ClipboardHistoryItemsResultStatus value indicating if the clipboard history could be read or not. All that would have to be added here is the actual user-consent dialog which is currently missing.

Example code:

ClipboardHistoryItemsResult history = await Clipboard.GetHistoryItemsAsync();
if (history.Status == ClipboardHistoryItemsResultStatus.Success)
{
    // user has the clipboard history feature enabled in Windows and granted this app access permission
}
else if (history.Status == ClipboardHistoryItemsResultStatus.AccessDenied)
{
    // user has the clipboard history feature enabled in Windows and denied this app access
}
else
{
    // history.Status == ClipboardHistoryItemsResultStatus.ClipboardHistoryDisabled
    //
    // user has the clipboard history feature disabled in Windows
}

Aditional Context

Here is the UWP demo app used to demonstrate the current UWP Clipboard API foreground access behavior: ClipboardForegroundAccess.zip

This proposal is similar to issue #62 which is looking to enable clipboard background access while keeping the user in control. The clipboard privacy settings page in Windows Settings would ideally manage both clipboard background access and clipboard history access.