December 2009 - Dillo-dev - lists.mailman3.com

display: inline
by tim.nieradzik＠gmx.de 25 Jan '10

25 Jan '10

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

dillo2.x on Fedora 12
by itsme_410＠yahoo.com 19 Jan '10

19 Jan '10

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

3 5

web bug save?
by bblochl＠arcor.de 12 Jan '10

12 Jan '10

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

patch: handle cookie time overflow
by corvid＠lavabit.com 02 Jan '10

02 Jan '10

I saw a cookie with an expiration date of 2039, which is beyond the end of the universe for me, so it turned into 1903. So I made this, and it's working for me, but maybe you will know a nicer calculation, or a portability subtlety that I should handle.

2 2

patch: .domain cookies from/to domain
by corvid＠lavabit.com 02 Jan '10

02 Jan '10

Like the patch says, /* * Technically, cookies set with a domain of .example.com cannot be sent * back to the host example.com, even if example.com set them in the first * place. Do most user agents allow it? Yes. Does a large percentage of the * web require it in order to work at all? Yes. */ The downside might be the scenario of sub.example.com setting a cookie that example.com didn't expect to receive, but if everyone else does it... Unless someone tells me not to within the next few days, I'll commit something along the lines of this patch. PS I just committed a change today to fix up expiration/replacement of cookies, which was somewhat broken in general, and especially broken with respect to session cookies, so if anyone out there uses cookies much, please test!

3 7

[bug]: CSS - attack of the mega-images
by onepoint＠starurchin.org 01 Jan '10

01 Jan '10

See http://blog.worldlabel.com/2009/inkscape-0-47-totally-solid-with-lots-of-ne… Dillo inflates the images in the top toolbar to the full width of the window. The problem is this CSS (taken from the original stylesheet and simplified) a { display:block; float:left; } a img { width:100%; height:100%; } I guess Dillo is interpreting 100% relative to the wrong length? Firefox renders the images at normal size. (Minimal example attached.) Regards, Jeremy

2 1

table/cell width problem
by corvid＠lavabit.com 29 Dec '09

29 Dec '09

Also, I finally got around to looking into why the columns are strange on http://hg.dillo.org/dillo when I have remote style sheets enabled. Each row is a separate table, and the date and submitter fields have fixed widths specified in ems. That seems to work in general, but the problem is that the tables have width specified as 100%, which seems to make the table code forget about the column widths.

3 3

Problem while running Dillo2 browser on latest CVS LTIB code + IMX27 ADS
by rmarathe＠i-rode.com 28 Dec '09

28 Dec '09

Hi, We are working on IMX27 ADS board and have taken latest CVS based LTIB code. I have included 'Dillo2' and 'fltk' packages as my objective would be to run the browser dillo on the imx27 system. After the Linux boots up, I go to the console and try to run the browser. But, I get the following error: ---------------------------------------------------------------------- mx27# mx27# mx27# ./dillo paths: Cannot open file '//.dillo/dillorc' paths: Using /usr/etc/dillo/dillorc paths: Cannot open file '//.dillo/keysrc' paths: Using /usr/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Disabling cookies. Can't open display ":0.0" mx27# ---------------------------------------------------------------------- I did try to debug and found out that the function fltk::open_display returns the above display error. How do I set the display correctly so that the browser's opening page gets displayed on the LCD panel connected to IMX27 board ? regards, Rajesh Marathe.

2 1

secure cookies
by corvid＠lavabit.com 27 Dec '09

27 Dec '09

[cookies seem to be working for me after all, despite the error messages] Cookies can have an optional Secure attribute that instructs the user agent to send the cookie only over a secure connection. I can't find anything at all saying that they can only be set by secure connections. This seems strange to me. I'd think that the man in the middle could have fun by giving the user some other session key or whatever when, say, an image is being retrieved over plain http.

1 0

are cookies supposed to be working nowadays?
by corvid＠lavabit.com 27 Dec '09

27 Dec '09

Tried enabling some cookies to test something, and I'm getting a lot of this sort of thing: [cookies dpi]: Enabling cookies as from cookiesrc... [cookies dpi]: (v.1) accepting connections... [cookies dpi]: Old netscape-style cookie... [cookies dpi]: Expires in 2000223 seconds, at Tue Jan 19 08:35:26 2010 ** ERROR **: [a_Dpi_send_blocking_cmd] Can't read message. It's a shiny new copy of the cookies dpi, and I haven't been seeing any problems with other dpis...

1 0