starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Add Protocol (URI) Activation #6786

New Issue
Open
opened 2026-01-31 00:47:14 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 00:47:14 +00:00
Owner
Copy Link

Originally created by @MarkIvanDev on GitHub (Mar 9, 2020).

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>

Originally created by @MarkIvanDev on GitHub (Mar 9, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # 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. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # 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>` <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-FeaturePriority-3Product-TerminalArea-UserInterface labels 2026-01-31 00:47:14 +00:00
claunia commented 2026-01-31 00:47:15 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 9, 2020):

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

@DHowett-MSFT commented on GitHub (Mar 9, 2020): I’m not sure `wt:new-tab -p CMD` is particularly ergonomic; what value would it add over simple process invocation?
claunia commented 2026-01-31 00:47:15 +00:00
Author
Owner
Copy Link

@MarkIvanDev commented on GitHub (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=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.

@MarkIvanDev commented on GitHub (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=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.
claunia commented 2026-01-31 00:47:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (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 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.

@zadjii-msft commented on GitHub (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 `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.
claunia commented 2026-01-31 00:47:15 +00:00
Author
Owner
Copy Link

@MarkIvanDev commented on GitHub (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.

@MarkIvanDev commented on GitHub (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.
claunia commented 2026-01-31 00:47:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (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.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.

@zadjii-msft commented on GitHub (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.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"](https://images-na.ssl-images-amazon.com/images/I/51aCFGh8IBL.jpg) situation. I think it'd come across as a relatively arbitrary boundary on the feature.
claunia commented 2026-01-31 00:47:15 +00:00
Author
Owner
Copy Link

@MarkIvanDev commented on GitHub (Mar 9, 2020):

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.

@MarkIvanDev commented on GitHub (Mar 9, 2020): 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.
claunia commented 2026-01-31 00:47:16 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (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 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 commented on GitHub (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 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 ...
claunia commented 2026-01-31 00:47:16 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (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.

@DHowett-MSFT commented on GitHub (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 :smile: I just can’t commit engineering resources to working on it pre-v1.
claunia commented 2026-01-31 00:47:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 8, 2021):

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?

@zadjii-msft commented on GitHub (Feb 8, 2021): 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?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Issue-Feature Priority-3 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#6786
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?