Currently chrome.test only implements harmless assertion APIs, but that may change in the future. If it becomes anywhere as powerful as Chrome's chrome.test API, then we have a problem. Bill said that it's doable to put the API behind a preference and run tests with that preference.

I don't think it's worth wasting time on this. All this API does is pass messages to listeners that the test harness adds to the extension instance. If at some point we decide that this needs to be hidden, we can just expose it only when there are listeners. But since the API is entirely a no-op in that case, I don't think it's worth the effort.

At the moment, that's indeed what the API does. That's no guarantee for the future, however: unnecessarily exposed APIs are a potential security risk. The risk is currently low, so I agree that this is a low-prio issue.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.