-
-
Notifications
You must be signed in to change notification settings - Fork 158
Description
We want to deliver preprocessors for DNR rules to align the behaviour on multiple platforms more precisely. Multiple approaches can be made involving both backend and extension.
The last consensus is below:
- We will create a separate file per each DNR ruleset to ship additional metadata along with the DNR rules. This is to completely be free with the DNR specification; some platforms might restrict us from using additional fields. The file is in the following JSON format:
Record<number & { __: 'filter id' }, { preprocessor: string & { __: 'condition string' } }>. - Those files will be loaded using glob import in the extension side. (see https://vite.dev/guide/features#glob-import)
- We will use those metadata to disable ineligible rules depending on the platform and environment. The string evaluation will be done using adblocker library (see the details in bottom of this issue). We will do this every time we enable static rulesets.
Regardless of the specific details, we have some potential blockers listed below for the future reference:
IFilter.prototype.toStringmethod cannot be perfect
Adblocker library mutates the filter representation internally to speed up matching and optimise the structure. This is currently seen as the limitation of the implementation. However, we can potentially set the rawFilter property of NetworkFilter to let toString work even without the debug flag of the engine.
This has been investigated by ghostery/adblocker#3694.
- Evaluation of preprocessor condition
We do have a function to evaluate the preprocessor condition in the adblocker library, but it's not simply exposed to the module entry point. If we want to evaluate the condition string outside of the library, we need to expose the function in the index file.
refs https://github.com/ghostery/adblocker/blob/master/packages/adblocker/src/preprocessor.ts#L103