Add Protocol (URI) Activation

[MarkIvanDev]

Description of the new feature/enhancement

In addition to the available App Execution Alias of the app, it would be nice to also add protocol activation (URI activation). Adding this would make it easier for other apps to integrate their workflow with Windows Terminal.

Proposed technical implementation details (optional)

We could already use the app execution alias as the protocol scheme and the exisiting command line arguments as the protocol parameters. It could be as simple as adding the following lines to the App Manifest and reusing the parameter parsers for the arguments.
<uap:Extension Category="windows.protocol"> <uap:Protocol Name="wt" /> </uap:Extension>

[DHowett-MSFT]

I’m not sure wt:new-tab -p CMD is particularly ergonomic; what value would it add over simple process invocation?

[MarkIvanDev]

Looking back, I think using the current format for parameters will not transfer well to the URI activation. But the parameter names can be used like this wt:new-tab?p=CMD

AFAIK, UWP apps can't start processes apart from Protocol activation. So there is no way for a pure UWP app to start up a Windows Terminal instance right now. A sample use case could be for UWP file managers to open a WT instance through protocol activation.

[zadjii-msft]

I guess my question would be about what context URI activated apps get launched in. Pure UWP applications run in a much less permissive model then normal Win32 applications, which provides more of a security boundary. (We'll sometimes use the words "lowbox container" or "low-IL" to refer to this security boundary). If a UWP app activates a protocol like this, does the target application open in the caller's container, or does the app open in the target's normal context?

If WT were to open in the caller's context, then this actually won't end up being all that useful. The Terminal might be running in the directory the app requested, but cmd or powershell won't really be able to do very much at this point, since they'll be trapped in the container.

If it doesn't open in the caller's context, then I guess this makes sense as a request. Kinda seems like it would be an escalation of privilege vector though, allowing a UWP app to basically start anything on your PC at medium-IL (the normal runtime context) just as long as the Terminal is installed.

[MarkIvanDev]

Apps that are launched by URI Activation run in their own container. I don't think this will result to an escalation of privilege as URI activation is one-way process, once the calling app activates WT, WT is on its own.

There is another URI activation available in UWP, Protocol for Results activation. In this type, a connection is established between the caller and the activated app. I am not suggesting this kind of activation. Just a simple activation like tapping on the WT icon in the start menu launching with a specific profile and a working directory at most.

[zadjii-msft]

Disclaimer: not a security expert, or a Windows platform expert.

I mean, the commandline args as they are can also be used for specifying the commandline to run in the terminal, so one could imagine a malicious UWP activating wt:new-tab?commandline=my-malicious.exe to escalate some malicious sidecar exe it ships with. Even just wt:new-tab?commandline=cmd.exe /c del /s /q C:\users\you could be pretty bad. That's why I'd be wary of this.

Sure we could say that protocol activation only works for opening a new window in a given directory. But that seems like a classic "If you give a mouse a cookie" situation. I think it'd come across as a relatively arbitrary boundary on the feature.

[MarkIvanDev]

The documentation for URI Activation says the following (emphasis mine):

Remarks
Any app or website can use your URI scheme name, including malicious ones. So any data that you get in the URI could come from an untrusted source. We recommend that you never perform a permanent action based on the parameters that you receive in the URI. For example, URI parameters could be used to launch the app to a user's account page, but we recommend that you never use them to directly modify the user's account.

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/handle-uri-activation#remarks

Since URI activation is mainly used for navigating to another app, this will not be a problem with the lowbox container of UWP apps. As it is solely based on how WT handles the activation that matters. The calling UWP app can't force WT to execute a certain command if WT won't. We can set a number of accepted commands that WT can parse in the URI activation - commands that only navigate the WT. Everything else is discarded and WT can launch the app in its default state.

[DHowett-MSFT]

Sorry, I will never countenance an allow list of things that WT can be used to launch by URI activation. The simple scale of that problem is pretty much unapproachable.

Can it launch cmd? Okay, but then it can launch cmd /c /s del. so we add an argument parser for CMD specifically ...

Then can it launch powershell or pwsh? Another argument sub-parser.

How about wsl, through either ubuntu.exe or wsl.exe? I’ve got some bad news ...

[DHowett-MSFT]

So yeah, I dunno. If we can’t launch processes, this exists only as a way to launch WT in ever more configurations. I’m not opposed to that, but it doesn’t seem valuable to add a less-featureful version of commandline args for the small handful of applications that might care.

All that said, though, as a community contribution we would definitely evaluate it 😄 I just can’t commit engineering resources to working on it pre-v1.

[zadjii-msft]

From @awakecoding in #9061

very interesting, it looks like the other issue is very similar to this one, with the exception of the protocol handler. I wouldn't mark it as duplicate, because the protocol handler would be usable to open a new tab from a browser-based password manager (we have those as well), but then the requirements are different, and we'd have to see how to properly handle security for the dynamic command injection.

I suggest we modify this feature request to be the protocol handler built on top of the other issue #8898, rather than the entire feature by itself. The goal would be to securely expose the same functionality but through a protocol handler instead.

I have a few ideas how security could be handled:

• the profile could be preconfigured with a hard-coded command, and the profile id would need to be known in advance
• a security warning could be shown to the user and the entire command presented in a dialog box before running it
• the command could be signed by a certificate using something very similar to .rdp file signatures. A modern variant would be a JWT

What do you think?