September 2014 - Dillo-dev - lists.mailman3.com

Problems tackling a bug

by james.from.wellington＠gmail.com

So it's probably a heissenbug, depending on the timing between two events. Options: - show us the bad backtrace in GDB, in case it rings a bell for someone - hang the -O1 code, send it SIGABRT to make it dump core, backtrace the core, and see if it's any better - someone who knows the code to guess what needs to be slowed down, to make it reliably reproduceable On 9/11/14, Sebastian Geerken <sgeerken at dillo.org> wrote: > On Mi, Sep 10, 2014, eocene at gmx.com wrote: >> Sebastian wrote: >> > I noticed that the current tip of dillo hangs in most cases when >> > displaying <http://www.dillo.org/>. I succeeded to reproduce this bug >> > in gdb, but get many "<optimized out>" values. So I tried to reduce >> > optimization, but unfortunately had problems reproducing this bug: >> > >> > - "-O2" (standard): reproducable both stand-alone and in gdb; >> > - "-O1": reproducable stand-alone, but not in gdb; >> > - "-O0": not reproducable at all. >> > >> > Versions envolved: >> > >> > $ gcc --version >> > gcc (Debian 4.7.2-5) 4.7.2 >> > $ gdb --version >> > GNU gdb (GDB) 7.4.1-debian >> > >> > Any ideas? >> >> I have the same gcc and gdb, and dillo doesn't seem to want to hang >> for me. Does it depend on your dillorc options? > > Removing ~/.dillo makes no difference. > > Neither does switching to other versions (gcc and g++ 4.4). > > Sebastian > >

Sept. 10, 2014

Problems tackling a bug

by sgeerken＠dillo.org

On Mi, Sep 10, 2014, eocene at gmx.com wrote: > Sebastian wrote: > > I noticed that the current tip of dillo hangs in most cases when > > displaying <http://www.dillo.org/>. I succeeded to reproduce this bug > > in gdb, but get many "<optimized out>" values. So I tried to reduce > > optimization, but unfortunately had problems reproducing this bug: > > > > - "-O2" (standard): reproducable both stand-alone and in gdb; > > - "-O1": reproducable stand-alone, but not in gdb; > > - "-O0": not reproducable at all. > > > > Versions envolved: > > > > $ gcc --version > > gcc (Debian 4.7.2-5) 4.7.2 > > $ gdb --version > > GNU gdb (GDB) 7.4.1-debian > > > > Any ideas? > > I have the same gcc and gdb, and dillo doesn't seem to want to hang > for me. Does it depend on your dillorc options? Removing ~/.dillo makes no difference. Neither does switching to other versions (gcc and g++ 4.4). Sebastian

Sept. 10, 2014

Problems tackling a bug

by eocene＠gmx.com

Sebastian wrote: > I noticed that the current tip of dillo hangs in most cases when > displaying <http://www.dillo.org/>. I succeeded to reproduce this bug > in gdb, but get many "<optimized out>" values. So I tried to reduce > optimization, but unfortunately had problems reproducing this bug: > > - "-O2" (standard): reproducable both stand-alone and in gdb; > - "-O1": reproducable stand-alone, but not in gdb; > - "-O0": not reproducable at all. > > Versions envolved: > > $ gcc --version > gcc (Debian 4.7.2-5) 4.7.2 > $ gdb --version > GNU gdb (GDB) 7.4.1-debian > > Any ideas? I have the same gcc and gdb, and dillo doesn't seem to want to hang for me. Does it depend on your dillorc options?

Sept. 10, 2014

Problems tackling a bug

by sgeerken＠dillo.org

Hi! I noticed that the current tip of dillo hangs in most cases when displaying <http://www.dillo.org/>. I succeeded to reproduce this bug in gdb, but get many "<optimized out>" values. So I tried to reduce optimization, but unfortunately had problems reproducing this bug: - "-O2" (standard): reproducable both stand-alone and in gdb; - "-O1": reproducable stand-alone, but not in gdb; - "-O0": not reproducable at all. Versions envolved: $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 $ gdb --version GNU gdb (GDB) 7.4.1-debian Any ideas? Sebastian

Sept. 10, 2014

Browser tracking

by eocene＠gmx.com

Jorge wrote: > This site is interesting. It gives kind of a score of web browser > trackability. [1] > > @corvid, I thought you'd like to give it a look (AFAIR, you have submitted > some standardizing to our HTTP querying in the past). It looks like > our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. > > It looks simple to provide some less unique alternatives in dillorc. Yes, this site was part of the impetus to work on the headers in March to make dillo resemble firefox more closely, and add deflate decompression and add keepalive. User-agent is a little misleading in that I have a current firefox user-agent string, and panopticlick says that's one in 2701.57 browsers, but no doubt it's rather more common among the visitors in September 2014 specifically. Somewhat related, I've been working on SSL in the browser, and https://www.ssllabs.com/ssltest/viewMyClient.html shows some more ways for browsers to reveal what they are. > DISCLAIMER: this is just on little aspect of the privacy chain. > Most probably this is moot unless you're behind a TOR ring. YMMV. Indeed. > > [1] https://panopticlick.eff.org/

Sept. 9, 2014

Browser tracking

by jcid＠dillo.org

On Mon, Sep 08, 2014 at 09:42:06PM +0200, Sebastian Geerken wrote: > On Mo, Sep 08, 2014, Jorge Arellano Cid wrote: > [...] > > DISCLAIMER: this is just on little aspect of the privacy chain. > > Most probably this is moot unless you're behind a TOR ring. YMMV. > > For what I've understood, TOR wouldn't help. I mean: usually an IP and a time window is all you need. Unless the site is being accessed in parallel from the same IP, there's almost no way to avoid session tracking. That's were TOR helps (AFAIU). -- Cheers Jorge.-

Sept. 9, 2014

Browser tracking

by andreas＠kemnade.info

Hi, On Mon, 8 Sep 2014 16:15:53 -0300 Jorge Arellano Cid <jcid at dillo.org> wrote: > Hi, > > This site is interesting. It gives kind of a score of web browser > trackability. [1] > > @corvid, I thought you'd like to give it a look (AFAIR, you have submitted > some standardizing to our HTTP querying in the past). It looks like > our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. > > It looks simple to provide some less unique alternatives in dillorc. > The User Agent string of dillo does not have that many version numbers like the ones of other browsers. I compared the table with iceweasel and chromium. dillo was the least unique browser of them. But there is of course much more to improve. Greetings Andreas Kemnade

Sept. 8, 2014

Browser tracking

by sgeerken＠dillo.org

On Mo, Sep 08, 2014, Jorge Arellano Cid wrote: > Hi, > > This site is interesting. It gives kind of a score of web browser > trackability. [1] > > @corvid, I thought you'd like to give it a look (AFAIR, you have submitted > some standardizing to our HTTP querying in the past). It looks like > our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. > > It looks simple to provide some less unique alternatives in dillorc. > > [1] https://panopticlick.eff.org/ I once started to read the paper (stopped where the math gets too complcated ;-) ); I remember that it is relatively simple to track a browser even if the browser fingerprint, which consists of numerous attributes, changes slightly when only few attributes (e. g. browser version) change. This gave me a vague idea to randomize these attributes exactly in a way to break re-detection. Dillo could perhaps be a good testbed for this. > DISCLAIMER: this is just on little aspect of the privacy chain. > Most probably this is moot unless you're behind a TOR ring. YMMV. For what I've understood, TOR wouldn't help. Sebastian

Sept. 8, 2014

Browser tracking

by jcid＠dillo.org

Hi, This site is interesting. It gives kind of a score of web browser trackability. [1] @corvid, I thought you'd like to give it a look (AFAIR, you have submitted some standardizing to our HTTP querying in the past). It looks like our HTTP_ACCEPT and "User Agent" are the most vulnerable to tracking. It looks simple to provide some less unique alternatives in dillorc. DISCLAIMER: this is just on little aspect of the privacy chain. Most probably this is moot unless you're behind a TOR ring. YMMV. [1] https://panopticlick.eff.org/ -- Cheers Jorge.-

Sept. 8, 2014

duckduckgo

by james.from.wellington＠gmail.com

Google also redirects through itself. The rationale is to avoid leaking your search terms to the found site, in the referring URL field that Dillo doesn't populate. The reasons will include using that to create a market for analytics and attempting to measure whether the search delivers people's preconceptions. On the DDG parameters page: https://duckduckgo.com/params there is a redirect parameter: kd=-1 for off With casual testing, this search url in dillorc seems to work for me, and not to generate a second round-trip through ddg: search_url="dd DuckDuckGo https://duckduckgo.com/lite/?kp=-1&kd=-1&kh=1&q=%s" but I can't see the redirect even if I turn it on, so that's not very conclusive. On 9/6/14, eocene <eocene at gmx.com> wrote: > > Just tried searching for something using duckduckgo with midori, using > the standard search, not the light one. I copied the link URL and saw > that they're doing the same thing that google does -- the link URL shown > at the bottom of the screen is what you expect, but the link is really > a redirection through duckduckgo. > > Doesn't look like dillo does that -- maybe something to do with > javascript, didn't matter why to me. > > Anyway, I didn't exactly like ddg behaving this way, and I believe I > will try using startpage more often instead. (Although I have to turn > off CSS to get a next button on startpage results...) > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Sept. 8, 2014