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 😸)
