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.

[michael-hawker]

I think reading is the security mode which needs access, any app should be able to write to the clipboard.

However, I see this posing a problem with the generic textbox, as any user is going to expect to be able to paste text into an app from the clipboard and having every app request access to reading the clipboard then becomes meaningless...

So, I think there has to be a distinction like you said between an active window and any other state and reading the current clipboard value vs. the entire history. I think it'd be hard to separate out if it's an 'inbox' control as part of a context menu vs. the app APIs itself trying to do any access, as that line is fuzzy with custom controls and other scenarios.

[Felix-Dev]

@michael-hawker To summarize, it seems reasonable to guard UWP clipboard access calls behind a request API (which would show a user-consent dialog if required) in the following cases:

• Background read/write access (as suggested in issue Proposal: Enable UWP apps to request background access to the clipboard #62)
• Access to the Clipboard history (even if in foreground)

Consequently, the Clipboard privacy settings page could then look like this:

Allow apps to access the clipboard in the background - On/Off

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

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

As for reading the current clipboard content (or writing to the clipboard) in the foreground, the current behavior of the in-built Text* controls (TextBlock/TextBox/...) pose a challenge, as you said. In light of this I would be fine in keeping the current behavior as is (i.e. calling Clipboard.GetContent() or Clipboard.SetContent() in the foreground will not require user consent).

[metathinker]

This is a really interesting idea, and one that my colleagues and I at Microsoft are definitely considering with internal discussions. I have a few questions, though:

Do we still want to have a permission for access to the current clipboard item?

You have a permission toggle for read and write of the current clipboard item listed as "must have" in your proposal, but it sounds like after @michael-hawker posed some questions regarding this point, you've set it aside as a requirement. Are you setting it aside just for now or do you think it is no longer necessary at all?

• The reason I ask is that my coworkers and I are concerned that requiring opt-in permission for the current clipboard item would lead to so many permission prompts that the user would eventually click "Yes" to every one without thinking. It sounds like Michael had the same thought to at least some extent.

Does writing need to be controlled as strictly as reading?

When Windows 8 imposed the original restriction that pure UWP apps and other apps in AppContainers cannot access the clipboard when their windows are in background, our main concern was with an app snooping on a copied item that the user wouldn't eventually paste into that app. So even though the clipboard restriction was applied to both reading and writing, our main worry was about reading. Do you think that logic still applies today also applies to apps in the foreground, and if so, do you think it would justify keeping the current relaxed approach for writing the current clipboard item and/or the clipboard history?

Should we have a separate API method for requesting opt-in permission?

The closest analog to your proposal I can think of is getting the user's geographic location. A UWP app that wants to read the user's location must do 2 things:

1. Its developer must put the location capability in its app manifest.
2. At runtime, before calling the API methods to retrieve the location, it must call a separate API method Geolocator.RequestAccessAsync to pop up a dialog requesting location permission, if the user has not already opted in to that permission.

In your proposal, there is no need for a special clipboard capability, and any Clipboard API method call will implicitly pop up the permission request dialog if permission has not previously been granted. I see an advantage in this - it means that apps that were written before your proposal is applied won't fail to get and set clipboard just because they haven't popped up the permission request dialog. However, I also see advantage in the geolocation API's approach, where the privacy implications of access to the data values is made obvious to the developer by the more convoluted approach. What are your thoughts?

[Felix-Dev]

@metathinker Thanks for your reply!

Just a very short reply for now as it's getting late here...

Do we still want to have a permission for access to the current clipboard item?

Sorry for the confusion here. I wanted to update the initial proposal to reflect @michael-hawker's input and the conclusion I made in my reply to him for a few days already yet unfortunately didn't manage so far. I plan to update my proposal tomorrow. And yes, knowing the considerable impact this would have on the user experience in common app scenarios I am fine with allowing unguarded foreground access to the current clipboard item (as is currently the case).

The Clipboard History access policy is something far more concerning to me and I believe it makes sense to take a second look at it and how we could possible improve protection of the user privacy here. As you have already indicated, there can be multiple ways to achieve improved Clipboard History access control here and I will take a closer look at your thoughts and suggestions in the next days!

Edit: Updated the proposal to reflect recent comments made by @michael-hawker, @metathinker and me. Let me know what you think! (@metathinker I have not yet added in your API suggestion to have the user opt-in to clipboard history access.)

[MuleaneEve]

@metathinker Another critical awareness tool is that any approved geolocation access still triggers the appearance of an icon in the taskbar. This should also be the case for the Clipboard (the icon can stick around for a few seconds).

An extra step that I would like to see for all these sensitive services is that there should be a way to see a history of these accesses after the fact. That way, we can audit apps to confirm that they did not abusing these services while we were distracted.

[ieburk]

Hi @Felix-Dev! These are great ideas - we want to explore them and we want to keep you updated on this effort! We need to be very reasonable with our users' needs to protect their privacy regarding clipboard access, and are working with our privacy experts to make sure we have a secure and trustworthy design that is consistent with all of Windows privacy.

[mominshaikhdevs]

Part Of: #219 + win32-app-isolation repo. (remove the CoreWindows part.)