Yes, but then it is duckduckgo.com doing the query. Here they're passing on the query in the referrer string and the users original browser makes the non-secure request to amazon.

That sort of gives it all away.

So if duckduckgo would just send back the answers to the query and not use a page that requests resources from third parties they'd be fine.

They aren't passing on the query in the referrer string. Your browser is. This story is a non-story. Referrer is just doing what Referrer does.

It's a fine story, and it is fixable. And it probably should be fixed, if only because fixing it is less work than talking about it. And due to a terrible oversight the header is actually mis-spelled and it came out as 'Referer:'.

Fixing this will make duckduckgo.com even better, which is awesome.

> And due to a terrible oversight the header is actually mis-spelled and it came out as 'Referer

Well, Cant blame DDG for it though

http://en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_ter...

No, definitely not, I just wanted to point that out.

I knew about this for years, having stared at a bug for a whole day before I realized it was the header that was misspelled. It never even crossed my mind until I was away from the keyboard for a few hours.

Except if the same user clicked through to a result, the server of the result page would receive the same referrer header w/ the DuckDuckGo query in it.

Not if he makes the 'POST' option the default for secure searches.

If you don't store the search term in the URL, then it doesn't get passed along in the referer. Store an encrypted version of the search term in the URL instead.

> Yes, but then it is duckduckgo.com doing the query.

Oh, yes, good catch.