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

[oph-villedieu@orange.fr: dillo_2.1.1]

by corvid＠lavabit.com

Johannes wrote: > On Sun, Dec 20, 2009 at 07:08:42PM +0000, corvid wrote: > > The vertical-align code I have around doesn't do anything for table cells. > > > > Can you share what you have so far? The latest for non-table-cell was http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007099.html (which points to a patch) and the latest for table-cell was http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007105.html

Dec. 26, 2009

web bug save?

by jcid＠dillo.org

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... -- Cheers Jorge.-

Dec. 26, 2009

web bug save?

by Johannes.Hofmann＠gmx.de

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? > > 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... > Absolutely. We really need to address this. Maybe we can do some more research again about what other browsers or plugins do about this. Cheers, Johannes

Dec. 26, 2009

[oph-villedieu@orange.fr: dillo_2.1.1]

by Johannes.Hofmann＠gmx.de

On Sun, Dec 20, 2009 at 07:08:42PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Dec 20, 2009 at 11:28:15AM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > I just received this email. The attached example shows the bug. > > > Does anybody remember what we did with valign? ;) > > > > > > > > I'm afraid I found a bug in this release (?) : > > > > it does not understand the html tag <td valign="bottom"> > > > > it reads instead <td valign="top"> > > > I think we never supported valign=top | middle | bottom > > in dillo-fltk. > > We probabely need to implement it in Textblock::sizeAllocateImpl(). > > The vertical-align code I have around doesn't do anything for table cells. > Can you share what you have so far? Cheers, Johannes

Dec. 26, 2009

web bug save?

by corvid＠lavabit.com

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? 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...

Dec. 25, 2009

web bug save?

by bblochl＠arcor.de

*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? 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.) 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? Are there other ideas? I am highly interested in that Web Bug problem. Seasons greetings bblochl ** *

Dec. 25, 2009

[oph-villedieu@orange.fr: dillo_2.1.1]

by corvid＠lavabit.com

Johannes wrote: > I think we never supported valign=top | middle | bottom > in dillo-fltk. > We probabely need to implement it in Textblock::sizeAllocateImpl(). I realized that my current solution, already known to be awfully inefficient, wouldn't let me implement baseline alignment. So, back to Table::sizeAllocateImpl(). When I had tried modifying y and descent here the other day, it put things in roughly the right place, but my problem was that the box drawn around the cell wouldn't reach to the top anymore. I imagine modifying the top padding value might help. Would that be an improper way to go about it?

Dec. 24, 2009

valign table cells (Re: [Dillo-dev] dpi program names)

by corvid＠lavabit.com

Johannes wrote: > On Wed, Dec 23, 2009 at 07:28:40PM +0000, corvid wrote: > > Something...somewhere...gets confused sometimes, though. > > Maybe I'll puzzle it out, but we'll see. I hope it's not somewhere in > > the redraw optimizations or something. > > If that's the case, i.e. it get's fixed by dragging another window > over the dillo window, then I will try to fix that. Let's not hold > off features because of this optimization thing. Luckily it turned out to be a bug in my code. I was using getContentHeight() when I needed to determine this manually from the passed allocation instead.

Dec. 24, 2009

dpi program names

by Johannes.Hofmann＠gmx.de

On Wed, Dec 23, 2009 at 07:28:40PM +0000, corvid wrote: > When talking with the submitter for bug#930, I found that he used > --prefix, which meant that dpid couldn't be found when > the directory wasn't in his path. > --program-suffix, which meant that dillo wasn't going to find dpid > anyway. (Apparently the dpis also had the suffix, which is probably > not handled by anything, either.) > > To what degree do you think it would be reasonable to handle this? > > Teaching dillo to try the --prefix when searching for dpid is pretty > easy, but when it comes to --program-suffix...well, I'm not sure > whether that's hard to extract from autoconf or not, but there's also > "--program-transform-name" which takes a sed program that transforms > names into who-knows-what, and the prospect of teaching src/IO/dpi.c to > know what happened over in dpid/ makes me want to write something > in the FAQ about leaving the filenames themselves alone. We could do something about --prefix, but for the rest I would just add a note in the FAQ or improve error messages if necessary. > > > PS I discovered that I could get vertical-align and table cells to > pretty much work by making a TableCell::lineYOffsetWidgetAllocation > (so much for having the Textblock version inline!). Nice! > Something...somewhere...gets confused sometimes, though. > Maybe I'll puzzle it out, but we'll see. I hope it's not somewhere in > the redraw optimizations or something. If that's the case, i.e. it get's fixed by dragging another window over the dillo window, then I will try to fix that. Let's not hold off features because of this optimization thing. Cheers, Johannes

Dec. 23, 2009

dpi program names

by corvid＠lavabit.com

When talking with the submitter for bug#930, I found that he used --prefix, which meant that dpid couldn't be found when the directory wasn't in his path. --program-suffix, which meant that dillo wasn't going to find dpid anyway. (Apparently the dpis also had the suffix, which is probably not handled by anything, either.) To what degree do you think it would be reasonable to handle this? Teaching dillo to try the --prefix when searching for dpid is pretty easy, but when it comes to --program-suffix...well, I'm not sure whether that's hard to extract from autoconf or not, but there's also "--program-transform-name" which takes a sed program that transforms names into who-knows-what, and the prospect of teaching src/IO/dpi.c to know what happened over in dpid/ makes me want to write something in the FAQ about leaving the filenames themselves alone. PS I discovered that I could get vertical-align and table cells to pretty much work by making a TableCell::lineYOffsetWidgetAllocation (so much for having the Textblock version inline!). Something...somewhere...gets confused sometimes, though. Maybe I'll puzzle it out, but we'll see. I hope it's not somewhere in the redraw optimizations or something.

Dec. 23, 2009