| |||||||||||||
Stallman: Ubuntu Spyware: What to Do?Stallman: Ubuntu Spyware: What to Do?Posted Dec 8, 2012 6:34 UTC (Sat) by mathstuf (subscriber, #69389)In reply to: Stallman: Ubuntu Spyware: What to Do? by Lennie Parent article: Stallman: Ubuntu Spyware: What to Do?
Yeah, I set DuckDuckGo as my search provider in Chromium. DDG has a link to do that on their page. If you still want Google, at least change it to HTTPS.
Unfortunately, the Android Chrome only offers Google, Bing, and Yahoo! as search providers. I've set the browser icon on my launcher to instead just use DDG instead of using the stock New Tab page.
(Log in to post comments)
Stallman: Ubuntu Spyware: What to Do? Posted Dec 8, 2012 10:28 UTC (Sat) by Lennie (subscriber, #49641) [Link]
Yes, that is the other problem, by default it is also a security leak.
If I start typing:
It will look up over HTTP:
https slashdot.org
Slashdot Posted Dec 8, 2012 18:17 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
Of course when you hit enter:
* The fact that you're connecting to that specific site is revealed to anyone handling your DNS traffic, or your IP traffic, or to anyone doing transit.
* Slashdot redirects you to their non-SSL page anyway
But yes, in theory this particular auto-complete feature betrays things you might wish not to make public.
Slashdot Posted Dec 8, 2012 18:26 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
> The fact that you're connecting to that specific site is revealed to anyone handling your DNS traffic, or your IP traffic, or to anyone doing transit.
The DNS traffic can be minimized with a caching DNS server. The external request(s) then go out every so often, not every time you try to access the site. And if you have an array of computers using the caching server, things should be hard to correlate. Of course, a proxy can be inserted which does additional DNS requests for any site referenced on downloaded pages as well to help add some "plausible noise" into the streams.
> Slashdot redirects you to their non-SSL page anyway
That's…yet another reason to avoid slashdot? I kid, I kid. Only half. Maybe.
Slashdot Posted Dec 9, 2012 1:48 UTC (Sun) by paulj (subscriber, #341) [Link]
A local, caching, fully capable recursive resolver (e.g. an actual nameserver) should be a default install on all machines really. Better for privacy, better for DNS-Sec (who is ever going to configure a stub-resolver with TSIG, and DNS-Sec validating stub resolver has to do all the work of a fully functioning recursive server), better for avoiding poisoning attacks on shared recursive nameservers.
yum install caching-namserver + beat NM into leaving resolv.conf alone somehow. +1
Slashdot Posted Dec 9, 2012 2:37 UTC (Sun) by Lennie (subscriber, #49641) [Link]
If everyone did that, then I hope you mean: local, caching, fully capable, forwarding recursor.
Because we really don't want every desktop talking to the root or top level domain servers.
Slashdot Posted Dec 9, 2012 6:45 UTC (Sun) by paulj (subscriber, #341) [Link]
Forwarding would just add latency and fragility. The .'s are a fixed set (in terms of the IPs), both the . and TLDs are quite a large set in terms of # of servers. The commonly contacted ones would be cached. Also, I've seen scribblings in the IETF journal once that questioned whether hierarchy of caching achieved much in the way of gains. Finally, the .'s and TLDs can handle the additional load - anycast is a powerful tool.
Slashdot Posted Dec 9, 2012 14:24 UTC (Sun) by Lennie (subscriber, #49641) [Link]
The average website has 14 domains linked from the first website people visit: http://httparchive.org/trends.php
You really want every device with a browser to talk to the TLD servers for each of these domains ? (yes many are the same domain: so let's say 7 per website you visit).
That's doesn't add up.
Slashdot Posted Dec 9, 2012 18:12 UTC (Sun) by paulj (subscriber, #341) [Link]
The roots and TLDs are *more* than capable of handling requests from every device on the internet, without caching. There is a simple proof for this: They *did so* - users will regularly make typos in their browsers, queries for these non-existent domains will go out to the "." and (if the TLD is valid) to the TLDs.
Perhaps this decreased a little since browsers started diverting things typed into the address bar to search engines.
However, the fact remains that the roots and TLDs *already* get hit by queries from *every* device with an interactive user, as well as any which happen to query for some misconfigured or no longer valid hostname. The . and TLDs are *already* setup to handle this kind of load, cause they already get it.
What the intermediate caches do is:
a) Not provide effective caching (distribution of queries is very long tailed) - see e.g. http://dl.acm.org/citation.cfm?id=581877 (and I think there's a more recent ISOC article that found the same thing)
b) Potentially add latency - it may take longer for your computer to get its answer.
c) Provide a huge, juicy target for attackers - a DNS poisoning attack is so much more efficient if you poison a widely shared cache.
Slashdot Posted Dec 9, 2012 10:19 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
You man: Beat NM into not using dnsmasq for this? (At least in Debian. Not sure about other distributions).
Slashdot Posted Dec 9, 2012 12:57 UTC (Sun) by hummassa (subscriber, #307) [Link]
Ubuntu, too. I was asking myself the same thing.
Slashdot Posted Dec 9, 2012 16:37 UTC (Sun) by cortana (subscriber, #24596) [Link]
AFAIK dnsmasq is used for the connection sharing feature. I'm using NM on my machines and it merely writes the DHCP- or user-specified name servers into /etc/resolv.conf.
Stallman: Ubuntu Spyware: What to Do? Posted Dec 8, 2012 21:28 UTC (Sat) by geofft (subscriber, #59789) [Link]
Is that actually true? I recall hearing that it will stop sending as soon as you type "https", for exactly that reason.
(I do avoid Chrome because I dislike Google's corporate policies in general, but I think the individuals comprising the Chrome team are generally quite great about privacy issues like this.)
Stallman: Ubuntu Spyware: What to Do? Posted Dec 8, 2012 21:32 UTC (Sat) by Lennie (subscriber, #49641) [Link]
It really does do that.
Just checked now, with an updated version on Windows which I hardly use (so I assume that is the default setting).
Stallman: Ubuntu Spyware: What to Do? Posted Dec 9, 2012 20:03 UTC (Sun) by literfizzer (guest, #31274) [Link]
The browser in CyanogenMod supports DuckDuckGo as a search engine choice out of the box.
Stallman: Ubuntu Spyware: What to Do? Posted Dec 9, 2012 21:56 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
That's good news, but what should really happen is that search providers are used instead. IIRC, Firefox on Android stopped doing so sometime after 12 or so. The DDG add-on even stopped working too (though about:config still works, which is…less than ideal).
|
|||||||||||||