Here is another perspective from a non-developer user on those reasons and the resulting tradeoff (of allowing DDG to trivially track which result links are fol

Here is another perspective from a non-developer user on those reasons and the resulting tradeoff (of allowing DDG to trivially track which result links are followed): 1. Privacy conscious users can control whether a Referer header is sent and if so, the content of that header. They might choose to use a browser that does not make it easy to control the Referer header. But DDG does not account for those privacy conscious users who may be using browsers that do allow this control. (Bias discosure: I use one and not for privacy reasons.) The DDG decision seems to encourage users to choose browsers that have privacy-unfriendly default settings or that do not make it easy or even possible to control what if any Referer is sent. At the very least, it tries to resolve an issue that is a clearly client-side one and is best resolved there. 2. Correct me if I am wrong but storing "settings" with DDG requires a cookie and/or Javascript to be enabled. If this is true, then again this is not an improvement in privacy. Privacy users may prefer to keep these browser "features" disabled wherever possible. Users can of course control whether they send GET or POST by using a client such as curl or the like, or sending requests from a local copy of a DDG html search page with the method changed from GET to POST. One might wonder why DDG cannot provide an alternative search page with its form method set to POST. Users can then choose which search page they prefer. No cookie needed. Instead it sets the default method on its search pages to GET (perhaps leaking the query in the URL). How many users will bother to change the default? A minority of them, no doubt. There is an opportunity to let users turn off cookies and Javascript and let them perform searches using POST, the method usuaully advocated by those advancing internet privacy. I cannot see that it would cost DDG anything substantial to provide it, except not promoting GET as a method by default, not requiring users who want to change defaults to enable cookies or javascript to "keep state" and reliquinshing the ability to easily track which result links users follow. To reiterate, control over the Referer header is easily done by the http client. Clients that do not allow easy user control over this are not improving internet privacy. In my experience sending Referer headers is almost never necessary. It is very rare that I find a site that requires a Referer header, let alone a specific one. Sending gratuitous information seems like a clear departure from the internet privacy playbook. Then again, I am not a privacy expert and perhaps the experts have decided there must be a carve-out for the Referer header and users should err on the side of sending too much information rather than too little. The only reason I am aware of this stuff is because I use the web heavily without javascript or cookies and I take an active role in what headers I send. I generally do not do this for privacy, but for speed and control. I can strip out the prefix client-side if I must use GET.