- Dillo-dev - lists.mailman3.com

How to use the tab or other keyboard keys to set foucs on web page links?
by sdliyong＠gmail.com Feb. 7, 2010

Feb. 7, 2010

Hello All, I am using the Dillo on an embedded device for web browsing. Since this device does not support mouse or touchscreen, I have to use the keyboard(or some buttons). I found I cannot set the focus on these links using tab keys( Dillo 2.2-rc1). If there any key configuration settings to set the tab key? If not, I want to modify the source code to add this function, is there any example or related patches for reference? Thanks a lot! Yong

2 1

.hgignore needs updating?
by furaisanjin＠gmail.com Jan. 28, 2010

Jan. 28, 2010

Hi all. This is a minor issue but after building dillo, hg status shows this. ? test/cookies I guess .hgignore needs updating. Regards, furaisanjin

3 9

dpidc
by corvid＠lavabit.com Jan. 26, 2010

Jan. 26, 2010

- Why does install-dpi-local put dpidc in ~/.dillo, anyway? Wouldn't that be unusual for it to be in anyone's path? - Do you think it would be silly to make a little manpage for dpidc? - I'm contemplating making dpidc's exit values distinguish between the cases of: 1) Bad usage. Wrong number of args. 2) I can't find the stuff to communicate with dpid (either because this the first use of dillo, or the dpi system has been changed). 3) Connection refused. I think dpid just isn't running right now. 4) Something is breaking while communicating with dpid.

4 8

display: inline
by tim.nieradzik＠gmx.de Jan. 25, 2010

Jan. 25, 2010

I am currently working on adding CSS support for "display: inline" tags. They are commonly used for navigation menus. As these menus are nothing more than simple unordered lists (<ul>), the items are printed one below the other which wastes lots of space. The patch I came up with does only partially implement support for these tags: The items are correctly displayed within one line but I cannot figure out why there is so much empty space after each item. Perhaps somebody with a better understanding of the dw-code than me might have a look into the issue. If I am correct, the dw/textblock.cc is responsible for calculating the widths. Textblock::wordWrap() looks pretty promising as there is a variable (hasListitemValue) determining whether it is a list item and calculates values for lastLine->leftOffset and words->getRef(0)->effSpace depending on this state. --Tim

6 27

Re: even more cookies SECURITY
by jcid＠dillo.org Jan. 24, 2010

Jan. 24, 2010

Hi, I want to start this 2010 year thanking all the people that have contributed to make Dillo what it is. It's been 10 years and a long way lays behind. Lots of people have shared their time/work/advice/help/money/. After all, what we have now is the addition of all those efforts. Thanks to you all!!! On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > Do we currently have anything that needs to be > fixed/implemented before a release would be sensible? Not that I remember. The only problem I recall was the error message you reported with cookies and later seemed to be working somehow. Besides, AFAIS the repo is stable enough to start rolling the release process. BTW, the cookie story is frustrating. Generally speaking: vested interests strive to kill commodity technologies to introduce their own and henceforward profit monopoly-like. This happens everywhere in the area we deal with e.g. HTTP, HTML, SGML, XML, scripting, flash, java, video streams, audio, cookies, AJAX, etc. Remember that not even the big players were able (nor willing) to implement the SPECS they co-designed. Dillo's game so far had been to support a subset with emphasis on efficiency and privacy. The game is never solved, the point is to decide well where to prune (see bottom line). Speaking of technology: Ten years ago it was images and tables, the FTP, then CGI, then cookies (the stateless HTTP, now with state), then frames (which faded 5 years later), then SGML (which was replaced by XML), then XML (which never succeeded over HTML tag soup). Then CSS (which is necessary these days. Despite IE never gave much for it). Somewhere in the middle there was java (and java beans), but it died. Then Flash, then AJAX, then silverlight, the cloud... IMHO, beyond the hyped technologies "du jour", Dillo is relevant as long as it's able to serve as an efficient information gathering tool, with emphasis on privacy. -- Cheers Jorge.-

3 8

experimental patch: gnutls for the https dpi
by corvid＠lavabit.com Jan. 21, 2010

Jan. 21, 2010

A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl. The answer is: If you borrow liberally from the public domain code in the gnutls manual, then not very much! So here's a toy for anyone who would like one: http://www.dillo.org/test/gnutls.0.patch Now we'll _have_ to have a release soon, because we're accumulating so many things to play with after release...

3 5

dillo2.x on Fedora 12
by itsme_410＠yahoo.com Jan. 19, 2010

Jan. 19, 2010

Hi, Any likelihood of getting some Fedora 12 dillo2 RPMS? Thanks for the great work!! Best, T

3 5

Cookies performance
by Johannes.Hofmann＠gmx.de Jan. 19, 2010

Jan. 19, 2010

Hi, I noticed that since the recent DPI update pages which use cookies load slower (e.g. fltk.org) Do others also see that? It could also be OS specific. Cheers, Johannes

3 25

some code for better cookie rejection
by corvid＠lavabit.com Jan. 16, 2010

Jan. 16, 2010

Yesterday I made a rough draft of some code to allow the use of the http://publicsuffix.org/list/ to determine which domains dillo shouldn't allow cookies to be set for: http://www.dillo.org/test/public_suffix.diff I just put it there for safekeeping for now, as I have no plans to clean it up and get it into dillo until after the next release, but it occurred to me that I should at least mention it's there for anyone who uses cookies and lives somewhere where the domain situation is complicated (e.g., Japan). A user would have to add a line to cookiesrc like public_suffix_file /path/to/list/file

1 0

web bug save?
by bblochl＠arcor.de Jan. 12, 2010

Jan. 12, 2010

Jorge Arellano Cid schrieb: > On Fri, Dec 25, 2009 at 05:46:22PM +0000, corvid wrote: > >> bb wrote: >> >>> *On http://www.dillo.org/ I found the item News and a remark: >>> >>> 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix >>> for malicious images. I am not shure what is meant with **malicious >>> images? Are this so called Web bugs? If yes - how is the blocking >>> done? >>> >> Here's the advisory about the image size problem: >> http://www.ocert.org/advisories/ocert-2009-008.html >> >> >>> I think there are some strategies possible to prevent a browser from >>> a Web Bug attack: >>> >>> 1. Dont allow to load gifs or pngs from another URL as the actual >>> page comes from. (I think to remember that firefox **originally >>> **had such an option - not available in the actual version.) >>> >> Here's the beginning of a thread and a patch experimenting with this: >> http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.ht… >> >> (the "same host" option was found to be useless, but I'm still >> interested in >> "same domain") >> >> >>> 2. I think one might prepare HTML/CSS not to load such gifs or pngs >>> smaller than say about 5x5. Do you think such a measure is feasible >>> in Dillo and could that really stop Web Bugs? But I think that there >>> should not be a problem to make Web Bugs larger than 1x1pixel as >>> long as they are transparent - may be I am wrong, I am just a simple >>> minded user, not a web professional. So such a limit might be useless? >>> > > AFAIS your analysis is correct. There's no problem in increasing the > web bug image size, specially on these broadband days... > > Personally I have hopes on restricting resource loading from other > sites, > but as corvid cites, it's non trivial and requires careful thought. > > As a highly interested user, you may gather some information on > web bugs, techniques to avoid them etc. and post a summary of > your findings here. That would help a lot. We have the knowledge > on how to code dillo and restricted time to work on it. If you > can help us everybody gains. > > > >> Here's a post and patch experimenting with rejecting images with a >> dimension >> of 0: >> http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html >> >> >> >>> Are there other ideas? I am highly interested in that Web Bug problem. >>> >> I'm glad to hear this, since user interest may encourage things to >> happen... >> > > I'm very interested in this topic, although haven't found free time > these days... > > > Thank you for your response. The begin of my web bug adventure was some curiousity as I gamed around with http://livehttpheaders.mozdev.org. I found some strange things, and momentarily felt like the guy in "The blue velvet", finding an cut ear and come into touch with an strange and eval world outside a wardrobe. The real eval things can only be done by javascript - so dillo is on the save side. It may be of general Interest: I found as a countermeasure the plugin ghostery for firefox. ghostery has a large list of known web bugs and can block it. Most of that software one may find is googles urchin.js, but ggogle has a new software ga.js. There was even launched "Turn Key Web Analytics In A Box" on Friday, December 18, 2009, see http://www.coradiant.com/news/091209_analyticsbox.htm. The List of web bugs you can find: http://code.google.com/p/ghostery/source/browse/trunk/firefox/ghostery-stat… One may check out a read-only working copy anonymously over HTTP: http://code.google.com/p/ghostery/source/checkout As I just pointed out, a dillo user cannot be tracked by any javascript code. But even a simple Web Bug with a http-rquest to a tracking server can get a lot of Information about the request AFAIK that is client IP address, certainly the request date/time, the page requested, HTTP code, bytes served, user agent, and referer. So the tracker knows the URL of the page containing the bug and allows the server to determine which particular Web page the user has accessed. But more, the URL of the bug can be appended with an arbitrary string in various ways with extra information to identify the loading conditions of the bug. This extra information can be added while sending the page or by JavaScript scripts after the download (but as ponted out - no Javascript with Dillo). Web bugs can also be used in combination with HTTP cookies (if there are any) like any other object transferred using the HTTP protocol. One might say, use a proxy. But I found that nearly all of the free proxys are real trojans and sending such web bugs, most often in the advertising pictures. I asked a couple of the providers of free proxy services. The usual answer was, that they do not send web bugs, but the bad advertisers do. And usually they offered ma thei payed service that is free of advertising. And very often that web bug requests will NOT be send via the proxy!! You sent me an option switch to forbid dillo to request another domain as that of the actually used page: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.ht… How can I patch Dillo in this way? It might be useful to have that as an option in Dillo, I am shure not every user is comfortable with that restriction. Seasons greetings BB

4 15