25

Feature Request: Integration of SafariConverterLib for Enhanced Content Blocking in Orion Browser

What does your feature entail?

The proposed feature entails integrating the SafariConverterLib from AdGuard into the Orion browser. This library is designed to convert rules to the Content Blocking API and enabling the usage of scriptlets and extended CSS. Currently, Orion uses its own built-in converter, which is limited and primitive. By adopting SafariConverterLib, Orion can significantly enhance its content blocking capabilities, providing users with more robust and flexible ad-blocking and privacy protection features.

What is it for?

The primary purpose of this feature is to improve the effectiveness and flexibility of content blocking in the Orion browser. By leveraging SafariConverterLib, Orion can support a wider range of blocking rules, including advanced scriptlets and extended CSS, which are not currently supported by the built-in converter. This will allow users to block more types of unwanted content, such as ads, trackers, and other privacy-invading elements, thereby enhancing their browsing experience and privacy.

How will it affect existing workflows or user experience?

Integrating SafariConverterLib will have a positive impact on the user experience by providing more comprehensive and effective content blocking. Users will notice a reduction in ads, trackers, and other unwanted content, leading to faster page load times and improved privacy. The feature will not disrupt existing workflows but will enhance them by offering more powerful and flexible content blocking options.

What are the exact ways that you see a user using your proposed feature?

  1. Enhanced Ad-Blocking:

    • Users will be able to block a wider range of ads, including those that use advanced techniques to bypass traditional ad-blockers.
    • Example: A user visits a website with intrusive ads that the current converter cannot block. With SafariConverterLib, these ads are effectively blocked, providing a cleaner and faster browsing experience.

  2. Improved Privacy Protection:

    • Users will benefit from better protection against trackers and other privacy-invading elements.
    • Example: A user is concerned about being tracked across different websites. With the enhanced content blocking, trackers are blocked more effectively, reducing the risk of privacy breaches.

  3. Custom Rule Support:

    • Users can create and use custom blocking rules that utilise scriptlets and extended CSS.
    • Example: A user wants to block a specific type of content that is not covered by existing filters. With SafariConverterLib, they can create a custom rule using extended CSS or scriptlets to block this content (YouTube ads).

  4. Seamless Integration with Existing Filters:

    • The feature will work seamlessly with existing filter lists, enhancing their effectiveness.
    • Example: A user subscribes to a popular ad-blocking filter list. With SafariConverterLib, the filter list becomes more effective, blocking more types of unwanted content.

How would it work into the existing feature to extend its usefulness?

The integration of SafariConverterLib will extend the usefulness of the existing content blocking feature in Orion by providing a more powerful and flexible rule conversion engine. The current built-in converter will be replaced or augmented by SafariConverterLib, allowing Orion to support a wider range of blocking rules. This will result in more effective ad-blocking and privacy protection, enhancing the overall usefulness of the content blocking feature.

Examples from Other Browsers/Apps:

  • AdGuard for Safari: AdGuard uses SafariConverterLib to convert rules to the Content Blocking API, enabling advanced ad-blocking and privacy protection features. This has been well-received by users for its effectiveness and flexibility.
  • WebShield & wBlock: These extensions written by me and @0xCUBE respectively provide level of advanced content blocking by supporting scriptlets and extended CSS that is desirable for Orion.

By integrating SafariConverterLib, Orion can offer a similar level of advanced content blocking, making it a more attractive option for users who prioritize ad-blocking and privacy protection.

    Merged 3 posts from Use SafariConverterLib to implement conversion to Content Blocking API & Scriptlet Injection.

      Anatomy5803 Thanks for all the details. Can you add URLs to relevant content blocking lists and suggest Orion default after this is implemented?

          Vlad
          For macOS, I would suggest
          Base filter - https://filters.adtidy.org/extension/safari/filters/2_optimized.txt
          Tracking Protection filter - https://filters.adtidy.org/extension/safari/filters/3_optimized.txt
          Social Media filter - https://filters.adtidy.org/extension/safari/filters/4_optimized.txt
          Annoyances - https://filters.adtidy.org/extension/safari/filters/14_optimized.txt
          URL tracking - https://filters.adtidy.org/mac_v2/filters/17_optimized.txt

          For iOS,
          Base filter - https://filters.adtidy.org/ios/filters/2_optimized.txt
          Tracking Protection filter - https://filters.adtidy.org/ios/filters/3_optimized.txt
          Social Media filter - https://filters.adtidy.org/ios/filters/4_optimized.txt
          Annoyances - https://filters.adtidy.org/ios/filters/14_optimized.txt
          URL tracking - https://filters.adtidy.org/mac_v2/filters/17_optimized.txt
          Mobile - https://filters.adtidy.org/ios/filters/11_optimized.txt

          Incorporation of url tracking filter would require $removeparam support, which I've requested for here.

              @Vlad @joystmp for macOS all you need is: base, tracking protection, easyprivacy. for iOS you need: base, mobile, tracking protection, easyprivacy. If a user wants to enable other lists, like annoyances, they can do so. the default lists cause minimal breakage & provide the most benefit in terms of ad blocking & protecting privacy.

                yes please make this happen

                  2 months later
                  17 days later
                  11 days later

                  to the Devs: thank you so much for implementing this, really making the difference on desktop!
                  hope will be ported on mobile as well
                  thank you 🫶

                  • Vlad replied to this.

                    Vlad my bad, readily after this came on desktop I tried to load some non adp filterlists on mobile and it was crashing so I didn't bothered. Yesterday I tried again and filterlists load and mostly work! still cookie banners slips thru though... I'll make a bug report.

                        17 days later

                            @laiz did some testing and will rely on him providing a recommendation for default

                              hagezi lists aren't needed because they're dns only, and have no cosmetic filtering or scriptlet injection

                              @SerViette @joystmp @Vlad
                              Currently the performance between the default lists and the ones listed by joystmp is identical based on every test I have done. That includes the d3ward test and real world tests on some ad-infested sites such as https://www.bournemouthecho.co.uk/ and https://www.golem.de/. The performance is not at Firefox + uBlock Origin level yet but that is being worked on.

                              The ultimate goal would be to leverage the native blocker (incredibly fast, good performance and low resource usage) in conjunction with an optional advanced script-based blocking solution for the shortcomings mentioned by @Anatomy5803 — achieving a best of both worlds blocking experience.

                              To summarize, you should be fine with either block list configuration for now but exciting additions are on the horizon if all goes according to plan 🚀

                              If there are individuals who are well-versed in all things adblocking on WebKit, feel free to share your insights.

                                laiz
                                you can see difference if you load the "bypass paywall" filterlist because this now work.
                                I agree that a lot of cosmetic scriplet are not being injected at the right moment ( if you reload the second hit mostly work) that is mostly true for cookie banner.
                                I'm also in lockdown mode so could be some javascript doesn't work on my side

                                    SerViette note that this filterlists have different optimizations for ios, for safari macos and for macos adguard app...