The research that comes from this particular UC Berkeley group is frankly terrible. One of the studies to see if rich people break the law was done by seeing if BMW drivers follow traffic laws less frequently than other cars. It completely ignores that many rich people don't get BMWs and that many are just middle class "car" people.
Their experiments are essentially an extension of their preconceived notions and the fact that their many flaws don't keep it from being published is a black mark on that entire field of "research".
Dead from a development perspective. I've had the same bug on the android client where voicemails play the first second or so and then stop, requiring me to click play again.
How do they become less representative? The sample groups are exactly representative when they are based on income. e.g. Polling millionaires about their feelings seems pretty representative of millionaires' feelings, even if there aren't that many.
The difference you seem to be missing is the actual instances of sexism, which you called out and everyone here is fine with; and, crusades against people like pg, who have never shown any sexism.
When you run dig @www.facebook.com news.ycombinator.com, it must query the default DNS for www.facebook.com; however, the ISP must return the real IP for www.facebook.com or the HTTPS establishment will fail because they cannot MiTM that connection.
So now dig has the actual IP for www.facebook.com, which it is now going to use for it's DNS query for news.ycombinator.com. The commenter observed this query is intercepted because it works (which it shouldn't).
I have the same habit and I've been trying to break it. Seeing the discourse ahead of time really tends to poison your initial impressions when you finally get around to reading it.
What aren't you getting? The query for Facebooks server may use the ISPs DNS server, but that's not the problem. It's when dig's request is actually sent to that resolved address that the ISP intercepted the request.
That's exactly what that dig '@' symbol does. Why are you contending the very basic functionality of dig? Instead of a glib remark devoid of any evidence, I will provide you a link so you can understand. Read the first line of the synopsis of the man page: http://linux.die.net/man/1/dig
The server after the @ symbol is the one the DNS query for 'Google.com' is sent to, which is the IP address of www.facebook.com. That is the packet that is being hijacked. Get it?
>you aren't really affected negatively by them doing it.
Even if you are fine with your ISP committing fraud, you are negatively effected by the complexity (points of failure) and latency this adds to the network.
"dig @www.facebook.com news.ycombinator.com" does not use the ISP's DNS servers at all. It sends a DNS query to Facebook for Google, which should normally fail. His ISP hijacks the request and provides a response. In this scenario, the advice in your comment is pointless because they will hijack requests whether they are directly to authoritative servers or if they are to recursive servers.
Why do you keep posting this? It's irrelevant because the idea isn't to hide what site you're visiting, it's to prevent the ISP from modifying the DNS responses. Signing DNS responses would be helpful if that was actually enforced anywhere.
DNSCrypt is a perfectly fine solution for this threat model.