How to approach IPC with UWP applications

[VodBox]

I am in the last stages of finalizing #3327, but the final design has wider implications for how the project wishes to manage third-party integrations, so I'm posting this to solicit thoughts from other contributors or from third-parties who are interested in developing tools for OBS. I have tried to make sure as much of the relevant information is available here and is easily understood, but I'm happy to clarify things as needed.

The obs-ipc plugin from #3327 exposes a named pipe that applications can transact with to create an anonymous pair of named pipes. These allow for two way communication with OBS directly, without blocking or overlap concerns and without the overhead of a protocol like WebSockets. This plugin shares information about the state of OBS, gives some level of control of the OBS state to connected applications, and even allows for the retrieval of a shared texture containing the OBS preview. This sets up the possibility for third-party integrations, and possible implementation in various overlay systems.

As with any part of OBS, this feature has been built with openness in mind; to allow anyone to create alternate interfaces running locally on a users system, to gain close access to relevant parts of the OBS API and it's internals. It's also been designed in a way that - while it is Windows only for now in its first iteration - the same functionality can be ported relatively easily to other OSes without making significant changes to the underlying API.

The concern I have for this current implementation, is that UWP applications can only connect to named pipes when specific conditions are met on the Win32 (OBS) side.

When a UWP application is run outside of developer mode, Windows runs it inside a fairly strict sandbox. The application in question must declare any extra capabilities from outside the sandbox that it needs, and for Store distribution in particular, these capability requests are scrutinized as part of the review process. One of these restrictions is that unless a UWP application is running with a Full Trust Permission Level as part of it's capabilities, then a UWP app can't connect to a named pipe outside of its sandbox, unless the Win32 side provides an explicit allow for an SID that a UWP app utilizes. The two types of SID that matter for this are a Package SID, and an App Capability SID.

The Package SID is a unique identifier associated with a given application package, and can be used in a security descriptor to specify what permissions that particular application has on a resource (in this case, whether it's allowed to connect to and communicate on a particular named pipe). An App Capability SID refers to the unique identifier for a particular capability or interface that an application has requested permission to access, that would normally be inaccessible from inside the sandbox. A developer can define a Custom Capability, however approval and reservation of a name has to go through Microsoft.

If we use a Package SID for the explicit allow, then only the UWP applications included in an allow list (either created at build time or iterated at run time) will actually be able to connect to obs-ipc. Either this means that we build OBS to only allow connections from an approved set of UWP applications for a given update, or we have to maintain an allow list that can be updated at runtime, and add to that list on request by an application developer. The benefit of this is that it's relatively simple to implement, but it would only allow integrations that we approve to be in an allow list.

If we use an App Capability SID for the explicit allow, that would require us to contact Microsoft to request a Custom Capability to be reserved with a name for us, along with details of what purpose the capability allows and how we intend it to be used. If they approve this request, then we have the option to create a SCCD (Signed Custom Capability Descriptor) that allows anyone who includes a copy of it with their UWP application to specify in their manifest that they support the Custom Capability. Should their applications be packaged then, or pass review by Microsoft for the store, it'll work with OBS' named pipes. The benefit of this is that we do not keep an explicit allow list, since the only step by developers needed is to include the SCCD. However, the SCCD is signed by Microsoft, and we would need to send another email to explain why the SCCD should allow any application to talk to us.

If Microsoft does not approve an AllowAny SCCD, then every UWP application that wants to connect with OBS would need to request a SCCD from us, provide us with a certificate hash and other information, and we would need to email Microsoft for every case to actually get the CCD signed for that developer. This would in effect be no different from having the allow list, but with more steps involved. The only benefit would not needing to have OBS update an allow list, or maintaining a list altogether.

My preference would be to try for an AllowAny SCCD, then providing a download for it that developers can include in their own applications. If that cannot be achieved, my second preference would be for a Package SID based allow list that we can update as needed. I'd like to hear what other people think on this however.

The reason I feel this is important - even if UWP is not likely to be used by third-party developers - is that part of us being open is trying to be platform agnostic and trying to reach developers where they are, rather than trying to force people into a specific platform or environment for integrating with us.

[derrod]

My preference would be to try for an AllowAny SCCD, then providing a download for it that developers can include in their own applications. If that cannot be achieved, my second preference would be for a Package SID based allow list that we can update as needed. I'd like to hear what other people think on this however.

I second this approach. But also believe that it should not be a blocker for a release (assuming the other pieces are in place by then). Should Microsoft take too long to respond we should consider shipping an initial version with just a whitelist, and then switch over to the SCCD based variant with a later patch.

In general my take is that UWP is not really important enough for us to really think about this in the first place. While I get the demand for "openness" in the end the only people that would be restricted by this are those that have willingly put themselves into a restrictive sandbox in the first place.

[VodBox]

For the record, the prompting for this discussion has to do with investigating Game Bar widgets as an option for companion apps to OBS. Game Bar widgets have to run as UWP apps and so they would be running inside the UWP sandbox. In order for that to be a feasible route for developers, there needs to be consideration of how UWP apps on the whole can be allowed to communicate with OBS.

The intent in particular, is to avoid a situation where a companion app arrives that wants to use the ipc plugin, and makes a change to support communication only for that app (whether in upstream or otherwise). I'd rather we preempt things with a release of the plugin in upstream that will already work for those developers, rather than changes being introduced that are closed off to only approved packages.