• Type:

DuckDuckGo browser seemingly sends domains a user visits to DDG servers

There’s about seven red herrings in this huge thread. A lot of people who suddenly use DDG when it’s convenient to complain about it. Right. @Tritonio was the only one whom I saw explain the actual vulnerability here (provided you have a positive bias of trust for DDG, which disclaimer, I do):

40.114.178.124 is the IP that icons.duckduckgo.com resolves to and WHOIS says that it’s managed by Microsoft. If this is Azure, which I would take a bet it is, then that means that for the last year or more, Microsoft could, technically tap into that server’s memory to see who requested which domain and when. So not only do you need to trust DDG, you also need to trust Microsoft that they didn’t do anything bad with the info. Does anyone still remember PRISM? This kind of passive access to user data is exactly what PRISM was about. Although I could be wrong and maybe the actual server is running in DDG’s premises and Microsoft is simply acting as a reverse proxy.

Ah, SIGINT. Spooky SIGINT.

This quote points at Microsoft Azure’s IP for example’s sake, but that doesn’t account for the countless ISPs your data travels through, even on a basic DNS level without vendor participation. A nefarious agency could MITM and use this as spyware for a correlation++ attack specifically targeting DDG users. That should terrify all of us because we love privacy, (right?) and when the right adversary arrives – “could” is usually a synonym for “will inevitably”.

I fully 100% believe it’s innocent, I even feel it makes perfect sense in the mind of a rushed developer. I am happy to see it fixed. Now, with that said, I’d like to propose a solution so the product marketing people can be happy too.

If you want to have this feature locally, make it secure and do the same thing – just bundle a massive SVG sprite sheet with the client (realistically, how big would it be?) and do some sort of table association to pull them up on demand if the hostname has a match. Otherwise, don’t make an outbound network request, just return and wait! If you wanted to change the way you do it (and follow more-or-less standard practice), you can rely on site-provided webContent data as others have mentioned.

Anyway, I’ll pass the mic off now. I think @nilnilnil and DDG exec team did a great job of fixing the issue. Up and onwards!

Read More

Previous Post

Space Jam’s 1996 website is still alive

Next Post

Substack (YC W18) Is Hiring to Build a Better Business Model for Writing

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top