Repository navigation
Add Protocol (URI) Activation #4842
Description
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>
Reacted by intrnl and spetterman66 / 17lifers
Activity
DHowett-MSFT commentedon Mar 9, 2020
I’m not sure
wt:new-tab -p CMDis particularly ergonomic; what value would it add over simple process invocation?MarkIvanDev commentedon Mar 9, 2020
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=CMDAFAIK, 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 commentedon Mar 9, 2020
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
cmdorpowershellwon'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 commentedon Mar 9, 2020
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 commentedon Mar 9, 2020
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.exeto escalate some malicious sidecar exe it ships with. Even justwt:new-tab?commandline=cmd.exe /c del /s /q C:\users\youcould 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 commentedon Mar 9, 2020
The documentation for URI Activation says the following (emphasis mine):
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 commentedon Mar 9, 2020
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 launchcmd /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 commentedon Mar 9, 2020
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 commentedon Feb 8, 2021
From Marc-André Moreau (@awakecoding) in #9061
feat(external-apps): add Windows Terminal (wt.exe) support (#17942)