# Replace AdGuard for Safari recommendation with uBlock Origin Lite **URL:** https://discuss.privacyguides.net/t/replace-adguard-for-safari-recommendation-with-ublock-origin-lite/27252 **Category:** Tool Suggestions **Created:** 2025-05-03T19:27:09Z **Posts:** 92 ## Post 1 by @anonfox — 2025-05-03T19:27:09Z > > > ### Update > > 2025-05-13 > > There is now a beta version for Safari on both macOS and… iOS, which can be installed through TestFlight, click the following link: > > > > ### Description > > Continuing from , which had become too large, to focus on remaining technical issues. > > To build a local version of uBO Lite for Safari, in a bash-compatible shell and at repo root (corrected as per @ramsey's post below): > > git clone git@github.com:gorhill/uBlock.git > cd uBlock/ > make mv3-safari > > The extension will be at `dist/build/uBOLite.safari/`, and can be sideloaded into Safari 18.4+ following the instructions at [Temporarily install a web extension folder in macOS Safari](https://developer.apple.com/documentation/safariservices/running-your-safari-web-extension#Temporarily-install-a-web-extension-folder-in-macOS-Safari) > > Remaining issues (will update as needed): > > - `excludeMatches` in [scripting.RegisteredContentScript](https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/scripting/RegisteredContentScript) appears to be ignored > - This causes lower filtering mode such as Basic or No filtering to still be filtered through injected CSS and scriptlets > - Fix has been merged into WebKit: https://github.com/WebKit/WebKit/pull/43398 > - ~~DNR's `allowAllRequests` has no effect, even though it's documented as being supported: ~~ > - This prevents the ability to disable filtering on site > - Ghostery is [using a different rule than `allowAllRequests`](https://github.com/ghostery/ghostery-extension/blob/4a955b1b7f59e5ee7be44d0c29ff653eaf85fabc/src/background/paused.js#L92-L102) > - This requires [Safari-specific code paths](https://github.com/gorhill/uBlock/blob/b5651417aacd6024cb0a89a2b357563c0761a5e6/platform/mv3/safari/ext-compat.js#L105-L129) > - Being addressed by Safari: > - ~~Redirects to local `web_accessible_resources` do not work, see ("Advanced network filters")~~ > - Removing leading `/` in resource paths in manifest [fixed the issue](https://github.com/gorhill/uBlock/blob/b5651417aacd6024cb0a89a2b357563c0761a5e6/platform/mv3/make-rulesets.js#L1448). Removing the leading `/` does not affect uBOL in other browsers. > - Lot of regex-based filters are rejected compared to Chromium version > - https://bugs.webkit.org/show_bug.cgi?id=260970 > - ~~The zapper does not work, possibly related to the `web_accessible_resources` issue above~~ > - ~~https://bugs.webkit.org/show_bug.cgi?id=246617~~ > - Using a workaround in Safari: [use `src` attribute before inserting iframe into DOM](https://github.com/gorhill/uBlock/blob/b5651417aacd6024cb0a89a2b357563c0761a5e6/platform/mv3/extension/js/scripting/zapper.js#L398-L404) > - Being addressed by Safari: > - ~~`youtube.com` does not load (blank page). It loads if I disable the Default ruleset -- so there is a rule in there which is causing the issue. However Safari does not support finding which specific rule is blocking which specific resource URL~~ > - Caused by the filter `||googlesyndication.com^$domain=blogto.com|youtube.com`. Conversion to DNR rule put `googlesyndication.com` into `condition.requestDomains`, so it appears `requestDomains` is either not supported, or interpreted differently in Safari. > - Reference material: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/4971ZS9cI7E > - A very [specific mitigation has been added](https://github.com/gorhill/uBlock/blob/b5651417aacd6024cb0a89a2b357563c0761a5e6/src/js/static-dnr-filtering.js#L440-L452) to prevent the breakage, but there is a need to understand how Safari interprets requestDomains since that property is used in thousands of DNR rules. > - Being addressed by Safari: > - Strict-blocking does not work > - https://bugs.webkit.org/show_bug.cgi?id=256054 > - ~~Though possibly it could be that special regex characters are being used (e.g. `^`), which are interpreted literally by Safari DNR's engine, see https://github.com/w3c/webextensions/issues/344~~ No, [JS's `RegExp` is literally used to match `regexFilter`](https://github.com/WebKit/WebKit/blob/8867ffb89ae174fb48924753375a451875bf26ea/Source/WebCore/contentextensions/ContentExtensionActions.cpp#L452-L459) > > Help to investigate these issues is welcome. > > ### uBO Lite version > > Local, build from command line > > ### Browser name and version > > Safari 18.4 > > ### Operating system and version > > MacOS 15.4 Might worth getting recommended instead of AdGuard in the future? --- ## Post 2 by @anon39279085 — 2025-05-03T19:43:05Z worth recommending of course, Let me know when that comes out, the page will soon be just uBlock Origin and Origin Lite heh --- ## Post 3 by @phnx — 2025-05-03T19:47:05Z Added #waiting tag since it’s currently in beta. Once in stable I see no reason why the existing uBlock Origin Lite recommendation shouldn’t extend to all supported browsers. Whether the existing AdGuard recommendation should be removed is arguably the bigger question here. --- ## Post 4 by @anon80779245 — 2025-05-03T21:30:09Z Nice to see Safari getting a good content blocker --- ## Post 5 by @securitybrahh — 2025-05-04T04:12:22Z is this on desktop? mobile prob just has this > **[Block Ads and Annoyances](https://guide.hyperweb.app/remove-annoyances/block-content/)** > > Hyperweb has a powerful built-in blocker that lets you block --- ## Post 6 by @anonymous261 — 2025-05-04T04:17:52Z On mobile. Adguard is PG’s current recommendation for iOS, and HyperWeb comparitively seems to have a less established track record. --- ## Post 7 by @xe3 — 2025-05-04T04:43:08Z > [@anon80779245](#): > > Nice to see Safari getting a good content blocker Adguard Pro has been really solid for me on iOS. I’d prefer uBlock Origin if it were possible, but since it isn’t possible, I’m happy enough with Adguard. I wonder how uBO _Lite_ will compare. I have only very limited experience with Lite, so I’m not fully aware of its limitations, nor how iOSes own limitations might impact it (or not). If/when it is released, I’ll be excited to try it out. --- ## Post 8 by @unpersonal — 2025-05-04T05:27:15Z Hyperweb does not seem to be available for all countries --- ## Post 10 by @xe3 — 2025-05-05T18:11:00Z > [@tibetfuchs](#): > > Thats very exiting! I’d love ublock for iOS Small but meaningful (pedantic) clarification: _“uBlock”_ =/= _“uBlock Origin” (uBO)_ =/= _“uBlock Origin Lite” (uBOL)_ The latter two come from the same developer/project, and the former is unaffiliated. uBlock Origin Lite (uBOL) is a more feature and capability limited version of uBO that was made to work within Google’s new MV3 limitations for Chrome. What is being worked on currently is being called a “minimally working uBOL” for iOS so don’t expect the full uBO experience or featureset. Still it’s positive news, some uBO(L) for iOS is better than no uBO for iOS :slight_smile: --- ## Post 12 by @xe3 — 2025-05-05T21:12:04Z > [@tibetfuchs](#): > > I am curious how this „minimally working uBOL“ compares to firefox focus TIme will tell I guess. I think uBOL is probably more capable than Firefox Focus’s content blocking on its own, but I don’t know what Gorhill (uBO/L developer) means by “minimally working” and I don’t know what iOS specific limitations might further limit uBOL beyond its existing limitations. --- ## Post 13 by @anonfox — 2025-05-05T22:24:40Z There is already a signed MacOS version! [Safari issues to resolve for a minimally working uBOL · Issue #327 · uBlockOrigin/uBOL-home · GitHub](https://github.com/uBlockOrigin/uBOL-home/issues/327#issuecomment-2852476410) --- ## Post 14 by @anonfox — 2025-05-08T15:36:43Z I’m wondering whether the AdGuard extension is more performant since [it uses](https://github.com/AdguardTeam/SafariConverterLib) Safari’s [content blocker API](https://developer.apple.com/documentation/safariservices/creating-a-content-blocker). It also doesn’t need the developer to update their extension just to update filterlists. --- ## Post 15 by @anon80779245 — 2025-05-08T16:09:07Z > [@securitybrahh](#): > > is this on desktop? mobile prob just has this Why not just use Brave ? --- ## Post 16 by @xe3 — 2025-05-08T16:36:59Z > [@anon80779245](#): > > Why not just use Brave ? Not sure if this question is meant for @securitybrahh or me (Since you quoted them, but replied to my comment) but my answer would be: Because I asked the inverse question, and couldn’t find a reason not: _“Why not just use Safari?”_ I did initially try Brave, and do have it installed, but I couldn’t find any comparative advantages to Brave iOS over Safrai. I thought it might have more sophisticated adblocking but its not meaningfully better, I thought it might have better blocking for PWAs but it doesn’t, that is an iOS limitation. Basically I didn’t find anything especially wrong with Brave on iOS, but I also couldn’t find any reason to prefer it to Safari + Adguard. --- ## Post 17 by @anon80779245 — 2025-05-08T17:26:48Z > [@xe3](#): > > Not sure if this question is meant for @securitybrahh or me (Since you quoted them, but replied to my comment) but my answer would be: The answer was for @securitybrahh because I didn’t see the need for this custom browser that may not be trustworthy. But there are still [concerns about Safari data collection](https://surfshark.com/research/chart/data-collection-mobile-browsers) --- ## Post 18 by @xe3 — 2025-05-08T19:02:51Z > [@anon80779245](#): > > The answer was for @securitybrahh because I didn’t see the need for this custom browser that may not be trustworthy. In that case I agree with you, Brave (or Safari + Adguard) makes more sense than a rather unknown browser with an adblocker. > But there are still concerns about Safari ~~data collection~~ wanting the `coarse location` permission [Surfshark Blogpost](https://surfshark.com/research/chart/data-collection-mobile-browsers) The only reference I see to Safari in that article mentions that it asks for the `coarse location` permission on iOS which is just an app permission, and isn’t totally unreasonable for a browser, it doesn’t indicate “data collection” though it could be used for that purpose. Still, I’d agree it’s a permission to be aware of, and possibly disable. And because it’s just an app permission, it’s in your control whether you want that permission enabled or not. But realistically, if you are using an iPhone you are already choosing to trust Apple to responsibly handle location data on your device, regardless of your browser choice or whether that browser is granted access to location information. Because irrespective of the browser you choose or the permissions you give it, you must trust the OS and hardware which is in a much more privileged position wrt location data than the browser is. If Apple intended to do nefarious things with your location data, they wouldn’t need to use the browser to do so. > **Why a browser would want access to location info?** > > I personally prefer my browser to not be location aware unless I explicitly allow it (beyond what can be inferred from IP). but I can understand why mainstream browser makers catering to mainstream users (whose search queries often look like: “weather” or “movie times” or “Cafe near me”) ask for the location permission. Even for us in the privacy space, there are valid reasons we might want to allow the browser location access to location info (e.g. if you use Google Maps in the browser or Uber’s webapp instead of the mobile app as harm reduction strategies). With that said I still feel it would be better if it was opt-in and an explicit choice (maybe it was, I don’t actually recall). --- ## Post 19 by @securitybrahh — 2025-05-09T07:01:29Z > [@xe3](#): > > Basically I didn’t find anything especially wrong with Brave on iOS, but I also couldn’t find any reason to prefer it to Safari + Adguard. /+ Safari is native to IOS. --- ## Post 20 by @anon80779245 — 2025-05-10T15:32:58Z It is now notarised and available, but not yet full stable release [Release uBOLite\_2025.5.7.895-beta · uBlockOrigin/uBOL-home · GitHub](https://github.com/uBlockOrigin/uBOL-home/releases/tag/uBOLite_2025.5.7.895-beta) BTW: uBlock origin Lite is back on Firefox for real this time --- ## Post 21 by @anonymous335 — 2025-05-10T22:01:41Z How to install this on iOS? I don’t see it on the App Store. --- ## Post 22 by @anon80779245 — 2025-05-11T08:30:49Z It might not be available in the store yet as it’s still in beta, but it is now approved (notarised) by Apple. Edit: I have no idea whether all Safari extensions are also available on iOS --- ## Post 23 by @anonfox — 2025-05-11T15:34:58Z Sorry, that’s likely false since [even uBOL filters are converted to content blockers rules](https://github.com/uBlockOrigin/uBOL-home/issues/327#:~:text=To%20be%20clear%2C%20it%20seems%20that%20the%20network%20request%20matching%20is%20very%20fast%2C%20it's%20only%20the%20conversion%20from%20DNR%20rules%20that%20is%20slow.%20That%20shouldn't%20be%20too%20much%20of%20an%20issue%20though%20since%20toggling%20on/off%20%22no%20filtering%22%20is%20not%20something%20that%20people%20do%20repeatedly%20all%20the%20time). --- ## Post 24 by @anonfox — 2025-05-11T15:36:06Z It’s still being reviewed by Apple, but it will get posted on testflight first. --- ## Post 25 by @anon80779245 — 2025-05-29T09:45:20Z I actually believe we shouldn’t remove AdGuard recommendation. In fact, IMO we should even recommend it as a MV3 extension for Chromium browsers. The reason is AdGuard is much more powerful than Ublock Origin Lite (ubol). For example, in Addguard you can add your own cosmetic/procedural rules (at least on Chromium), while ubol doesn’t allow you to (it _might_ be [added](https://github.com/uBlockOrigin/uBOL-home/issues/325) in the future). Also, Adguard will allow you to add custom lists in their next big release (this will necessitate enabling Chrome dev mode though). --- ## Post 26 by @TigerBanded — 2025-05-29T13:31:53Z Ublock lite is out on TestFlight for Safari if anyone wants to give it a try. I tried it out. It still needs some work. I’ll stick with Adguard for now. > **[Join the uBlock Origin Lite beta](https://testflight.apple.com/join/JjTcThrV)** > > Available on iOS --- ## Post 27 by @Plum — 2025-06-05T14:21:07Z One major difference between uBOL and AdGuard is that AdGuard is using the native content blockers function in Safari in addition to an extension, while uBOL is only an extension. This is major because extensions on iOS do not run in PWAs or web previews but content blockers do (on MacOS extensions do run in PWAs). So if only using uBOL on iOS, there are no content blocking capabilities in PWAs. This would go against the usual recommendation to use PWAs over native apps for privacy. --- ## Post 28 by @anon80779245 — 2025-06-05T15:46:47Z > [@Plum](#): > > One major difference between uBOL and AdGuard is that AdGuard is using the native content blockers function in Safari in addition to an extension, while uBOL is only an extension. Isn’t “Adguard for Safari” an exension? I am a bit confused here. --- ## Post 29 by @Plum — 2025-06-05T17:16:58Z There are two ways an app can go about blocking content in Safari. One way is through using the native “content blockers” app extension built into Safari. These are the classic rules lists that can block cookies, loading certain things, and can hide elements from the page. Content blockers cannot see anything on a webpage or report anything back to its app. Content blockers predated Safari supporting extensions. Extensions are more robust and can do more things like view the contents of a webpage and run code. These can be enabled on a per site basis. Extensions can interface with its app. Examples of extension functionality that is not possible with content blockers include a password manager inserting a drop down account selector on login screens and blocking ads on YouTube. Extensions and content blockers run in all Safari windows on MacOS. In Safari on iOS, extensions only run in the main app and no not run in PWAs or web views. Content blockers do run in PWAs and web views. AdGuard for Safari uses both content blockers and an extension. The content blockers are used for the usual blocklists and the extension is used for more complex blocking. [Here is the info from AdGuard on the difference](https://adguard.com/kb/adguard-for-ios/web-extension/). uBOL only uses the extension function so its blocking capabilities are limited in PWAs on iOS. --- ## Post 31 by @anonfox — 2025-06-08T21:54:28Z > [@anon19961771](#): > > Does uBlock Origin Lite have a smaller attack surface than AdGuard? Not sure. I heard that AdGuard for iOS is MV2 but couldn’t confirm it myself. > [@anon19961771](#): > > I think regardless, once uBO Lite is added to the Firefox AMO, uBlock Origin should be removed since there’s no good reason to use that over the far less insecure MV3 content blockers. This is off-topic and has already been discussed [Proposal: Remove uBlock Origin and update criteria for browser extensions](https://discuss.privacyguides.net/t/proposal-remove-ublock-origin-and-update-criteria-for-browser-extensions/24205) --- ## Post 32 by @fria — 2025-08-05T12:58:01Z The extension is out now on the App Store: [https://apps.apple.com/app/ublock-origin-lite/id6745342698](https://apps.apple.com/ca/app/ublock-origin-lite/id6745342698) I think now we can remove the #waiting tag and start moving forward with this what do y’all think [@team](/groups/team) --- ## Post 33 by @anon94117004 — 2025-08-05T14:52:19Z > [@Plum](#): > > This is major because extensions on iOS do not run in PWAs or web previews but content blockers do (on MacOS extensions do run in PWAs). Is this still an issue? It seems like it’d be a blocker or at least worth a warning if uBOL is listed. --- ## Post 36 by @jordan — 2025-08-05T23:28:35Z We should probably wait until we see it getting regular updates before recommending it. The way I understand how it works is that the block lists require the application to be regularly updated for it to stay up to date. --- ## Post 37 by @TigerBanded — 2025-08-05T23:49:50Z That’s a good point. I can’t imagine the app wouldn’t be updated regularly, but best to wait and see. I pulled this from the uBOL Q&A: > There are no filter lists proper in uBOL. There are declarative rulesets and scripts which are the results of compiling filter lists when the extension package is generated. Those declarative rulesets and scripts are updated only when the extension itself updates. As a result, uBOL never makes network requests to any remote servers. --- ## Post 38 by @anon39279085 — 2025-08-05T11:59:07Z Objection on removing AdGuard ![IMG_0016](https://forum-uploads.privacyguidesusercontent.com/original/2X/7/7ac6569ce68b612e5d7c085e36b4932c353cfb98.jpeg) Until it will be available everywhere, we can then remove AdGuard for good [In fact thats what I want to do when UBoL comes out on my iPhone] --- ## Post 39 by @anon57862721 — 2025-08-05T12:02:59Z ![IMG_0426](https://forum-uploads.privacyguidesusercontent.com/original/2X/3/34eae8c6a8758a0743118d3df8ecdf0e9c60128d.png) It’s not working for me. --- ## Post 40 by @anon39279085 — 2025-08-05T12:03:34Z Seems we have a double objection wow --- ## Post 41 by @anonfox — 2025-08-05T12:20:49Z it needs iOS 18.6 or later --- ## Post 42 by @anon57862721 — 2025-08-05T12:24:49Z Damn. I thought I was running on the latest version. Somehow I missed that. Thanks --- ## Post 43 by @anonfox — 2025-08-05T12:32:26Z [https://github.com/uBlockOrigin/uBOL-home/issues/358#issuecomment-3155012748](https://github.com/uBlockOrigin/uBOL-home/issues/358#issuecomment-3155012748) > It’s not geo restricted (to my knowledge), but I think it might take 24h to propagate everywhere: > > “Please note that it can take up to 24 hours for apps to become available on the App Store after release” --- ## Post 44 by @AnotherBloodyUsername — 2025-08-06T08:06:40Z Surely it would be about giving users some form of choice. Adguard does work fine and also does have a mobile app for android which blocks adverts in all apps not just web browser. --- ## Post 45 by @anon39279085 — 2025-08-06T09:32:48Z Yup gotcha it propagated :+1:, Also partly my fault since I was using a VPN ![IMG_0017](https://forum-uploads.privacyguidesusercontent.com/original/2X/b/b54ae6bebacff191b9daefa255e9a02dc9d2c41c.jpeg) --- ## Post 46 by @anon61753997 — 2025-08-06T13:59:13Z I object to removing AdGuard. The reason is that it doesn’t work with PWA apps. > [@Plum](#): > > One major difference between uBOL and AdGuard is that AdGuard is using the native content blockers function in Safari in addition to an extension, while uBOL is only an extension. > > This is major because extensions on iOS do not run in PWAs or web previews but content blockers do (on MacOS extensions do run in PWAs). > > So if only using uBOL on iOS, there are no content blocking capabilities in PWAs. This would go against the usual recommendation to use PWAs over native apps for privacy. I have tested uBlock on iOS 17.6, and this point is still true. --- ## Post 47 by @jonah — 2025-08-06T15:09:40Z How does uBlock Origin Lite work on Safari if not via the native content blocking framework? iOS is annoying because the Safari settings used to explicitly list which extensions were content blockers, which would make this easier to check, but now that is gone. --- ## Post 48 by @anonfox — 2025-08-06T15:24:51Z Gorhill is aware of the issue [https://github.com/uBlockOrigin/uBOL-home/issues/358#issuecomment-3159712627](https://github.com/uBlockOrigin/uBOL-home/issues/358#issuecomment-3159712627) Hopefully there’ll be a solution soon --- ## Post 49 by @anon61753997 — 2025-08-06T16:34:51Z > [@jonah](#): > > How does uBlock Origin Lite work on Safari if not via the native content blocking framework? uBOL reads and alters webpages’s content _directly_, not through Safari. Meanwhile, Adguard uses a hybrid approach. It provides basic rules for Safari’s content blocker _in addition to_ reads and alters content directly. This is because [the rules that Safari’s content blocker supports](https://developer.apple.com/documentation/safariservices/creating-a-content-blocker) are very basic. > Content blockers are app extensions that you build using Xcode. They indicate to Safari a set of rules to use to block content in the browser window. Blocking behaviors include _hiding elements, blocking loads, and stripping cookies from Safari requests_. > [@jonah](#): > > iOS is annoying because the Safari settings used to explicitly list which extensions were content blockers, which would make this easier to check, but now that is gone. With extensions like Adguard, this distinction is gone. > [@anonfox](#): > > Hopefully there’ll be a solution soon They can wait for web apps on iOS/iPadOS to support extensions. :face_with_tongue: Web apps on macOS only support extension from last year, so it may take several years. --- ## Post 50 by @anon94117004 — 2025-08-06T16:45:55Z Another objection regarding permissions: - AdGuard: “AdGuard does not have permission to read or transmit content from any webpages”. - uBOL: “Webpage Content and Browsing History: Can read and alter sensitive information on webpages, including passwords, phone numbers, and credit cards, and see your browsing history on the current tab’s webpage when you use the extension.” > [@anonfox](#): > > Hopefully there’ll be a solution soon They then closed that issue. --- ## Post 51 by @jonah — 2025-08-06T16:54:50Z > [@anon61753997](#): > > uBOL reads and alters webpages’s content _directly_, not through Safari. > > Meanwhile, Adguard uses a hybrid approach. I know AdGuard uses a hybrid approach, but I thought it was the other way around with uBOL, where they _only_ use Safari’s system and don’t modify websites. Don’t all MV3 extensions have to use declarative statements? --- ## Post 52 by @jonah — 2025-08-06T16:56:02Z > [@anon94117004](#): > > uBOL: “Webpage Content and Browsing History: Can read and alter sensitive information on webpages, including passwords, phone numbers, and credit cards, and see your browsing history on the current tab’s webpage when you use the extension.” This _should_ be optional, like it is on desktop. Can someone test setting this permission to Deny and seeing if it still works? --- ## Post 53 by @anon94117004 — 2025-08-06T16:56:30Z > [@jonah](#): > > This _should_ be optional It is not optional, I just tested on iOS 18.6. I think this stems from it again not being a true Apple “content blocker”. --- ## Post 54 by @anonfox — 2025-08-06T16:57:12Z It still works, and this is the default iirc. You need to grant it permission for Optimal or Complete filtering though --- ## Post 55 by @HackOrSwim — 2025-08-06T17:10:31Z Additionally, from my testing, if you don’t grant it that permission and try to change to Optimal or Complete, as soon as you close and reopen the settings tab for uBlock, it should be back at Basic. It apparently lacks the ability to ask for permission, at least on iOS. You have to grant it in the Safari settings manually to use any of these modes. --- ## Post 56 by @Redroyach — 2025-08-06T22:32:41Z I don’t think Adguard should be removed, it also provides content blocking on other apps and ublock doesn’t, that’s useful if you use any banking apps and therefore can’t use a VPN, iOS doesn’t support split tunneling on vpns. --- ## Post 57 by @anon94117004 — 2025-08-07T00:55:45Z > [@Redroyach](#): > > use any banking apps and therefore can’t use a VPN Why do you believe these are incompatible? --- ## Post 58 by @xray.telescope — 2025-08-07T01:41:51Z Installed uBOL on all my Apple devices yesterday. Very happy so far. I’ve noticed adjusting the settings between basic, optimal, and complete sometimes doesn’t stick even with full permissions to access every website. Not really sure of the difference between optimal and complete though. No one should be surprised that an extension that modifies the webpage you are viewing can see and alter sensitive information on the webpage. Safari is simply warning you of what is going on. Other Safari extensions that do this include Wiper and StopTheMadness. AdGuard only provides content blocking in other apps if you let it be your DNS too. That’s a function that NextDNS, ControlD or other serivces already may do for you. And uBOL appears to be much lighter than Ad Guard (at least on macOS) which has to have the full app running all the time. --- ## Post 59 by @TigerBanded — 2025-08-07T02:45:48Z Can confirm, uBOL is so much lighter than running the Adguard extension in Safari on my iPhone and Mac. That alone makes it an easy choice for me. --- ## Post 60 by @anon55464882 — 2025-08-07T06:41:29Z I think we should wait a bit longer before recommending uBOL for Safari. For other services, we usually wait months or even years before making a recommendation. Now, we’re considering adding uBOL after just a few days, even though we’re still unsure about potential downsides or development issues that could arise. Yes, the developer is reputable and trusted, but it’s still new on Safari. A little patience won’t hurt. --- ## Post 61 by @anon32162901 — 2025-08-07T13:59:03Z I figured any half-decent Safari content blocker would be using this hybrid — content blocker API + web extensions API — approach. I currently use Wipr 2 which does that. If I go to Settings \> Apps \> Safari \> Extensions I see a multiple entries/toggles related to Wipr and only one of them, the Wipr Extra entry, has that warning about being able to view and modify webpage contents. I assume that Wipr Extra entry is leveraging the web extensions API to provide more advanced blocking. I’m no developer, but always assumed the content blocker API simply provided “hosts file” capabilities, while the web extensions API handled javascript related stuff (cosmetic filtering). Does uBO Lite only rely on the web extensions API for all its blocking? --- ## Post 62 by @anon61753997 — 2025-08-07T16:22:01Z > [@anon32162901](#): > > Does uBO Lite only rely on the web extensions API for all its blocking? Yes, and [it will remain like that in the near future](https://github.com/uBlockOrigin/uBOL-home/discussions/408#discussioncomment-14019691). > uBOL will stay a webextensions-based browser extension, I do not plan to go further than this, I do not have the time and motivation to take on more work than I already do. --- ## Post 63 by @anonfox — 2025-08-07T17:36:16Z That’s problematic imo. It means it won’t work in web apps or in-app Safari websites unless apple makes them support extensions --- ## Post 64 by @xray.telescope — 2025-08-08T00:47:58Z Are you currently using a DNS solution like NextDNS or AdGuard Pro with it’s DNS? I’m not aware of any other way to impact what happens in apps. (I personally use NextDNS) Am I missing something? --- ## Post 65 by @anonfox — 2025-08-08T00:53:44Z No, I’m not using these. I’m talking about [this](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller) ([pics](https://user-images.githubusercontent.com/68077359/228607206-2ef75d06-dc5b-4d41-829f-9bdac865531a.png)). It supports content blocking with AdGuard, but not uBOL. It’s unfortunate because I use it a lot to read news articles, so this is a dealbreaker for me personally. --- ## Post 66 by @xray.telescope — 2025-08-08T01:09:30Z Ah, ok, thanks. I hate “in-app” browsers for this kind of thing. I didn’t know Ad Guard could handle them. Generally of less of a problem on macOS where running Adguard more effort and apps usually don’t (uh, Perplexity…!) Maybe I’ll split mobile (adguard) and mac (uBOL). --- ## Post 67 by @Redroyach — 2025-08-09T14:08:08Z Because I tried a few days ago, I can’t login to my bank app when using Mullvad or IVPN, I tried as many exits as I could. --- ## Post 68 by @anon85180982 — 2025-08-13T23:08:50Z Does the uBlock Origin Lite extension for Safari work after restarting the iPhone? Because in my case, when I launch Safari for the first time, I have to close it from multitasking and reopen it for it to work. I also reported the issue on GitHub, but the developer doesn’t seem to have any problems. [uBOL does not work when restarting the iPhone · Issue #428 · uBlockOrigin/uBOL-home · GitHub](https://github.com/uBlockOrigin/uBOL-home/issues/428) --- ## Post 69 by @jonah — 2025-08-14T00:01:09Z > [@TigerBanded](#): > > uBOL is so much lighter than running the Adguard extension How are you measuring that? --- ## Post 70 by @xray.telescope — 2025-08-14T01:22:06Z I have experienced bugs too, but not what you’re describing. My problems have been oddly inconsistent. Changes to the filtering mode sometimes didn’t stick for one. Another was interference with NextDNS status on their dashboard. Both seem to have disappeared. I started a report on GitHub only to find the problem resolved when I tried to document it… I just restarted my iPhone and can’t duplicate your report, and I mainly use private mode in Safari. After restart I had to reload the first page twice before it displayed. But uBOL was operating and [canyoublockit.com](http://canyoublockit.com) loaded as expected. I do notice that I sometime need to reload pages to get them to display; seems like more than using AdGuard Pro, but not conclusive. Hmmm. When i load the uBOL Test Page the second block under “Advanced network filters (DNR)” is red tho it should be filtered. It’s seems a work in progress, but I’m mostly happy. This comment seems unexpected though! > I don’t have access to an iPhone, but I do have access to an iPad, but I will need help with the steps since I do not have that much experience with it. --- ## Post 71 by @TigerBanded — 2025-08-14T01:36:20Z I used AdGuard in Safari for years, and the first time I installed uBOL and turned off the AdGuard filters, I was shocked at how much faster things loaded in Safari. So not a true, verifiable measurement. Just an observation. --- ## Post 72 by @anon85180982 — 2025-08-14T08:46:34Z Here is my test after restarting the iPhone with uBlock not starting up [IMG\_5539.jpeg and 4 other files | Files.fm.](https://files.fm/u/qrzb54f2uy) --- ## Post 73 by @eqrlzo8t — 2025-08-16T08:35:12Z By default, Safari sets all extensions’ permission to “Deny“ (a.k.a “Basic” mode in uBOL). At this mode, extensions can’t access websites’ contents. Extensions (uBOL) can’t force themselves to higher permissions either. Users have to set it manually. --- ## Post 74 by @anon85180982 — 2025-08-17T08:54:17Z So I should do this every time I reboot the iPhone? --- ## Post 75 by @TigerBanded — 2025-08-19T17:21:12Z UBoL has been updated twice for Safari already, so looks to be actively maintained and receiving regular updates. Source: [Releases · uBlockOrigin/uBOL-home · GitHub](https://github.com/uBlockOrigin/uBOL-home/releases) --- ## Post 76 by @anon55464882 — 2025-08-20T07:56:49Z It’s not an indicator because the app is only available for about two weeks. --- ## Post 77 by @Banter8905 — 2025-08-26T17:13:16Z Can anyone advise why the number counter over the extension takes a while to reflect the number of trackers blocked? I have noticed this behaviour upon installing updates to the application. --- ## Post 78 by @Weewaawoo — 2025-08-27T15:50:32Z I was under the assumption the number is updated when further requests are blocked --- ## Post 79 by @Banter8905 — 2025-08-27T22:39:40Z I thought so to. But on sites where requests are blocked it takes a while to reflect after an update. --- ## Post 80 by @IksNorTen — 2025-08-28T04:49:18Z Why replacing? Why instead not recommend it in addition to AdGuard? As far as I know, AdGuard is a very good software (and imo equivalent to uBlock Origin regarding ad-blocking, at the exception of YT ads but the AdGuard app can now blocks YT ads too). --- ## Post 81 by @CarefulMouse — 2025-08-28T08:43:27Z uBlock origin in Safari works fine for me in blocking youtube ads. --- ## Post 82 by @IksNorTen — 2025-08-28T08:55:47Z Yes but it doesn’t mean we can’t have another recommended alternative if for some reason uBlock Origin Lite doesn’t work properly for someone or if someone’s just doesn’t want to use it --- ## Post 83 by @fria — 2025-08-28T08:57:52Z > [@IksNorTen](#): > > Why replacing? Why instead not recommend it in addition to AdGuard? Originally, AdGuard was only listed because UBlock Origin wasn’t available on Safari, but it seems like people really like AdGuard so for now we can just add the Safari version of UBOL and keep AdGuard. --- ## Post 84 by @overdrawn98901 — 2025-08-31T18:34:56Z Anecdotal evidence, but I found UBOL plays much nicer with my WireGuard road warrior setup. I randomly faced connections issues and it seems to have stopped when I switched to UBOL. Unsure if it actually fixed me issue or not. --- ## Post 85 by @Footnote5444 — 2025-09-09T16:36:17Z Non-scientific report; but after playing around with the latest uBlock Origin Lite on Safari 18.6, it appears that Apple’s implementation of web extension (what uBOL uses) remains flawed. I monitored by DNS traffic while switching from AdGuard to uBOL and giving it all permissions needed under “Complete” and noticed that sometimes when using Safari after the phone had been idle, domains that should be blocked were not being blocked. Other times it worked perfectly, so either there are bugs in Apples implementation OR bugs in uBOL still, but either way I think AdGuard remains the best option on iOS and macOS. For now. AdGuard isn’t perfect- AdGuard for Safari is an electron app that uses a lot of system resources compared to Wipr for example, but it also doesn’t just fail to block clear tracking and ad domains when waking the device up from being idle. Whatever the issue is, hopefully future updates fix it, but in my experience either due to WebKit issues or uBOL issues, the app isn’t quite as stable as hoped. --- ## Post 86 by @Footnote5444 — 2026-01-02T21:45:15Z Just wanted to bump this as I believe uBlock Origin Lite has reached a level of stability that it should be added as an option alongside AdGuard for Safari. Since my last comment, Gorhill has implemented fixes so the start-up issues noted above have been resolved. It seems the primary issue is that due to Safari restrictions, WebExtensions like uBOL do not work on web apps or in-app webpages. Other than that, I have noticed that uBOL “feels” less resource heavy than AdGuard. But this is not based on any exact benchmarks. uBlock Origin Lite has an advantage over AdGuard in being “set and forget” while also offering support for uBlock specific filters by default alongside the usual Easylist options. While I believe that the AdGuard recommendation is fine to remain, uBOL has reached a level of stability on Safari that it should be added as a secondary option for iOS and Mac users. --- ## Post 87 by @ramusica — 2026-03-25T12:06:29Z Agreed. There’s no need to remove AdGuard and if people want to use uBlock Origin Lite for Safari instead they can do so. --- ## Post 88 by @0x44 — 2026-09-07T09:34:26Z What I’m curious about is, who the developers behind AdGuard actually are. Everyone knows the uBlock Origin developer, since he doesn’t hide his identity. He is “accountable” for the code he releases. With AdGuard though, the developers are mostly anonymous. Who are they? Nobody really knows. For software that intercepts / filters all your browsing traffic, that lack of public accountability is worth considering. --- ## Post 89 by @shadowwwind — 2026-09-07T12:39:00Z Adguard is a company registered in Cyphers [Contact Us | AdGuard](https://adguard.com/en/contacts.html) Some of their employees are public on their linkedIn [AdGuard | LinkedIn](https://linkedin.com/company/adguard) I don’t know about gorhill, but adguard is often attending both advertising and adblocking events/meetups. There are multiple public appearances by their employees. [https://www.youtube.com/watch?v=y6qIN60Naig](https://www.youtube.com/watch?v=y6qIN60Naig) They are literally doing the opposite of hiding --- ## Post 90 by @Footnote5444 — 2026-09-07T16:46:38Z This is FUD. AdGuard for iOS is publicly available to audit on GitHub. Same as uBO/uBOL. Your argument is baseless in that many of the same people contributing to uBO/uBOL do not make themselves publicly know either. One should never blindly trust any software they use, but AdGuard has been doing this - with few incidents - for a long time now. I see no reason to treat them as a threat or bad-faith actor. --- ## Post 91 by @0x44 — 2026-09-07T16:48:35Z Thank you for your reply @shadowwwind , that’s good info. Personally, i’m still not comfortable using products from a registered company in Cyprus (originally founded in Moscow, so development staff probably primarily in Russia.) In the end, you’re trusting the organization, not an individual whose work you can follow commit by commit. Note that many of AdGuard’s products are closed source. [They state this in their Github repo](https://github.com/AdguardTeam/AdguardForAndroid#disclaimer), only the bug trackers are hosted on Github, no source code is published (Adguard for Android, Windows and Mac. And also all the VPN apps.) But that’s just my preference, not a verdict on AdGuard. Curious though what others here think… --- ## Post 92 by @Footnote5444 — 2026-09-07T17:05:00Z If you want to twist this, you could make a similar argument about Gorhill, no? Gorhill posts publicly as Raymond Hill, but has never done interviews, or made details about themselves known. For all we know Gorhill could be a developer from Canada or one located in Cyprus. Also - this thread is about AdGuards Safari content blocker which is included in their open source projects. The only closed source projects AdGuard has are ones that require payment to use. Their explanation behind this has always made sense to me. If it is free, AdGuard makes the source code available. If it is paid, it’s closed source with the idea being you are paying which should alleviate some concerns about anything nefarious taking place. I would prefer all their apps being open source, but I do understand their hesitation to do so since they do need to pay the bills.