Breadcrumbs

ADRs

ADRs

This page contains the eyeo Browser Ad-Filtering Solution architectural decision records (ADRs), which summarize the most important software design choices made during the development of the Solution.

These decisions address functional and non-functional requirements that eyeo finds architecturally significant.

Implementing ad-filtering from scratch

Chromium contains some ad-filtering functionality in the form of the subresource filter. However, the Chromium subresource filter has notable limitations: it does not support CSS element-hiding, JavaScript element hiding emulation, or snippets.

Patching these limitations requires significant tradeoffs:

  • More conflicts to solve after Chromium updates

  • Less flexibility to introduce new features and optimizations

  • Irreconcilably different objectives between eyeo and Chrome's authors

Since Chromium authors control subresource filter development, they may pursue business objectives misaligned with eyeo's vision. The eyeo team therefore chose to build ad-filtering capabilities from scratch rather than extend the existing subresource filter.

Using full or minified filter lists

eyeo previously used minified filter lists to reduce memory consumption for mobile users. Recent implementations achieved similar reductions through FlatBuffers adoption and moving from V8 to native implementation.

eyeo now uses full filter lists, which provide these benefits:

  • Allow for more filter rules

  • Improve overall user experience

  • Block a greater number of intrusive ads

  • Increase Acceptable Ads allowances for compliant publishers

Storing filter lists in FlatBuffer format

Filter lists are converted from plain text into FlatBuffers format after download. This approach offers significant advantages:

  • Reduced memory consumption to approximately 15 MB

  • Reduced startup time from seconds to milliseconds

  • No negative impact on page load time (except sites with long URLs)

  • Support for multi-threading and synchronous popup blocking

  • No deserialization required due to binary format

  • Memory-mapping capability for direct disk access

  • Data access speed equivalent to pointer dereferencing

Each FlatBuffers file contains only one filter list for these reasons:

  • Filter lists with different update schedules can be downloaded independently

  • Conversion time is reduced compared to combining all selected lists

  • Separate files prevent excessive combinations for long-term distribution

Moving user counting to a dedicated service

Coupling the user counting service with filter list downloads provides eyeo with insight into Solution usage across Chromium, OS, and platform versions.

As a dedicated service, this approach enables:

  • Monitoring of Acceptable Ads opt-out rates

  • Partners to serve and monetize filter lists from their own servers

For additional details, consult the user counting documentation.