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.

> In addition, doing it this way avoids another request (and potentially multiple) to the end site.

Potentially saving a few requests here and there is certainly not worth phoning home with that kind of data regardless of what records you keep how much you do to anonymize it. This is especially true for a company that has built its brand on promises of privacy!

Besides, favicon requests are small potatoes compared to the kind of tracking, ads, metrics, and other often-unnecessary page resources that bog down most of the modern web. And a well-designed website can mitigate the issue pretty easily.

It seems like DDG just doesn't want to do more work to make the browser do the sensible thing and instead piggy back on their existing favicon service, and then going to make the argument that it is safe with us. The domain of browser is totally different from reaching out to the website and rendering favicons server side. Do you not see this as a problem? I think it is acceptable to say "We agree this is a problem, and we are gonna look into fixing this" instead of pushing back on an obvious problem.

Surely you could fetch the favicon asynchronously and update the address bar or tabs or wherever you display it only after the other assets are loaded? It’s not like the DOM has elements that depend on it. This is a really, really weird hill to die on.

And all you lose in the process is hard-earned trust from people like me, who switched to DDG years ago for privacy concerns.

This is troubling.

I understand we’re suppose to take your word but it’s making me skeptical now about the actual intentions. If DDG truly cared about user privacy then you shouldn’t transmit user information for something as trivial as favicons.

Is this service open-source and publicly auditable ? Because we've learned not to trust one's word of "don't be evil", only facts matter.

If you say the service is anonymous and does not leak data, prove it.

I'm sorry, but this is bullshit. If the received HTML contains a <link rel="shortcut icon" ...> element, you already only need one request, so this is not an improvement. If that is present, you should NEVER use your API.

If it's not present, then you have options, and yes, using your weird API is an option (which I still don't like, but ok). But sending private information to your servers even when sites follow the standard show either that you're probably not trustworthy, or that your product team is so painfully incompetent that I'd be afraid to use their browser at all.

I think people here are more interested to know if you’re going to fix it.

> The service is private as we do not collect any personal information

This sentence is 100% meaningless. I understand you have good intentions, but these things must rely on proof, never on trust. Either you get this information or you don't; whether you say you "collect" it is inconsequential.

You may not collect it, but your upstream could collect it, and encryption has a shelf life.

It's a really bad look and you should ditch it.

> We had already had created this anonymous favicon service for our private search engine.

Which presumably means you've already created the logic for determining favicons. I'm not sure why this couldn't be implemented in the browser.

> We had already had created this anonymous favicon service for our private search engine.

I don't think here's a need for adjectives here. Why stress that it's anonymous (when that's hard to verify) or that the search engine is private, when that too is starting to come into question? Repeating these things won't will them into the reader's perception.

> In addition, doing it this way avoids another request (and potentially multiple) to the end site.

This isn't true, unless I'm missing something here? When I access a website, the HTML response I get from that website includes all the information my browser needs to, on its own, get and display the favicon. Can you clarify why you think/say this avoids one or more requests? What mechanism is this service a substitute for?

Saving a request is not a good reason to phone home, especially given what the DDG brand is built on and the main reason I would use it over Google. Please reconsider.

It's alright, folks. We got E2EE and a pinky-swear.

Please ask your higher-ups to educate you about essentials of privacy in the modern age. It's not about what you may be doing wrong, it's about what you technically could do wrong.