Limit 3rd Party Developer Access in FS2024 for Protection

I run multiple operating systems. Windows 11, Linux and others. I am not worried about the security situation. I know the Windows OS does collect additional data from me that is another conversation someone else can have.

Of course, no application is 100% secure.

I write code for a living and mess around with information security so not too much worried about my security posture. But I feel that flight simulator add-ons need to be restricted because there are people who need protection.

Your demand would mean the death of the A2A Comanche as it exists today. It is that simple. It cannot, in any shape or form, be implemented without its own executable. There is no compromise to be made, it is a factual impossibility.

EDITED: it might be possible for A2A to do what they need to do in WASM but I don’t support forcing developers to do so because of potential lack of features, performance and stability.

Not sure what to say. I love A2A they are great people and products! But things change. It’s up to Microsoft/Asobo to decide whether the changes should be considered.

… and it’s hard to believe it.


MSFS is a product reliant on the community. If MS and Asobo want to eventually go down this route, sure, but they should be aware of the fact most of the community would be against such a change.

What the OS collects, and what any other given application collects are two entirely different things.

I have no personal knowledge, but I would be very surprised, if a game like MSFS, was not sending a while slew of information (reports) back to MS, when your PC / X-box is connected to the Internet, so I just assume it is collecting almost everything, including when I am flying, my aircraft, where I am flying, and hopefully, any system issues I have .

I bet they have a better Logbook than I have available to me !!

You can also bank on them know who is running “unauthorized” copies of MSFS or MS-Store content !!
What I find amazing and extremely disappointing is, as a Developer , is that they don’t seem to be doing anything to go after those individuals, or impose any penalties on them, or prevent this from happening.

As a coder, you do realize that would require removing the entire SimConnect interface, right?

I should also clarify since it’s unclear in the original post – WASM is a code sandboxing environment. That’s why WASM is the exclusive way for writing add-on C/C++ code using SimConnect in the Marketplace environment. (Previous versions of MSFS would load an executable or .dll with native code.)

WASM isn’t always as fast as native code, and I’m not sure if threading has been thoroughly worked out in the MSFS implementation or not (it’s a huge pain in the ■■■ on the web browser version!) which is probably a large part of why some of the big airliners are coming out with external executables implementing parts of their rendering. They also get direct access to the GPU for drawing if they want, and can then send those bitmaps into the simulator – I don’t know if that’s something that’s currently done or not.

Conceptually, you can compute anything inside the WASM sandbox, but it may not always be practical today to do so.

Other tools literally require access over the network to external programs, or through USB to your input devices, or other stuff – so all those flight tools, input managers, etc – or need to display something on another screen or an output devices that’s not supported natively in MSFS or easily.

So while I expect the sandbox environment to improve, there will always be tools that want, and always be tools that need, to work outside the sandbox.

99% of addons dead cuz of that reason,

I can assure you none are

This post seems like you clearly have no knowledge of the Horrible sdk that’s making developers like me have to write external code for flight models,radars,a maybe a old RNAV system

I have understanding in these areas but I am keeping it very simple here for general user. No need to get overly complicated. If Microsoft/Asobo want to explore this issue in detail they can.

There’s no changes to be considered because there’s no legitimate security concerns here.

The programs are signed by a third party for this exact situation, and even after the fact Windows will go through a verification that you actually want to run an unsigned program, which they aren’t.


I’m starting to think this is a troll account,made less than 24 hours ago


You are perfectly fine to believe this but I disagree. I think it’s important to have a reasonable discussion about add-on developer security. Security has changed since over the past decades that means flight simulator needs to change.

Guess you weren’t around pre 2020 when addons were all DLL and EXEs

1 Like

WASM is a machine-code targeted to run in a web environment. WASM currently supports HTTPS requests so WASM “code” can make external communications assuming they’re HTTPS.

It is, by inherent nature since it runs as machine code that runs natively on hardware. One could argue it runs faster than the language that targeted it.

Only one airliner does this, Fenix. PMDG for example natively uses the NanoSVG graphics API for C++. FBW uses the MSFS Avionics framework which is Javascript.

This entirely depends on what graphical API you’re using, not a limitation of WASM.

Majority of devs do though. Maddog, for example, just uses an external app for load management because at the time WASM didn’t support HTTPs, however everything else resides in WASM.

That’s not really accurate; Wasm codegen requires holding more state in registers (such as the base address of linear memory), which increases register pressure and thus increases the number of variables spilled to stack, usually slowing performance. There’s also narrower SIMD (only 128 bits available) which may lead to lower-speed vectorized code.

One potential advantage to performance is the use of 32-bit pointers (though C/C++ code can opt in to compressed pointers if it’s clever) which may use less RAM at times, but I’ve generally found folks describing modestly lower performance of Wasm-compiled code versus native-compiled code.

Of course it depends on the runtime implementation as well. :slight_smile:

In any case none of this is actually relevant to the core issue that some code runs either “much faster” or “at all” on a native operating system stack vs within a particular Wasm sandbox.

1 Like

An entirely fair argument, You have much more low-level knowledge than I do in this department haha.


A program is signed by a OU or EV code signing certificate issued by either 3rd party CA which is trusted by operating systems or a local CA that is untrusted unless you install the root certificate. Then there is an option to timestamp. The digital signature after the signing process confirms the program has not be tampered with since. This program can contain good and bad code. Both options signed or unsigned will require the user to confirm you want to install or run the program.

These is dependent on a User’s UAC settings. However I don’t see how this a legitimate argument to the things I’ve mentioned.

I did not think that was possible to do – at least a year or so ago, when RXP wanted to implement their Garmin Licensed Garmin Trainer GNS530 into MSFS, and wanted to draw direct to the GPU memory, that was not an available option in MSFS, and despite him asking for that feature, he was bluntly denied such memory access, and hence decide, if he could not implement the Garmin Trainer into MSFS as he technically wanted, he would not do it at all, and we are left with a WT “not 1:1” slow JS version.

1 Like