The new Safari extension 2.0 does not work

CrunchyFritos

Vlad I for one appreciate these changes to the extension, especially the narrower permissions required for it to operate. That’s a meaningful improvement in my book, and it speaks to the care the Kagi team takes to address even potential privacy and security concerns. Kudos 👏👏👏

Talran

I also had issues with address bar search not redirecting on iPad after force killing/having Safari tombstoned for memory. Apologies if this is addressed elsewhere. I’m running around a lot today and haven’t totally caught up but I wanted to post in case it can be at all useful.

Since I did the following, I’ve had no issues.

Follow step 6 in the Kagi extension app. But more specifically:

While it was misbehaving, manually go to Kagi.com.
Make a search.
Click the puzzle piece extension icon.
Pick to allow the site.
Got a popup to allow while using or always. Picked always.
Then I got a follow up popup that asked me if that should be for all domains or just Kagi. I picked all domains. (Even though I had picked All Websites - Allow, in the extension settings at an earlier step)

This was on iPad Pro 2022, latest iOS, where I had the most issues.

I also removed and reinstalled the new app once to make sure I didn’t have any settings buried somewhere that I left in a bad state without realising. So I don’t know if you can maybe set something that might interfere with the flow I saw above.

Dustin

I can confirm that after roughly an hour of the phone being idle, the extension appears to be inert again. There seems to be something going on when the system or even perhaps Safari is "snoozed"?

I just did the same steps as @Talran to go to kagi.com, enable the extension for all websites and Kagi searches again work. I can make a dozen searches without any issue whatsoever.

andreagrandi

I tried to completely uninstall the extension. I reconfigured it from scratch.

When I did the first search it worked perfectly.

Then I kept using my iPad, I came back to Safari to do another search and this time it went to DuckDuckGo instead of Kagi 😓

kagi-user

Same problems here. Newest iOS on iPhone 15. Old extension worked 100% reliably.

When I click the kagi extension inside of safari it seems to work again for a short bit.

TheBOT

Is the solution to allow it on all websites?

user41

TheBOT

No, it is not. I tried.

awu

I am still having issues on 2.0.2. This time I cannot seem to fix it. I’ve killed Safari, disabled and re-enabled the extension, and it still doesn’t work. I just haven’t re-installed it. I understand that this was tested before release but in my opinion at this point there are enough users having issues to justify rolling it back while ironing out the issues. I am a full-time Safari user and would gladly volunteer to be a TestFlight tester.

nompan

Yes, please roll it back! 🙏 We need Kagi to work!

Xavez

I can confirm that uninstalling the old extension, and installing the new one from scratch, following all instructions to the letter, does not solve the problem. After a day or so on iOS 17.2.1, it’s back to using DDG.

The temporary solutions outlined above do work (resetting permissions). But so far, no good on 2.0.2.

metaeaux

adoptingdeclarativecontentblockinginsafariwebextensions.zip

1MB

Dear Kagi team,

I have attached Apple source code taken from Adopting Declarative Content Blocking in Safari Web Extensions and modified it to demonstrate how to redirect searches from duckduckgo.com to kagi.com using the declarativeNetRequest API.

The file contains a git repo, so you can see the differences from the source code that Apple provides. Using this approach to redirects, I have been able to observe:

100% success rate with redirecting from duckduckgo.com to kagi.com
No requests to duckduckgo.com are made, provided that "Search Engine Suggestions" is disabled in Safari settings so that there are no requests for auto complete.

Please note that to make this extension work, the user needs to set their session token in the code. Search for SESSION_TOKEN in the ruleset_1.json file.

You can test and observe that requests are redirected and not sent to the default search using Proxyman on iOS. I'd recommend setting up kagi.com and duckduckgo.com in the SSL proxy list so that you can see the full request/response body.

The Kagi extension for Safari does not work 100% and searches to the default search engine still go through, even when "Search Engine Suggestions" are disabled. To kagi users: If your goal is to avoid sending seaches to Google, then setting Google as your default and using the Kagi for Safari extension will still send all of your searches to Google. I consider this to be a large oversight from the Kagi team. Either they are unaware of it, or do not think it's important to tell Kagi users about this.

I'm sharing this example because I want to demonstrate that this kind of redirect that is both private and reliable is 100% possible. I've seen comments from the Kagi team that Apple restrictions make (1) and (2) impossible. Even within the Kagi extension it says:

Sorry that Apple made this so complicated. We even started building an entire WebKit browser called Orion to make it easier to use Kagi on Mac. We’d appreciate if you gave it a try.

These just sound like excuses, and it makes me lose confidence in the team.

If the team wants to roll out a quick fix, I'd suggest statically hardcoding all of the redirects in the declarative ruleset, and asking users to enable the extension to have permission on the domains they are using. For example, enable the extension to have permissions on duckduckgo.com and kagi.com. That's a more flexible setup for users than trying to match the kagi app settings to the safari settings.

nanoscrew

metaeaux

Thank you for the sample code. We've looked into declarativeNetRequest-based solutions in the past, but they weren't chosen because they did not reduce the level of permissions required. Reducing permissions to no more than "Browsing History" was a primary objective for the 2.0 extension. declarativeNetRequest, as far as I can tell, shows up as "Browsing History and Tracking Information", which is what the 1.x extensions requested as well. This is how Safari 17 displays the permissions for each scenario:

That said, at this point, we need to consider reliability issues. While 2.0 had significant issues with reliability, 1.x on both platforms suffered from reliability issues as well. Combining the codebases and reducing permissions was meant to increase reliability and decrease maintenance cost for the extension. But if the extension is unreliable, even temporarily, it's a major disruption to a paid service, so it's worth exploring this alternative API as a solution.

I'm working on a proof-of-concept using your sample code as a starting point, moving the majority of settings over to the toolbar popup, and allowing the session token to be dynamically updated in the extension instead of hardcoding into json ruleset. I'd like to share the code and a TestFlight build once it's ready, aiming for Friday 5-Jan. Some remaining issues include:

Allowing !g/!ddg/etc search engine bangs. If you allowed the extension access to (for example) google.com, !g <search query> will always return you right back to Kagi's <search query> results page.
User experience when viewing the extension permissions page. To make sure we only ask for permissions if you're viewing pages on Google/DuckDuckGo/etc, we need to provide every single country-specific/alias domain in the manifest.json under host_permissions. This is a list of 261 domains. Subdomains can use a wildcard, but TLDs cannot (e.g. "://.google.com.au/" needs to be listed as well as "://.google.com/". You are not allowed to do "://.google./"). This isn't a problem in day-to-day searching, but it could confuse users as to why there's a 261-domain list in Safari -> Settings -> Websites -> Kagi Search for Safari
The redirect seems to break in a weird way if the modifyHeaders action is not applied on kagi.com requests. If we redirect to kagi.com/search?q=<search query> without the modifyHeaders rule applied, we get redirected to the sign-in page, even if we're in normal browsing mode, and are logged into kagi.com. If we redirect to www.kagi.com/search?q=<search query>, Kagi does its own redirect stripping out the www and the session cookie is re-applied to the request automatically. This helps if people don't want private browsing enabled and therefore don't copy in their session link into the extension. I'm asking the Kagi web devs if this is something expected with secure cookies, or if it's a bug in Safari's implementation, but regardless, at least there's a workaround, even if a bit clunky.

So, in conclusion: the declarativeNetRequest API looks promising from a reliabilty perspective, but the permissions issue is concerning. Having Safari declare that Kagi's extension "can be used to track you" does not align with Kagi's philosophy of not tracking users. Having the code be open-source helps, but we've received feedback that the permissions text in Safari is a major factor in their decision to use Kagi or not, so we cannot take this lightly. We'd love to hear from the community about this. (And if anybody you know can convince the Safari team to allow custom search engines natively, we'd appreciate that very much 😸)

metaeaux

Users may want to try xSearch or Hyperweb to set their default search engine while they wait for the extension to be rolled back or fixed.

kedar

@metaeaux A bit harsh re: team, especially since one thing shouldn't define them, but valid and very constructive. The query leakage is concerning, and something I was wondering about, but didn't have the time to test. Thanks. I assume xSearch (which I use) and Hyberweb do not have this issue?

It's confusing to me that v2 shipped with these flaws and also shipped during a holiday week (at least in many parts of the world). v2 could have waited for later in January, in my opinion, and with extra time, met quality standards without dampening a holiday week for the team and creating a stir in the community. (This thread is the #3 most commented topic here already...)

I would offer a simple solution is to push v1 back (as it was less divisive than v2, even if imperfect) re-release v2 when it's ready, ideally using the approach metaeaux demoed.

metaeaux

@kedar I haven't tested Hyperweb using Proxyman, but I did see the occasional query leakage when using xSearch. I think xSearch tries to cancel the request, but I found sometimes it's not successful, for example, when I tried "Paste and search", I saw queries go through. Not sure if that's 100% reliable repro steps though. I shared the example above because I'm not aware of any apps that implement declarativeNetRequest and do redirection without leakage. I've used this approach in a private web extension I've maintained over the past year without issue.

I agree completely regarding the rollout. Shipping something like this prior to a holiday is something engineers joke about a lot, because it's known to be bad practice. I don't think getting this out the door prior to holidays holds any urgency. Since this is a subscription product, this rollout is equivalent to a service outage, and it has lasted for days now.

sigmasirrus

Btw, looks like xSearch requires permissions on all websites now (iOS 17).

nompan

I’m switching to xSearch for now. I’ll switch back to Kagi’s extension when it’s working again. If you set xSearch to “override Safari engine” and set the mode to “blacklist”, it works well. Redirects are fast and reliable. It’s a bit cumbersome to set up, but it does the job.

I hope the Kagi team can get their extension sorted out soon, as I’d prefer to use it over xSearch.

andreagrandi

The query leak has been an issue from the beginning and my understanding is that it's an iOS/Safari limitation, not a Kagi bug. That's why I made sure to set DuckDuckGo as my default search engine. I trust them, I was using them before and I don't mind if something gets leaked to them. I do mind if I leak to Google instead.

toni

andreagrandi Based on what @metaeaux demonstrated couple messages above seems it is not iOS/Safari limitation if implemented correctly (and search suggestions are disabled). I hope team takes this as priority after the basic functionality of the extension is fixed.

andreagrandi

toni I hope the provided example can be helpful to Kagi team, but let's try to adjust our expectations a little bit.

It's holidays season almost everywhere. Me and most of my colleagues for example won't back to work until Jan 8th and I'm expecting Kagi's team to be in the same situation, so let's give them time to fix this properly.

At least on MacOS everything seems to be working as usual (but I'm not sure if I updated the extension and I won't do it for now) and on iOS I can deal with DDG for a few more days.

podfrog

Hi all. Experiencing something I think may be similar - on iOS 17.2.1 with the lasted 2.0.2 version of the extension, Safari no longer automatically redirects to Kagi when searching in the address bar.

One thing that may possibly be a clue: I only updated to the new version of the extension after the previous version has stopped Redirecting. That got me hunting around to see what the problem might be, which is when I discovered there was even a new version to update to.

« Previous Page Next Page »