BW already has all the URLs of services you use: you saved them yourself for them to keep safe. It's obvious you already trust them enough to know that sort of data.
So if favicons were gathered locally, then you would prefer that your own browser would reach out and make multiple requests to every (potentially dodgy) site listed on the search result page?
Note also that these are favicons for results that DDG has already given you. This isn't tracking your clicks. The list of sites that appear on the search result page is not new information to the search engine that just gave them to you.
EDIT: Like other commenters, I was not previously aware that DDG had a browser, and my comments were about this behaviour for the search engine results page.
Can you explain your edit a little more? I still only understand your original viewpoint. Just because there's an app doesn't mean they don't have to contact DDG servers at all, right?
We had already had created this anonymous favicon service for our private search engine. In addition, doing it this way avoids another request (and potentially multiple) to the end site.
The service is private as we do not collect any personal information (e.g. IP addresses) on any requests for this or any service and the requests are all end-to-end encrypted.
Why not do it locally? It is one extra request to the favicon link in the header and cache it. Or cache it when the user visits the website. Or explicit button in the settings UI to refresh favicons locally.
Your answer to all these criticisms is a lazy one. You are saying "this already exists for other things so we use it regardless of what the correct method is". Just because something exists in one form doesn't mean it's the correct choice.
I personally believe you, but this approach adds multiple unnecessary trust boundaries. Just thinking about how many separate logs are triggered outside of DDG is troublesome. And what happens when you guys think everything is secure, but one day find out it isn't?
I understand utilizing a single service/feature to accommodate multiple platforms is a big win from a programming standpoint. But if it carries the risk of losing the trust of your user-base while at the same time risks breaking the core mission statement of the business (privacy), it's probably not worth it.
What do you mean by "end-to-end encrypted"? Isn't this just a request to your service that will then go out and fetch the icon from the site, so it can't be e2e since you need to know which site to request the icon from.
Why use that term when it clearly can't be true or even seems applicable/relevant?
reply