At the moment, we have some C++ helpers to check various sandbox-ability bits. They all get invoked on early startup when the system information service initializes, and all of them get called.

The problem with this is that none of this info is ever retrieved, as far as I can tell, except if the user loads about:support (or perhaps other consumers of Troubleshooting.jsm - see https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/toolkit/modules/Troubleshoot.jsm#694-696).

This should ideally live somewhere else. Could we perhaps use the same sandbox-helper service we use a little further down (if MOZ_SANDBOX is defined) to produce a jsval or webidl dictionary that we can return?

Ni for comment #0 and whether moving this elsewhere is easy to do...

(In reply to :Gijs (he/him) from comment #0)

This should ideally live somewhere else. Could we perhaps use the same sandbox-helper service we use a little further down (if MOZ_SANDBOX is defined) to produce a jsval or webidl dictionary that we can return?

Probably. That XPCOM glue didn't exist yet when these nsSystemInfo properties were originally added, but now that we have it, it seems like a better place for that info.

Another oddity here is that the SandboxInfo singleton is constructed, and various OS feature detection tests run, at static initializer time instead of lazily when it's first used; there were reasons for that which no longer apply, but nobody's gotten around to changing that yet. As a result, the code that sets these properties in nsSystemInfo is just testing bits in a global int variable, so this may not be as expensive as it looks.