Hacker News new | past | comments | ask | show | jobs | submit login

In the settings, http://duckduckgo.com/settings.html, you can turn on POST requests as well as disable favicons and 0-click. Switching to POST alone should fix this issue for you. In particular the Referer heading then becomes:

Referer: https://duckduckgo.com/




how about you set up a separate domain (e.g., supersecretduck.com) where all the options you mention above default to their paranoid settings?


Or make it automatic or at least default for https? If you're using https, the only thing you have to hide is your search term, right? And that's what's being exposed to Amazon, or whoever else is seeing your URL along the way.


If you're using HTTPS, the Referer is blocked by your browser.


If that separate domain can be used in the Chrome URL bar, count me in. Thought it would be even better if it could be done using the main URL in the Chrome URL bar somehow...


If the domain exists it can be used in the Chrome URL bar. Any search engine that puts its queries in the URL can be added manually to Chrome.


The whole point of using POST is to remove the queries from the URL, though.


In Opera, when setting up search engines [which can be used directly in the address bar], you have the option of using POST instead of GET.


Why use chrome if you seek privacy?


Why not? Could you please elaborate.


Better make that the default then for secure searches!


Some people, perhaps most, don't like POST because it is annoying to copy URLs and use the back button. I'm not opposed to making it the default for https, but I don't want to make a default that most people don't want either.


That's a good point. Maye you could put a small warning on the page if they disable 'POST' that there might be leakage of their search terms to the sites they visit?

"Hello dear user, you probably know exactly what you're doing, but on the off-chance that you don't, please realize that disabling the POST option for https connections may leak your search terms to the visiting site".

Or something to that effect.


The problem is not that the referer leaks to the sites you click through to. The referer leaks to sites as soon as the results page is displayed because there are externally hosted images embedded in the results page.


But a post would take care of that right ?

After all, then the referring url would just be the search page without any parameters.

So if you switch off the post then leakage would occur, with the 'post' enabled you're fine.

edit: I see what you mean now, if they switch to 'get' mode it leaks the info even to sites they don't visit. One more good reason to use that post!


But what's the point of an https search if it's not really secure? The only thing the user is trying to hide is the query, and it's not being entirely hidden.

For users who are annoyed, you could explain to them somewhere on the site that you don't put it in the URL because it exposes their query. If they really want a secure search, I imagine they'll understand the tradeoff.


Does the POST switch works when you are using DDG via the Google Chrome URL bar? (I have it set at "https://duckduckgo.com/?q=%s)


I search using ixquick.com because of their good privacy measures and they searh using post.

They have a button on their website that adds it to you list of search engines in chrome (chromium in my case), so it definitely can be done.

EDIT: it turns out that ixquick switches to a different URL and uses get instead of post for this, so forget what I said.

PS: the opera urlbar inline search has post support.


Doesn't seem to, no. The page I land on is still http://duckduckgo.com/?q=hacker+news.


Encrypting the url parameters is the way to go:

Requests for:

http://duckduckgo.com/?q=hacker+news

Should HTTP redirect to something like:

http://duckduckgo.com/?enc=34g7h3giuh3g

Where 34g7h3giuh3g would be the ciphertext generated by encrypting "hacker news". That page knows what the search term was because it will have decrypted the parameters on the server side, but any referers would just contain "garbage", and it would also mean people can copy/paste the address bar about.


all the other person has to do then is perform a search to see the secret terms. granted, it's better than it showing up in plain text in the referrer, but you could easily write a script to scrape the actual terms...


What if you use the IP address of the user as a seed for the encryption? Then if someone else used the same key from a different IP they'd get different search terms?


That embeds the IP in the process and could theoretically be reverse-engineered.


Are there session ids? I assume that HMAC(secret + sessionID + ip + search terms) would be fine.


No sessions.


I see you do settings through a cookie or URL params. I'm out of ideas unless you hash the cookie + ip for a session ID fir that purpose.


Yes, you're right. I didn't think of that.


Moving such stuff to "settings" is hardly a good solution for wanting to stay anonymous. After all, it probably means you'll have to be logged in.


There are no accounts and these settings can be set without cookies as well.


Furthermore, the setting cookies are simple transparent cookies (f=-1 to turn off favicons), they are not tracking cookies. They are only used when you set the preference and then only contain your preference itself.


How do you do it without cookies? Changing the settings for each search?


You hardwire a specific URL query string into your browser search bar. Here are the params: http://duckduckgo.com/params.html




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: