Proposal: Enable UWP apps to request background access to the clipboard

[Felix-Dev]

Proposal: Enable UWP apps to request background access to the clipboard

This proposal was originally tailored to the specific use case of allowing UWP apps running in the background access to the clipboard when interacted with via toast notifications. In follow-up discussions it was then suggested to increase the scope of this issue to cover background access to the clipboard for UWP apps in general. This proposal has thus been edited to reflect the broadened scope.

Summary

Currently, the UWP Clipboard APIs only allow (read/write) access to the clipboard when the calling UWP app is the foregroud app. In other words, these APIs will "fail" if your UWP app is currently running in the background. However, there are use cases where UWP apps running in the background should be allowed to have access to the clipboard in order to provide a delightful user experience (see for example the scenario described in this comment.

As a workaround for this current app model limitation, UWP apps can use a Win32 full-trust helper process (via an app service) and call the Win32 Clipboard APIs to access the clipboard to read from/write to the clipboard even when in the background.

This proposal aims to improve the UWP Clipboard APIs so that UWP apps can request clipboard access when in the background. This request model follows the typical UWP permission model - an initial background clipboard access request will prompt a user-consent dialog with access only being granted if the user agrees to the request. If the user denies the request, no background access to the clipboard for the app is granted. As long as the user did not revoke previously granted background access for an UWP, each subsequent request call will be "silent-accept", in other words, no user-consent dialog prompt will be shown.

Rationale

Developers should not have to resort to using a win32 full-trust process to realize UWP app experiences where (selective) clipboard background access is essential to create delightful user experiences. Some significant drawbacks of having to consume a win32 full-trust helper process alongside your UWP app are the following:

1. UWP apps have the restricted runFullTrust app capability: This can cause security concerns for potential app customers - in the worst case leading them to not use your app
2. Additional development complexity is added due to having to set up the win32 full-trust helper process and enable back-and-forth communication between it and the main UWP app. See the documentation for more details about how app service communication works.

Scope

Capability	Priority
Allow UWP apps running in the background to request read/write access to the clipboard and if the user agrees to the request, access is granted.	Must
The user can revoke granted background clipboard access for a (UWP) app in Windows Settings at any given point.	Must
Change the current clipboard foreground access behavior to also ask for specific user agreement if required.	Won't

API Details

A conceptual API overview can be found in this comment: #62 (comment)

Additional Context

This topic (particulary the app scenario with backgroudn clipboard access following toast notification interaction) was initially brought up in the WinUI repo and @BenJKuhn already gave some first thoughts on it (see [Clipboard Pains]):

That said, a notification that’s being interacted with seems like it should be allowed clipboard access. This would require special handling because of how Windows and foreground is counted, I think, but doesn’t seem beyond reasonable.

A Feedback Hub entry about this issue can be found here: https://aka.ms/AA7zx69

[hansmbakker]

I understand you propose to move the clipboard access to outside the application logic for security reasons, but doing this via a toast does not feel like good UX to me.

I also think the clipboard access should be separated in reading and writing.

Writing is less of a security issue I believe, but mostly a UX issue (if an app puts something in the clipboard while the user still wanted to use another value, that's annoying).

However, if the app can read / monitor the clipboard without consent of the user --> that is a security issue.

Would it not be possible for the windows team to provide a clipboard API that an app can only successfully call when the app is in the foreground, so that an app can still provide the user interface inside the app?

[Felix-Dev]

@hansmbakker

I understand you propose to move the clipboard access to outside the application logic for security reasons, but doing this via a toast does not feel like good UX to me.

I'm not sure you understood my app scenario correctly: In my particular case, I have talked to users of my app and they found the concept of simply clicking a button on toast notification to copy some information displayed much more preferrable than

1. put the app in the foreground again (for example via toast foreground activation)
2. now copy the info and
3. bring the app to the background again.

All they want to do is quickly copy some conveyed info if desired and providing a [copy to clipboard] button on the notification itself will exactly enable this requested UX.

I'm not sure what you mean with "outside the application logic". The clipboard API will still be called inside the app, not somewhere else (think Application.OnBackgroundActivated).

Would it not be possible for the windows team to provide a clipboard API that an app can only successfully call when the app is in the foreground, so that an app can still provide the user interface inside the app?

Again, I'm not sure I understand you correctly but what you seem to be describing here is exactly the case today. UWP clipboard API only grants access to the clipboard when your app is in the foreground. Which is the reason why I cannot copy notification content to the clipboard when the app is in the background. Instead, I have to resort to using a win32 full-trust process to realize the requested UX.

[hansmbakker]

Oh, excuse me. I didn't try the clipboard API yet myself and I thought that what you described was that the clipboard API is limited even when the app is in the foreground.

[jonwis]

To paraphrase the request:

When the app gets its ToastNotificationActionTrigger from a "background" tagged toast, it should be able to request access to the clipboard

What if we had a more generic thing, which was along the lines of:

AppContainer apps can request background read, write, and monitoring access to the clipboard, with appropriate user control following the other Foo.RequestAccessAsync models

Would that help? So your toast trigger handler would look like:

var clip = ClipboardManager.GetDefault();
if (await clip.RequestAccessAsync(ClipboardAccess.Write) == CapabilityAccess.Allowed)
{
    clip.WriteDataPackage(this.CreateDataPackageForToast(t));
}

(We're trying to decouple as many things as possible, so "clicking this toast gets you clip access" is a little more confusing than "you can get clip access in more ways.")

[Felix-Dev]

@jonwis Would each call to ClipboardManager.RequestAccessAsync() show a user-consent dialog or would no user-consent dialog be shown on subsequent calls as long as the user did not revoke permission (for example via Windows Settings or by denying the request in the dialog)?

Yes, I'm fine with broadening the scope of this issue (I tend to create issues very much tailored to specific use cases in the hope to increase chances of them being accepted). I will gladly update the issue to reflect the broader scope.

(Seeing as it was suggested to increase the scope of this issue pinging @jtorjo here as they also had plenty of issues with the UWP app model clipboard implementation and I believe they will like the direction where this is going.)

[jonwis]

As with most Request prompts, it'd be a one time thing to enable, then the second request would be silent-accept. You still need to call it every time, but the popup would only happen once.

[Felix-Dev]

@jonwis That's perfect then! I will update this proposal accordingly to reflect the broadened scope.

Edit: Updated the proposal.