4 ms·

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

by tagawa 6y ago

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.

systemvoltage 6y ago
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. There are so many options.
haggy 6y ago
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.
oska 6y ago
Please don't downvote this reply from a DDG staff member (as I'm currently seeing). Even if you don't like the reply it's good that we're getting replies.
- oefrha 6y ago
  You can read essentially the same reply as the first comment on the linked issue, so not much value is lost even if gp is downvoted into oblivion.
- jeltz 6y ago
  But we are not. It is just the same reply parroted in multiple places without responding to the actual criticisms.
aronpye 6y ago
Good privacy is not based on trust. Even so, this incident is even less reason to trust you.
jb775 6y ago
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.
SahAssar 6y ago
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?

by tagawa 6y ago

systemvoltage 6y ago

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. There are so many options.

haggy 6y ago

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.

oska 6y ago

Please don't downvote this reply from a DDG staff member (as I'm currently seeing). Even if you don't like the reply it's good that we're getting replies.

oefrha 6y ago
You can read essentially the same reply as the first comment on the linked issue, so not much value is lost even if gp is downvoted into oblivion.
jeltz 6y ago
But we are not. It is just the same reply parroted in multiple places without responding to the actual criticisms.

aronpye 6y ago

Good privacy is not based on trust. Even so, this incident is even less reason to trust you.

jb775 6y ago

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.

SahAssar 6y ago

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?