FDC3 API window.fdc3 installation and overwriting

[novavi]

One of the items touched upon briefly in the Nov 30th Standard WG meeting was the use of FDC3 within a web browser. One of the scenarios discussed was that when an app using FDC3 needed to be run in a browser environment, it must include an FDC3 implementation in either its main JS bundle or a preloaded JS bundle. (This is ignoring the separate case of things like Chrome Extensions, which are problematic for browser-based enterprise app deployment from an InfoSec perspective.)

It was mentioned in the meeting that if such an app is run within a container that already supports FDC3 then it is inappropriate / dangerous for the app to overwrite the container's FDC3 implementation that was originally exposed via window.fdc3.

I have spent some time recently working on a proprietary (rough) FDC3 implementation which is browser-based (i.e. handling intents and channel broadcasts across iframe windows and external windows locally, using the native browser APIs that support cross-origin comms). In the course of this work, when I tested some of my apps in different containers I noticed that the FDC3 Desktop Agents in both OpenFin and Finsemble allow one to overwrite the FDC3 method implementations on window.fdc3, and even allow one to replace the whole window.fdc3 object completely. I haven't (yet) tested this issue in other other desktop containers.

It seems to me that it would be worth considering whether to add a recommendation (SHOULD) or perhaps even a requirement (MUST) in the next version of the FDC3 spec to cover this issue.

In my browser-based FDC3 Agent implementation I take the following approach:

• Test for presence of any existing window.fdc3 object. If it exists (i.e. because the app that included my FDC3 Agent script is currently running in a desktop container instead of a browser) then I completely skip the bootstrapping and installation of my FDC3 Agent and leave window.fdc3 as-is.
• After creating my fdc3 object, I invoke Object.freeze(fdc3) in order to prevent the object's methods from subsequently being deleted or reassigned by external code at runtime. I believe a shallow freeze should be sufficient here so long as the immediate properties of the fdc3 object are all functions (rather than nested objects).
• When exposing my fdc3 object via window.fdc3, I do so by using Object.defineProperty(..) rather than by using a simple window.fdc3 = fdc3 assignment. This prevents window.fdc3 subsequently being deleted or reassigned by external code at runtime.

I'm not sure of the exact mechanisms people are using to expose fdc3 objects via window.fdc3 in Electron-based desktop implementations, but purely for reference this is the rough flow I'm using for a browser-based solution:

Object.freeze(fdc3);
if (window.fdc3) {
  console.log(`FDC3 is already supported in this environment. Therefore ${fdc3AgentProviderName} will not be installed.`);
}
else {
  await bootstrapFdc3Agent();
  Object.defineProperty(window, "fdc3", {
    value: fdc3,
    configurable: false,
    writable: false
  });
  console.log(`${fdc3AgentProviderName} has been installed.`);
  window.dispatchEvent(new Event(CustomEventType.fdc3Ready));
}

I can't see a valid reason for an app to be allowed to overwrite the FDC3 Agent that has been provided to it by the environment the app is running in. Therefore I'd be interested to hear other people's thoughts are on this installation / overwriting issue, what they are currently doing, and whether or not this is something people think should perhaps be covered in the next version of the spec.

[novavi]

Just to expand upon the above, one thing that's probably worth noting for the specific case of browser-based solutions is that even if you take care to freeze your object and make its methods non-configurable and non-writable, you don't have any guarantee that the underlying JavaScript / HTML5 APIs it relies upon are actually the (original) native versions. Since JavaScript / HTML5 APIs are not immutable, it's possible for the following to happen:

• your script providing your API loads.
• runtime code subsequently replaces a native JavaScript / HTML5 API method that your API relies on internally.
• runtime code does not change your API method directly.
• you invoke your API method, but it now uses the runtime-replaced version of the underlying JavaScript / HTML5 API method, rather than using the (original) native version provided by the browser.

This was always possible for browser APIs by reassigning existing properties at runtime to use new functions. However, in modern JavaScript there is also the option of using the Proxy API - which I think makes it impossible to tell whether a native function was replaced or not i.e. because it will still report itself as [native code].

Given the above, I now think any potential recommendations in this area intended to cover browser-based implementations would probably require quite a bit of discussion in order for it to be clear on the exact scope of the recommendation.

By contrast, I believe the case of desktop container implementations is probably more straightforward (relatively speaking) in the sense that context isolation can be used to prevent native browser APIs being overridden. That is to say, a script running within an application in a desktop container could still override a JavaScript / HTML5 API method, but if an FDC3 API method exposed in that environment relied upon a JavaScript API method then it should actually use the (untampered) isolated version of that JavaScript API method.

[novavi]

Returning to my original comment about the behaviour with window.fdc3 in desktop containers, to give a concrete example the scenario is along the lines of:

await fdc3.getInfo();
// Returns:
//   {fdc3Version: '1.2', provider: 'SomeContainerProvider Inc', providerVersion: '8.2.2'}

window.fdc3.getInfo = () => {
  return new Promise((resolve, reject) => {
    resolve({
      fdc3Version: '1.2',
      provider: 'MyEvilHack Inc',
      providerVersion: '0.1.0'
    });
  });
}
await fdc3.getInfo();
// Now returns:
//   {fdc3Version: '1.2', provider: 'MyEvilHack Inc', providerVersion: '0.1.0'}

window.fdc3 = undefined;
// Whole FDC3 API is now unavailable...

My example of changing getInfo is of course pretty benign, but the point is that if an FDC3-enabled app was subject to a XSS attack then it seems that the core FDC3 intent and channel broadcast functionality could be compromised. One could argue that in such circumstances, the whole app would be compromised in a potentially huge way in any case. That is true, but I would have thought an FDC3 API should at least be protected as much as technically possible, even if it cannot control what is happening at the level of the consuming application.

I was curious to see how other implementations handle the exposing of their FDC3 API. Looking at FDC3-Sail, I noticed that it prevents one from overwriting the method implementations on window.fdc3, and also prevents one from completely replacing the whole window.fdc3 object. Based on what I know at the moment, this seems like a good approach.

From what I can see, FDC3-Sail uses context isolation and leverages contextBridge.exposeInMainWorld(..) to expose its FDC3 API as window.fdc3 e.g. here:
https://github.com/finos/FDC3-Sail/blob/main/packages/preload/src/fdc3-2.0/index.ts

I believe the relevant part of the Electron docs is this:
https://www.electronjs.org/docs/latest/api/context-bridge

For comparison, I also came across a reference to an 'old way' of handling the exposing of client-side API objects in Electron by assigning to the window object:
https://stackoverflow.com/questions/59993468/electron-contextbridge

It sounds like contextBridge.exposeInMainWorld(..) automatically handles freezing an object and making its methods non-configurable and non-writable. However, from what I understand based on reading the above and quickly testing in an Electron app:

• exposeInMainWorld easily handles object literals containing functions. This is in fact the approach used by FDC3-Sail to create its FDC3 API (https://github.com/finos/FDC3-Sail/blob/main/packages/preload/src/fdc3-2.0/api.ts#L382).
• exposeInMainWorld does not easily handle class instances. I'm not sure whether there are any ways around this (e.g. for the cases where an implementation relies on a class instance rather than an object literal with functions).

Since desktop containers are a bigger part of the FDC3 picture than browser-based containers, I thought this info was perhaps relevant to the discussion of this issue. However, I should heavily caveat the above by stating that I'm not an Electron developer by any means - so I'd be happy to hear from someone with Electron experience who could either confirm or refute my findings above.

[kriswest]

HI @novavi,

One of the items touched upon briefly in the Nov 30th Standard WG meeting was the use of FDC3 within a web browser. One of the scenarios discussed was that when an app using FDC3 needed to be run in a browser environment, it must include an FDC3 implementation in either its main JS bundle or a preloaded JS bundle.

First off, at the time of writing, there are no browser-based FDC3 Desktop Agents because at present there is no way to inject the FDC3 API without including a vendor library containing one. As per the discussion in the meeting, the inclusion of a vendor library to provide the Desktop Agent Implementation is against both the letter and the spirit of FDC3 as it implies adoption of a particular Desktop Agent implementation (Platform Provider) by an application. The closest you could get is a browser-extension (that the user has to install) which injects the API.

This is something we could look to solve in a future FDC3 version - perhaps utilizing the FDC3 NPM module as a vendor-independent library to import which then attempts to discover a DA running in the browser. But as of today, any purely browser-based solution cannot comply with FDC3 - and any proliferation of them is likely to cause exactly the problems that you identify.

On to your main point. JavaScript does indeed allow you to override or monkey patch functions (for example I can monkey patch the WebSocket API, replacing a function or the whole thing within the scope of a single app/DOM). That is only a problem if:

1. You are including a library or code that tries to inject an fdc3 implementation onto window for you - see the first point - such implementations are NOT FDC3 compliant and should not be promoted or used. However, I concede that there are companies doing so - although none are currently talking to the FDC3 maintainers at meetings about bringing their solutions into compliance with FDC3 or proposing additions to the Standard to either eliminate the need for the library inclusion or to do so in a safe way (that can be adopted by the standard).
2. The app overrides/modifies the window.fdc3 Object itself. Probably not a good idea if intending to use it. Anything you would achieve by doing so could likely be achieved by more conventional means.
3. The app is subject to a XSS attack that hacks the window.fdc3 Object. Browser vendors work to prevent this and app developers should be using the tools provided for them to do so (e.g. input filtering, output encoding, Content-Type and X-Content-Type-Options headers and CSPs)>
   • Hence, I'm not convinced it is the job of the FDC3 standard to prevent this.
   • However, and as you identify, there are things that FDC3 implementations could do to make this more difficult (such as freezing the API implementation). These are not required by the FDC3 Standard at present - but could be considered for a future version (if an issue is raised and a solution voted in by the Standards Working Group). Until then that's an issue for particular Desktop Agent/Container implementations.

[novavi]

Hi @kriswest

Yes, I agree with what you said about there being no browser-based FDC3 Desktop Agents because of the fact that browsers quite rightly prevent cross-origin script injection. And although a browser extension is certainly a neat solution for demo purposes, but I can't see that avenue gaining any traction for enterprise apps for a number of different reasons. To your points:

1. Agreed - this is not currently FDC3 compliant.
2. Indeed - for an app to deliberately override the window.fdc3 object would be silly, and as you pointed out the app could achieve the same aim by other means.
3. An XSS attack was the main scenario I was thinking of in terms of a desktop agent's window.fdc3 object being inadvertently overridden.

• I agree that there are well-established tools and techniques for app developers to drastically reduce the possibility of XSS attacks, and that is it the responsibility of app developers to adhere to current best practice in this area.
• However, I also think that because it seems relatively straightforward for a (native, non-browser) DA to prevent its window.fdc3 object being modified, and since this has already been demonstrated by FDC3 Sail it would seem odd for me for a DA implementer to deliberately avoid freezing its FDC3 API when it has the chance to do so.

I would also add that since FDC3 promotes interoperability between applications across organisational boundaries, then even if a hypothetical In-house App A adhered to best practice for its security, when App A was used alongside Vendor App B then App A could be compromised by poor security in App B that leads to a XSS attack in App B. Hence in the scenario, even though the blame would ultimately lie with the developers of App B, I think App A would have a strong interest in (and would benefit from) the DA doing everything within its power to prevent any code running inside App B from maliciously overriding DA FDC3 functionality. Perhaps if DA implementers don't feel this is within their remit then there would be little support for specifying this in a future version of the standard itself. But I'm happy to raise an issue if you think further discussion within the Stardard WG would be beneficial?

As for your wider point about companies developing their own browser-based FDC3 implementations, I can foresee a few things happening in the real world:

• Companies playing with implementations to better understand the standard. This is behind their corporate firewalls, probably not even in production, and in any case invisible to the FDC3 Standard WG.
• Companies implementing the standard to allow them to use the FDC3 API for cross-product, cross-app comms in browsers the short term (albeit not FDC3 compliant) whilst they figure out their medium- and long-term desktop strategy (which may ultimately involve adopting a vendor desktop container). This is also invisible to FDC3 Standard WG but as you rightly point out, if a browser-based solution became more of a real strategy for them then they should really to talk to the FDC3 maintainers in an attempt to resolve all the issues discussed about browser-based solutions.
• Future vendor-supported browser-based FDC3 implementations. At the moment I believe this is limited to Connectifi (when it becomes available) but it would be reasonable to assume that over time there will be other browser-based offerings.

Given this range of scenarios (especially the final one) I don't think the issue will go away. Therefore I think it would be beneficial at some point for the Standard WG to at least try to tackle some of the issues presented by browser-based solutions. But if as you say individual company implementors in this area are not talking to FDC3 maintainers then I'm not sure what the trigger for a proper discussion will be - perhaps a vendor offering such as Connectifi will ultimately trigger it, even if details of internal company implementations continue to remain invisible?

I'm intrigued by the idea you floated of using a FDC3 npm package to support runtime-based discovery / selection of DA. This is definitely an interesting avenue (although, sadly, I suppose also subject to the same monkey patching risks as everything else in a browser!)

[novavi]

For anyone reading this who somehow didn't see the other issue, it's worth noting that one of the items raised above (FDC3 npm package to support runtime-based discovery / selection of DA) has now become part of a much wider discussion about FDC3 For Web browsers #896