search

uBlockOrigin / uBOL-home

uBO Lite home (MV3)
GNU General Public License v3.0
1.22k stars 50 forks source link

feature: maybe it's time to rethink the possibility of porting to Safari #52

Closed dminca closed 3 months ago

dminca commented 3 years ago

Just asking if it's possible to make this wonderful extension available for Safari now, given the following article published by Apple Developers in regards to converting web extensions for Safari

https://developer.apple.com/news/?id=qiz0arxc

Prerequisites

Description

[Description of the bug or feature]

A specific URL where the issue occurs

[A specific URL is MANDATORY for issue happening on a web page, even if it happens "everywhere"]

Steps to Reproduce

  1. [First Step]
  2. [Second Step]
  3. [and so on...]

Expected behavior:

[What you expected to happen]

Actual behavior:

[What actually happened]

Your environment

uBlock-user commented 3 years ago

https://www.reddit.com/r/uBlockOrigin/comments/hdz0bo/will_ublock_origin_back_to_macos_big_sur/fvoc7wk/

emikaadeo-git commented 2 years ago

Hi, maybe we can reconsider this with new experimental uBOLite MV3 API-based content blocker ? Safari have support for MV3 extensions since version 15.4 https://webkit.org/blog/12445/new-webkit-features-in-safari-15-4/#safari-web-extensions

gorhill commented 2 years ago

I don't have MacOS, this would have to be undertaken by a another volunteer developer.

Anyways, the implementation of declarativeNetRequest API on Safari is missing key capabilities for the current state of uBOL, it does not support conditions such as initiatorDomains, excludedInitiatorDomains, requestDomains, excludedRequestDomains. It also does not support action types redirect which will be needed once uBOL starts to use this capability.

Additionally, the Safari scripting API is also missing key capabilities, namely registeredContentScript, getRegisteredContentScript, unregisterContentScripts, updateContentScripts.

emikaadeo-git commented 2 years ago

@gorhill Hi, thanks for clarification.

henryhchchc commented 2 years ago

Just noticed that Apple added support for redirect 10 months ago as mentioned in https://webkit.org/blog/12193/release-notes-for-safari-technology-preview-139/

Added support for the redirect rule type in declarativeNetRequest, which requires host permissions to be granted for the host of the URL being redirected

I think this feature is available in Safari 16 but Apple haven't updated their documentation.

abarisain commented 1 year ago

It looks like safari 16.4, in beta, adds support for a lot of what is missing

image

That said, there is still this ridiculous requirement for it to be wrapped in an app, so someone will have to do that.

wavded commented 1 year ago

Safari 16.4 is out of beta now, not sure how close this gets us.

dminca commented 1 year ago

I’ve posted on Mastodon to Jen and Jon from the WebKit team, let’s see if they’re considering the missing capabilities mentioned by Raymond https://mastodontech.de/@dminca/110135906549832299

helvetiica commented 1 year ago

Any updates for Safari 17 (macOS Sonoma)?

gorhill commented 1 year ago

Transferring the issue to uBO Lite issues repo because if ever there is a port to Safari, that will be MV3 uBO Lite, not uBO, which requires MV2.

Knaledge commented 1 year ago

Are there currently any other barriers to entry for restarting development of the Safari Extension for uBOL? Perhaps there is an opportunity to engage the broader community to alleviate some of those impediments (if there are any)

stephenhawk8054 commented 1 year ago

Are there currently any other barriers to entry for restarting development of the Safari Extension for uBOL?

Maybe the only barrier is someone willing to fork and develop it for Safari?

hadig commented 1 year ago

Converting the firefox variant with the safari-web-extension-converter seems to work somehow out of the box on macOS Sonoma. The dashboard is blank, but extension badge is updating blocked ads count. Ad blocking seems to work, except youtube video ads.

arjpar commented 1 year ago

@hadig I'm also willing to work on porting UBO Lite with whatever code you have. Since UBO is such a highly used extension I'm sure there are others (even if few) that may be willing to work on porting it (UBO Lite) to Safari.

khesed commented 1 year ago

Made a PR: https://github.com/uBlockOrigin/uBOL-home/pull/71

aayushbhatia06 commented 10 months ago

I know uBlock team is famous for not taking donations (for all the right reasons I might add) but just wanted to say if another interested developer would like to develop but has monetary hurdles myself and a LOT of other Safari users would be happy to contribute.

Webtapper commented 8 months ago

Is there any update on this issue/suggestion? And also want to re-iterate I would also gladly donate just for starting uBlock Origin for Safari development again :)

arjpar commented 8 months ago

@Webtapper There's no update that I know of. A PR was made and rejected because Safari's implementation of DNR (declarativeNetRequest) lacks some specific features that uBO-Lite on Chrome/(Firefox?) requires to function properly. There was no minimal viable product in the PR. I'd be more than happy to develop a port, without donations, but I need to check how much support for DNR the Safari team has added. The WebKit devs have moved the project to GitHub, and they're willing to engage with the developer community. I'm sure I/someone else can look at Safari's documentation for DNR and see what is missing/implemented for an MVP for Safari to come to fruition.

In the PR I mentioned above, @gorhill stated that specific APIs weren't supported by Safari's DNR implementation, and an investigation was/is needed to figure out which APIs are and are not supported.

Like I said above, I'd be more than happy to port uBO-Lite to safari, I just haven't had the time. The requirement for a Safari extension to also be published on the app store and fulfilling the requirements for that ($100 for a dev license) is also one thing that may put a strain on a port.

Hopefully this answered your question!

stephenhawk8054 commented 8 months ago

Just FYI that any volunteers who want to take a look can check the table comparison of Safari's MV3 ability here: https://github.com/uBlockOrigin/uBOL-home/wiki/Availability-of-MV3-APIs-used-by-uBOL

I think it's better to PR and complete the table with clear sources first to have a better picture of Safari's compatibility with uBOL.

arjpar commented 8 months ago

For/to all those concerned, I'll be starting work on a port here, and then eventually pushing upstream.

arjpar commented 8 months ago

so update: it will need work to get it to work on safari. i have the extension running, but its very buggy and actually breaks safari haha. it doesn't support "storage" or "type" keys in the manifest, which may prevent a mvp until apple adds those keys.

gorhill commented 8 months ago

it doesn't support "storage" or "type" keys in the manifest

There is a manifest.json version for each platform, so having a specific one for Safari is fine:

For Edge, it's a patched version of Chromium manifest.json because the web-accessible-resources had to reside at the root of the extension directory (patcher).

Once you have a proper Safari-compliant manifest.json, then it will be a matter of finding out which APIs are missing or behave differently in Safari.

Webtapper commented 8 months ago

Thanks @arjpar. I do not have the knowledge to help with any technical challenges here - but if we are at the stage of needing to raise $100 for the developer license I’d love to contribute as well. I’ll follow it here and appreciate your updates so far!!

arjpar commented 8 months ago

For those wondering, I'll be posting updates here

arjpar commented 7 months ago

Due to the issues explained here which explains the problems I've run into, a port of uBlock Origin Lite to Safari is currently not possible. It is, however, possible to make an excellent free & open source wide spectrum (ad blocker) content blocker for Safari using the relevant Safari-specific APIs and technologies for content blocking. But that is beyond the scope of my port, and it would not be a port of uBlock Origin Lite, it would be either a fork or a new project altogether. I don't have the time, effort, or knowledge of Apple ecosystem development to create such an extension. I welcome anyone who has those things to consider creating it if they want to. For the aforementioned reasons my Safari port of uBlock Origin Lite will cease development. (All the work I've been doing so far was locally) I doubt Apple will release the needed MV3 DNR APIs soon given that they have their own Safari specific ways of doing things. If they do eventually release those APIs and don't neuter them, I probably won't be working on a port, due to the previous reasons of not creating a new Safari ad block project - time, effort, and knowledge.

MisutaaAsriel commented 7 months ago

Fair enough. You are correct in that Safari has its own APIs which serve similar purposes (and in some ways, I would argue have benefits over DNR APIs, but at the expense of cross-compatibility), so a Safari port would likely be its own thing at this point, which hybridizes compatible uBlock methods with Safari specific Content Blocking methods.

Likewise, whilst App Store distribution isn't necessary, the extension being unsigned or otherwise signed by an unrecognized signing authority would make distribution more cumbersome.

Thank you for at least trying and/or looking into it. As a Safari user looking to move away from AdGuard, the attempt was appreciated.

fanckush commented 5 months ago

does Safari 18 in the new macOS Sequoia have any effect on the this issue?

arjpar commented 5 months ago

@fanckush I don't believe so. I looked at WebKit's changes for WWDC, and it didn't mention any major changes to content blocking. I only browsed their blog page though, and didn't see the specific videos on it, so maybe there are changes.

With that said, I have thought about learning about Apple ecosystem app development and creating a free open-source ad blocker for Safari as an extension. It's just a thought. If there's sufficient user desire for one, I'd really start to consider creating one. Currently there's Wipr (paid), and AdGuard (but different apps for macOS (free) and iOS (paid version for all the goodies)). Given that all the ad blocking solutions for Safari out there don't fit my desires entirely, I might actually start creating one out of interest - but it wouldn't be a port of uBO Lite, since that's not possible.

Handwork5615 commented 5 months ago

@arjpar Yes please 🙏🏻 other options are available as you mentioned above but uBlock is best in class. ublock origin is the only reason many people use other browsers. Please create one for safari.

fanckush commented 5 months ago

btw, if you like Safari but can't use it because UBO isn't available, you can give Orion a try

it's still in beta I think, so it can be a bit buggy here and there

JulianKahnert commented 5 months ago

@arjpar I really would love to have a Safari Extension! Ican help with questions regarding the Apple ecosystem and deploying an extension! But I have no experience with the development of an ad blocker.

arjpar commented 5 months ago

@Handwork5615 @JulianKahnert To all those concerned: I've started work on the extension. I'm still learning Swift though. I'll be writing up a design document to detail the architecture soon, it will be in Markdown format in the project's repository. Speaking of a repository, would you all like the project to be in a GitHub organization instead of my main profile? I would like it to be a joint effort, and build a community of collaborators. This means that if I eventually move on to something else, the project will still be sustained.

JulianKahnert commented 5 months ago

@arjpar What about a project in the uBlockOrigin org? If you have a PR and want a Code Review, just let me know 😊

arjpar commented 5 months ago

@JulianKahnert Like I said before, this project wouldn't be a port of uBlock Origin, because it doesn't share the same codebase as uBlock Origin. I would want to make it as close as uBlock Origin as I can, if I can. Also @fanckush I'm a Orion Contributor, and have access to private Orion RC builds. uBlock Origin doesn't apply cosmetic filtering on Orion until you manually reload the page. The Orion dev team is working on fixing smaller issues rather than bigs ones to improve the stability of the product. Eventually, it will work. As I mentioned above (if I did), I think it might be possible to make an ad blocker for Safari that's even more powerful than uBlock Origin Lite, using the relevant Safari-unique APIs. I'll have to see if I can make it work.

Handwork5615 commented 5 months ago

@Handwork5615 @JulianKahnert To all those concerned: I've started work on the extension. I'm still learning Swift though. I'll be writing up a design document to detail the architecture soon, it will be in Markdown format in the project's repository. Speaking of a repository, would you all like the project to be in a GitHub organization instead of my main profile? I would like it to be a joint effort, and build a community of collaborators. This means that if I eventually move on to something else, the project will still be sustained.

Please read this, posted 17 hours ago on reddit by someone, just look at the upvote of uBlock origin comment. You'll get lot of support from community for sure. https://www.reddit.com/r/mac/s/hCxASUFhpN

arjpar commented 5 months ago

@Handwork5615 I read it, and I'm happy many people would support the project. I was thinking about writing my own Network Filtering Engine, thats on par or even better than uBlock Origin's, but I'm not sure if it would be allowed by Apple's App Store policies or if the APIs allow it (I don't believe so). Regardless I want to try to support the following:

It will also be written entirely in Swift, SwiftUI, be a Catalyst & Universal App. Since it will use the latest technologies provided, it will only be available on recent versions of iOS, iPadOS, macOS & visionOS. These are just my aspirational goals. I think the Apple Documentation page for Content Blocking might be out of date, or maybe I'm just not looking in the right place. Again, these are just my idealistic/aspirational goals, I need to do further investigating to see if its feasible. I'm also still learning Swift, SwiftUI, & Apple Development, but I want to implement features in the most optimal way possible.

abarisain commented 5 months ago

I am very, very sorry to be the party pooper but it may be time to move this discussion elsewhere, please. I for one am satisfied with wipr and only interested in ublock.

arjpar commented 5 months ago

@dminca @gorhill This issue should be closed, since it's not possible to port uBlock Origin Lite to Safari currently. I have created an organization & repository to try to "re-create" uBlock Origin as much as we can in Safari using the Safari-relevant APIs. Further discussion can take place there. I'm currently in the design phase of the app, rather than just moving fast & breaking things.

dminca commented 5 months ago

@dminca @gorhill This issue should be closed, since it's not possible to port uBlock Origin Lite to Safari currently. I have created an organization & repository to try to "re-create" uBlock Origin as much as we can in Safari using the Safari-relevant API. Further discussion can take place there. I'm currently in the design phase of the app, rather than just moving fast & breaking things.

fair enough. Appreciate the effort of trying to integrate it.

Unfortunately the Safari team from Apple was not so communicative 😔

gorhill commented 3 months ago

This issue should be closed, since it's not possible to port uBlock Origin Lite to Safari currently

Closing as suggested. Maybe in some future this will be possible, in such case the best action is for volunteer(s) to submit a pull request to bring support to Safari -- opening an issue asking to bring support to Safari is not really the way to go. Opening a discussion about this is fine.

Dacatzgoescodin5267 commented 3 months ago

Two words. FUCK and OFF! since im not switching to the shitty lite version nor switching to firefox. I'm going to stand my fucking ground whenever you like it or not.

vitorgalvao commented 3 months ago

The only thing such an attitude accomplishes is forcing maintainers to block the disruptor and lock the thread. Everyone loses and it does nothing to advance the cause. On the contrary, it makes people more unwilling to help.

Please don’t do that. Volunteers are giving away their time and expertise for free so everyone else can enjoy. A little courtesy and respect is the minimum.

I’m going to take the opportunity to thank the maintainers of the uBlock Origin organisation for all their work, with a special mention to @gorhill for starting the project.

It’s a shame we can’t make it work in Safari—hopefully that is just a “yet”—but thank you all for looking into it and answering questions.

arjpar commented 3 months ago

It’s a shame we can’t make it work in Safari

@vitorgalvao To clarify, while it’s not possible to directly run uBlock Origin Lite (uBO Lite) on Safari as a WebExtension, there is a viable alternative that achieves similar functionality. Although we don’t share any code with uBO Lite, we’ve developed a solution that emulates its behavior from the end-user’s perspective.

We’ve achieved this by leveraging AdGuard’s filter lists, which are specifically optimized for mobile and Safari. The result is a tool that falls between uBlock Origin Lite and the full uBlock Origin (as used in Firefox) in terms of effectiveness. We’ve intentionally avoided naming it uBO Lite since it doesn’t share the same codebase, but it does match and even surpass uBO Lite in certain areas, such as support for custom filter lists and improved performance.

Our approach involves converting everything to Safari’s content-blocking format, including transforming extended CSS and scriptlets to JSON, which we then execute in the respective files. Although it’s currently in an alpha-beta stage, it works well for the vast majority of users (around 99%).

If anyone is interested, I’m happy to provide further details, though I recognize that this might be beyond the scope of the current discussion. The key takeaway is that while a direct port of uBO Lite to Safari isn’t feasible, a comparable solution is indeed possible using Safari’s APIs and other existing technologies. It might not be uBO Lite by name, but functionally, it delivers a very similar experience, often with added benefits.

vitorgalvao commented 3 months ago

If you (or anyone) are/is interested I can provide more details.

Yes, please. I’m curious in what you mean specifically.

arjpar commented 3 months ago

If you (or anyone) are/is interested I can provide more details.

Yes, please. I’m curious in what you mean specifically.

To elaborate, we utilize AdGuard’s ConverterLib to transform optimized filter lists for Safari, including AdGuard Base and others that are already comparable to uBlock Origin’s (uBO) lists, and surpass uBO Lite’s lists due to customization options (such as toggling filters on/off and adding custom lists which is yet to be fully implemented in WebShield). These lists are converted to JSON: static filters and rules supported by Safari’s Content Blocking API become a content-blocking JSON file, while scriptlets and extended CSS filters are converted into a single JSON file and executed separately by a dedicated scriptlet and extended CSS JavaScript file.

We’re planning to fork and enhance ConverterLib to further optimize performance and efficiency, though it’s already quite robust. The primary performance bottleneck comes from scriptlet injection, so we’re also working on improving their scriptlet library, with the aim of contributing these improvements upstream for the benefit of everyone.

The reason we don’t use uBlock Origin’s lists is that there aren’t optimized filter lists for Safari/mobile like there are with AdGuard. With AdGuard’s lists, we achieve nearly all the benefits (around 96%) while using fewer than ~80k rules, which is fewer than (or on par with) uBO’s default set.

The project I’m working on, WebShield, is designed to be more efficient and performant than both uBO Lite and possibly even uBO. Our content blocking (static and some cosmetic filtering) consumes minimal CPU and memory resources—less than 1% of CPU and a few kilobytes of RAM, as far as I recall. Scriptlet injection and extended CSS use around 40MB of memory. WebShield also allows for custom filter lists, enabling/disabling defaults, and even an element zapper mode (which is yet to be implemented but feasible).

The reason the content blocking is so lightweight is that it’s converted into native WebKit rules. I’m working on optimizing the entire pipeline, from our current code to the conversion process (via SafariConverterLib, also known as BlockKit), and scriptlet/extended CSS injection. I’m also considering using Protobuf instead of JSON for scriptlet/extended CSS injection, as it’s faster, though I need to weigh the trade-offs.

In my opinion, WebShield already outperforms alternatives like Wipr 2, which lacks customisation and relies on some manual filter list maintenance, and 1Blocker, which is paid and seems to use custom-curated lists that don’t block as effectively as Wipr 2, AdGuard, or WebShield. Moreover, AdGuard requires separate purchases for macOS and iOS to unlock all features, whereas WebShield will always be free (in both freedom and cost) and open-source. I’m currently evaluating different licensing options to best serve the community and Safari users.

If you or anyone else has further questions, feel free to ask, though it might be more appropriate to discuss this on the WebShield discussions page, as this conversation might be beyond the scope of a uBO issue tracker. We also have a sister project, wBlock, which is developed in parallel with WebShield and shares much of its codebase. Questions about wBlock can be directed to its issue tracker, though I’m not sure if @0xCUB3 will open GitHub discussions for that repository.

0xCUB3 commented 3 months ago

If you (or anyone) are/is interested I can provide more details.

Yes, please. I’m curious in what you mean specifically.

To elaborate, we utilize AdGuard’s ConverterLib to transform optimized filter lists for Safari, including AdGuard Base and others that are already comparable to uBlock Origin’s (uBO) lists, and surpass uBO Lite’s lists due to customization options (such as toggling filters on/off and adding custom lists which is yet to be fully implemented in WebShield). These lists are converted to JSON: static filters and rules supported by Safari’s Content Blocking API become a content-blocking JSON file, while scriptlets and extended CSS filters are converted into a single JSON file and executed separately by a dedicated scriptlet and extended CSS JavaScript file.

We’re planning to fork and enhance ConverterLib to further optimize performance and efficiency, though it’s already quite robust. The primary performance bottleneck comes from scriptlet injection, so we’re also working on improving their scriptlet library, with the aim of contributing these improvements upstream for the benefit of everyone.

The reason we don’t use uBlock Origin’s lists is that there aren’t optimized filter lists for Safari/mobile like there are with AdGuard. With AdGuard’s lists, we achieve nearly all the benefits (around 96%) while using fewer than ~80k rules, which is fewer than (or on par with) uBO’s default set.

The project I’m working on, WebShield, is designed to be more efficient and performant than both uBO Lite and possibly even uBO. Our content blocking (static and some cosmetic filtering) consumes minimal CPU and memory resources—less than 1% of CPU and a few kilobytes of RAM, as far as I recall. Scriptlet injection and extended CSS use around 40MB of memory. WebShield also allows for custom filter lists, enabling/disabling defaults, and even an element zapper mode (which is yet to be implemented but feasible).

The reason the content blocking is so lightweight is that it’s converted into native WebKit rules. I’m working on optimizing the entire pipeline, from our current code to the conversion process (via SafariConverterLib, also known as BlockKit), and scriptlet/extended CSS injection. I’m also considering using Protobuf instead of JSON for scriptlet/extended CSS injection, as it’s faster, though I need to weigh the trade-offs.

In my opinion, WebShield already outperforms alternatives like Wipr 2, which lacks customisation and relies on some manual filter list maintenance, and 1Blocker, which is paid and seems to use custom-curated lists that don’t block as effectively as Wipr 2, AdGuard, or WebShield. Moreover, AdGuard requires separate purchases for macOS and iOS to unlock all features, whereas WebShield will always be free (in both freedom and cost) and open-source. I’m currently evaluating different licensing options to best serve the community and Safari users.

If you or anyone else has further questions, feel free to ask, though it might be more appropriate to discuss this on the WebShield discussions page, as this conversation might be beyond the scope of a uBO issue tracker. We also have a sister project, wBlock, which is developed in parallel with WebShield and shares much of its codebase. Questions about wBlock can be directed to its issue tracker, though I’m not sure if @0xCUB3 will open GitHub discussions for that repository.

To this point, wBlock is ready for use as an alpha (I'm the dev btw). You just have to build it with your own Xcode. I think porting ublock is not only feasible, but would be very beneficial.

abarisain commented 3 months ago

Can we please take this elsewhere?

The explanation was interesting, but I think that this is not the place to discuss this anymore

All that will end up with is subscribers never being able to know of a safari uBO light via this issue because this thread ends up closed.

leo60228 commented 1 month ago

Due to the issues explained here which explains the problems I've run into, a port of uBlock Origin Lite to Safari is currently not possible.

@arjpar The linked post was deleted. What were the issues described?

arjpar commented 1 month ago

@leo60228

To answer your question: it's because Safari (at the time, not sure about recent versions of WebKit) didn't support the required DNR & other APIs to produce a MVP for uBO Lite.

While Safari's limited APIs prevent a direct port of uBlock Origin Lite, I'm developing a full content blocking solution (like uBlock Origin) specifically for Safari that's showing promising results. Here's what's been accomplished:

Key Features:

Current Status:

Technical Notes:

The project leverages Safari's native capabilities to deliver a robust content blocking solution, despite the platform's API limitations. Instead of compromising with a lighter version, we're creating a full-featured alternative optimized for Safari's architecture.

It will be (and is) free & open source.

antdude commented 1 month ago

When will the first public compiled prerelease version be able for us to try?