Clarify WebExtension installation scope and persistence in WebDriver BiDi

[whimboo]

Currently, the BiDi specification does not define how web extensions should be installed in an active browser profile, as there is no standardized specification for profile handling.

To enable web extension authors to test their add-ons in Firefox without requiring prior signing, we need to support temporary installation. This means the extension remains installed only for the duration of the current browser session and is automatically removed upon restart.

I’m not sure how Chrome or Safari handle this scenario (CC @OrKoN, @gsnedders, @kiaraarose, and @xeenon), but it would be helpful to at least clarify the expected lifetime of installed web extensions in the spec. If Chrome and Safari do not have a temporary installation concept and instead allow unsigned extensions to be installed permanently by default, we may need to define this as a Firefox-specific behavior.

Alternatively, if temporary installation becomes the default, we could introduce a permanent parameter to allow extensions to persist across browser restarts. In Firefox, this would only be allowed for signed web extensions.

See as well the discussion at: w3c/webextensions#764 (comment)

[xeenon]

@whimboo I agree — these should be temporary, and that’s exactly how Safari handles them. In Safari, the extension install is entirely ephemeral; it exists only for the duration of the automation session and is removed as soon as you exit automation or quit the browser.

We should all align on temporary installation as the default. Safari will not support a permanent option to prevent it from becoming a vector for malware to persistently install extensions. If other browsers choose to offer a permanent option, that’s up to them, but Safari will not honor it.

[OrKoN]

Does it cause any issues for testing in WPT right now? If not, I think it is fine to have a vendor-specific behavior and even add a note to the spec that implementations may remove installed extensions after the WebDriver session is ended. Chrome requires additional launch arguments to be able to install extensions via automation but extensions would be persisted in a (usually a test) profile. Maybe this behavior would change eventually (cc @oliverdunk) but I think this all is covered by implementation-defined installation steps.

P.S. sorry for closing/re-opening (hit the wrong button)

[whimboo]

I'm fine with adding a note in the BiDi specification stating that installations are temporary by default. However, it would be helpful to define precisely what "temporary" means - specifically, whether all installed extensions should be removed when the related WebDriver session ends or when the browser process is closed.

In most cases both options might fall together, but there are scenarios where a client does not start the browser process directly and instead connects to an existing one by creating a new session and disconnecting later. Clarifying this behavior would ensure consistency across implementations.

[oliverdunk]

I would echo the question from @OrKoN - does this cause any issues for testing right now?

If not, the suggestion in Alex's comment can work with all of our security models and requires the least amount of additional work (emphasis added):

add a note to the spec that implementations may remove installed extensions after the WebDriver session is ended

I agree that consistency is desirable. However, where possible (including in Chrome) I expect developers will be creating a fresh profile for each run of their test suite. So I'm not sure that this particular case matters much in practice and I'm concerned about stating that installations must be temporary.