- From: Andrew Sutherland <notifications@github.com>
- Date: Mon, 08 Jan 2024 16:17:11 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1698/1882028534@github.com>
I think specifying the function name dynamically via a string is a non-starter. Although there is precedent in HTML for inline JS that could be said to resemble this, it's bad precedent and is a major source of XSS issues. For the particular use-case of WebExtensions that seems to be motivating this request, my general impression from discussion with our (Mozilla's) add-on teams is that one of our greatest concerns is dynamism in WebExtensions that enables bad actors to create extensions that seem benign but later are dynamically reconfigured to violate the user's privacy and/or security. An API surface like this would intentionally create problems for static analyses. If the high-level goal is for WebExtensions to be able to reduce their performance impact on the browser until the user activates specific functionality, I would suggest that the correct approach for this is to have the enabling/disabling located on the WebExtension API surface that would be responsible for generating the event. The WebExtension code then can add event listeners using addEventListener in the usual way. This a more appropriate layering for efficiency and devtools integration. [NavigationPreloadManager](https://w3c.github.io/ServiceWorker/#navigation-preload-manager) is not a perfect example of this, but is a pattern that WECG could follow if there somehow is not already an existing idiom for this. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1698#issuecomment-1882028534 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/issues/1698/1882028534@github.com>
Received on Tuesday, 9 January 2024 00:17:18 UTC