nanoscrew
Thanks for following up on this. I think the permissions issue is a valid concern because declarativeNetRequest could be used to add tracking, but overall it's actually much more private and trustworthy because third parties like Kagi can't actually observe web navigation directly. Some info in an FAQ or blog post could help clarify this to users, along with the source code being open. Another benefit is that it doesn't depend on redirecting from a javascript process. There's some interesting info here about how Safari handles DNR rules internally.
My private extension handles search engine bangs by using regex rules. For example, the DNR regexFilter for duckduckgo.com I use is ^https:\/\/duckduckgo\\.com\/\\?q=[^!].*. I have created rulesets for handling search bangs, for example, wikipedia uses: ^https?:\/\/duckduckgo\\.com\/\\?q=!w\\+(.*)&
The long website permissions would be quite confronting to users. But perhaps the instructions to users could focus on enabling the plugin within the Safari tab open to their default search engine, so that they don't have to see the list and scroll to find their search engine.
Funnily enough I did some experimentation to see if DNR could modify autocomplete yesterday. I wasn't successful, but I did find that redirecting duckduckgo to http://kagi.com/api/autosuggest?q= avoids the need to use modifyHeaders to add the cookie, and ends up redirecting to http://kagi.com/search?q=. As far as I understand it, the DNR redirect won't include cookies in the headers. Since Kagi does a redirect when the token is included, the modifyHeaders rule gets executed to add the cookie and allows the search to go through. In any case, I believe fixes for this issue can be handled server side by Kagi. It would be much nicer for the Kagi extension to inject the session token as a cookie than as a URL parameter.
I have sent feedback months ago to Apple about adding Kagi as a search engine. I can try pinging Jen Simmons on Mastodon to see if custom search engines could gain any traction.
