Proposal: webRequest worklets

[nir-walkme]

It has been discussed many times that DNR does not support many use cases that were possible using Blocking webRequest. Some of the use cases are summarized in this meta ticket.

Some solutions were suggested by the browser vendors, but they are far from achieving reasonable functionality. The fact that DNR is declarative, limits its functionality and any solution based on it would probably be too limited.

Therefore I would like to suggest a non-declarative alternative to DNR and Blocking webRequest. I call it "webRequest worklets".

"webRequest worklets" would provide the benefits of DNR: security and performance, but with lower impact to developers.

How it works?

• In a similar way to blocking webRequest's addListener API, it is possible to register a worklet to listen to web requests.
• For more information about Worklets, read here.
• The Worklets would work in a similar way to the blocking webrequest callbacks and will use code to evaluate and modify web requests (as opposed to using declarative rules).
• But the worklets would be limited in their functionality. Functionality such as performing network requests or saving to storage would be blocked. It is expected that the Worklets would perform mostly string reading and string manipulation. The Worklet might read information from storage (for example: ad-blocker configuration) but not store it.
• A similar concept exists today in "Shared Storage", which is using Worklets that are limited in functionality and this way can preserve privacy but still provide important functionality.

Benefits of "webRequest worklets":

• Security and Privacy - Since the worklets cannot output data externally (not through network nor storage), the traffic that goes through the worklet is kept private and secure.
• Performance - The fact that the worklet functionality is limited can prevent usage of non-performant code. Moreover, worklets can support WebAssembly or possibly can be pre-compiled so performance is better.
• Supports most of the use cases that were possible using Blocking webRequest.

Happy to hear your thoughts on this.

[nir-walkme]

@Celsius273 @hackademix @carlosjeurissen @ghostwords Happy to hear your thoughts on my proposal

[tophf]

Standard JS isn't the best choice for a worklet language probably as it's too flexible, it also has tons of built-in globals in globalThis that take time to initialize even with V8 snapshot technique, its interpreter is big as well.

The usual choice for this task is something lua-based like LuaJIT or eLua, which consume ~1000 times less memory and are much faster to start, their interpreter is much smaller and simpler and the JIT version is very performant.

[ghostwords]

Sounds like this would solve #302.

[nir-walkme]

The usual choice for this task is something lua-based like LuaJIT or eLua, which consume ~1000 times less memory and are much faster to start, their interpreter is much smaller and simpler and the JIT version is very performant.

Thanks for the suggestion. Is any lua-based language currently being used in browsers?

[tophf]

AFAIK none, because browser makers don't have worklets in a core performance-critical path, the currently existing use cases (audio processing or the Houdini project) have comparatively lax performance/memory restrictions.