Re: [T(A)ILS-dev] search engine

Delete this message

Reply to this message
Autor: intrigeri
Data:  
Para: The T\(A\)ILS public development discussion list
Assunto: Re: [T(A)ILS-dev] search engine
Hi,

tim smy wrote (15 Jan 2011 22:50:12 GMT) :
> I put your comments forward to the duckduckgo.com forum and received
> this reply.


> While I am sure duckduckgo.com is a good search engine , and says
> that logs are erased nightly , is this enough? why keep logs at all?


I am concerned by these answers. Most of them you've received are of
that kind: "yes you need to give us this and that piece of
information, but we promise we won't do anything bad with it". This
sounds nicely to my hear, but T(A)ILS purpose is to *avoid* having to
trust such a service provider's privacy policy and servers security.
Also, no matter how kind and trustable they are, I guess DuckDuckGo
would comply with any legal request for user data. T(A)ILS is meant to
protect users against such threats regardless how nice and
privacy-friendly the service provider is.

> Thx! Anything in particular you want me to comment on?


>     > SSL version w/ HTTPS everywhere.


>     Scroogle also has a SSL version, which is used in T(A)ILS.


> HTTPS everywhere means that for major sites the organic links are
> automatically changed tho their https versions.


This is great to heard, but T(A)ILS 0.7 will ship with the HTTPS
Everywhere Firefox extension => T(A)ILS users would not get any added
benefit from this DuckDuckGo feature.

>     > Tor hidden service (about).


>     What would be the advantage in T(A)ILS?


> Not sure how T(A)ILS works, but the advantage is speed if you're on
> Tor. The end point is our server.


References needed, please. In my limited understanding of hidden
services, reaching a hidden website goes 7 hops instead of the usual 3
hops, so I fail to understand how it could be faster. I'd be happy to
stand corrected :)

>     > POST/Refcontrol settings.


>     > Privacy Settings
>     > For more info on these privacy settings, check out the Privacy Policy.
>     > Redirect:


>     >      If On it prevents sharing of your search with sites you click
>     >      on.


>     This hides to the clicked websites:


>      - the fact the user is coming from DuckDuckGo
>      - the search that was performed, in case GET is used -> see the
>        second "privacy" setting


>     On the other hand, I wonder how this is implemented without telling
>     DuckDuckGo what site the user is going to visit... which would be
>     pretty bad privacy-wise.


> The referer says duckduckgo.com, but the search terms are not there.
> We do not store ips or user agent so we have no idea what you in
> particular are clicking on. And right now we do nothing with this
> information anyway, and it is erased nightly.


"we have no idea" is a misleading way to answer my question. It should
really be read as "technically speaking, we could easily have a access
to that information, but we are nice and *right now* we do nothing
with it". As I explained above, although nice to hear, this statement
is meaningless in T(A)ILS context. I'd rather hear technical answers
to the technical issues I am raising, than ready-made conclusions of
the "you don't need to care, we are nice" kind.

My initial question really was: does this referer protection mean
trading "providing referer info to the websites visited from
DuckDuckGo" against "providing information to DuckDuckGo about what
links a user is clicking on their search result page"?

If it does, I'm unsure this trade-off is interesting wrt. T(A)ILS
design and goals, and *this* is a point that deserves discussing.

I think we'd rather go on working on adding some kind of referer
filtering in Torbutton / T(A)ILS: this would work for every website
and avoid providing that much information to any given party.

>     > Address bar:
>     >      If On, searches will appear in your address bar (GET vs POST
>     >      requests).


>     I fail to understand the privacy enhancement this brings. Could
>     someone explain? I can clearly see the privacy downside in case
>     referrers are not disabled.


> This is a) an over-the-shoulder privacy enhancement


This is a pretty valid point in favour of the POST requests.

> b) makes it harder for someone to looking through your browsing
> history on your computer.


Nice to hear generally , but I think we can ignore this in the context
of T(A)ILS as we run Firefox with history disabled.

>     > HTTPS:
>     >      If On, searches on the site will always go to the encrypted
>     >      version.


>     This would be a great thing to have.


>     > they are on by default.


>     According to the settings page I just visited the HTTPS setting is Off
>     by default.


> This just means if you land on our homepage with that setting on, it
> will submit searches to the https version. If you start on the https
> version always, it isn't needed.


Ok. If we switched T(A)ILS to use DuckDuckGo by default, we would
obviously start on the HTTPS version, so we can ignore this too.

>     Worried about how the default settings could be changed, I have had a
>     quick look to their website and it seems this can be done using [URL
>     parameters](https://duckduckgo.com/params.html) rather than cookies,
>     which is probably desirable in T(A)ILS context. We should be careful
>     about this though: using a non-default set of URL parameters would
>     help DuckDuckGo fingerprint T(A)ILS users.


> We don't store user agents. I'd also be fine with scrubbing these
> parameters from the logs nightly.


Well, one more [yes this would allow us fingerprinting T(A)ILS users]
"but we won't do it". I won't repeat myself once more.

To sum-up:

1. Every "privacy-related" DuckDuckGo feature is either useless in
T(A)ILS context, or implies to give much information about T(A)ILS
users activities to them (websites visited, general
fingerprinting). I'm therefore not in favour of using such
features. We nevertheless need to somehow provide equivalent
protection to T(A)ILS users.
2. The POST thing is convincing and shall be investigated: either by
doing whatever is needed to have our default Scroogle search use
POST rather than GET, or by switching to using DuckDuckGo.
3. Regardless of DuckDuckGo's "privacy" features (that are probably
generally nice, but poor security theater in the context of
T(A)ILS), we might simply want to make T(A)ILS users less dependent
on Google, and/or consider DuckDuckGo is a great search engine,
and/or escape the honeypot Scroogle kind of is.

Thoughts?