RFC: Use external icon sources

I was just looking through the icons implementation, wondering why it was finding different images for some sites than previous tools (namely KeepassXC), and I had a thought: Use something else!

DuckDuckGo have a great icon finder API which can be used (this is how KeepassXC does it), which should be pretty simple to integrate with.

Alternatively, as mentioned in Set Icon Server URL Globally, perhaps just forwarding icon requests to the official icon resolver as well.

It’d be cool to be able to configure these, both the order and which “finders” were used.

I’m happy to contribute some of these changes, just want to know what people think.

The official icon resolver and the one in bitwarden_rs function exactly the same, though some ordering could be different. And bitwarden_rs also supports base64 encoded images which upstream at this point does not.

The problem with using any API service is that you expose your sites where you have credentials stored for which could be unwanted.

A workaround could be to use a reverse proxy and pass the request to /icon/domain.tld/icon.png to something else.

If there are icons not working, or totally wrong, I’m glad to try and fix that to benefit all users. For that of course we de need to know the site.

I’m not sure if we want an extra icon fetching api integration alongside the current one either, there was one in the beginning, using the official icon fetching from upstream bitwarden, before the built-in was there, and if I’m correct also a small time afterwards.

I can try to see if there are huge difference between the built-in and duckduckgo’s version maybe.

If it’s implemented in the server itself, then it wouldn’t be revealing any more than the current implementation does. For Bitwarden compatibility, it’d have to be this way. That would be the point in using a respectable provider, and making it opt-in.

It would, but having it integrated into the server would make it significantly easier to integrate with. Unfortunately duckduckgo’s API returns .ico, so it’d need conversion, which reverse proxies won’t do. Could proxy it out to the official one, though. But again, it’d be cool to have it built-in, and thus be nicely cached and with fallbacks.

The fact the duckduckgo one is used in a search engine means it’s probably going to be able to have pretty good coverage of any site. It’s unfortunate it’s not open-source, though.

It would reveal your sites to DuckDuckGo, the current implementation doesn’t, because it access the sites directly and extracts the icons it self using a normal browser user agent, probably the same way DuckDuckGo does.

Regarding the .png, Bitwarden(_rs) does use that as an extension, but it actually passes on the the original image doesn’t matter if it’s a .png, .ico, .svg, .jpg whatever.

Still i am curious on what icons are that different that you want to use Duckduckgo’s service.

Also, as a side note, we do try to keep as close as possible to the upstream bitwarden with most stuff, but if this would be a really added benefit, we could discuss this.

@theorangeone, i did some tests today and compared bitwarden_rs, bitwarden and DuckDuckGo icon’s. I’m not seeing that much of a difference, i even did sha sums on the provide icons returned, and most are even the same, just some small differences with a few sites, or DDG didn’t returned an icon at all.