- Dillo-dev - lists.mailman3.com

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

HTML4 testpage containing all elements
by Johannes.Hofmann＠gmx.de Jan. 11, 2010

Jan. 11, 2010

Hi, does anyone have a test page containing all possible HTML4 element? Cheers, Johannes

2 1

want to test some experimental cookies code?
by corvid＠lavabit.com Jan. 10, 2010

Jan. 10, 2010

In recent days, I've been making a version of cookies dpi that follows the current cookies draft of the http state working group. I haven't tested it exhaustively yet, but if anyone who uses cookies wants to try it and watch the msgs and so on, let me know. As for how much validity or meaningfulness this draft has, let's see... - They've made the decision to describe the way things currently behave, having learned from the bitter experience of others who made RFC 2109 and RFC 2965*. In 2010, no one has any way to be King of Cookies. They write testcases and try all of the major browsers and decide what they want to write down in their spec when there are differences. - On their mailing list, from the user agents, they have an opera guy, the curl guy, and someone related to firefox, although I didn't take any notice of whether he has a position of authority in firefox or not. - Of course there will be changes. Smallish, I think. A cookie set without an explicit domain goes only to that domain. A cookie with a domain attribute is sent to that domain and any subdomain. A .domain attr cookie can go to domain. As for how to decide to reject cookies for, e.g., .co.uk, I don't think they're ever going to say too much. A cookie can be set for any path, regardless of the url path of the page setting it. Paths are matched when selecting cookies to return, though. Path-matching does work by slashes instead of simple prefixes. An http page can set a secure cookie (just like currently). An example of the little things that may change are that a cookie that is just VALUE instead of NAME=VALUE is currently allowed, but it's not decided for good yet. There are corner cases such as this that maybe they could make illegal without rendering themselves irrelevant. * To be precise, the main author of the RFCs has written that it was at least initially reasonable to think that what they were putting together in rfc 2109 would be adopted by user agents.

3 3

Doctree changes
by Johannes.Hofmann＠gmx.de Jan. 7, 2010

Jan. 7, 2010

Hi, I just committed a modification of the Doctree class which is used for CSS matching. Before it was just an interface that was implemented by StyleEngine. Now it is a real class that is used by StyleEngine. I hope the new origanization makes things a bit clearer. It also avoids virtual method calls in the performance critical CSS matching path. To me it seems that complex pages render a bit faster now, but I did not make any proper measurements. Cheers, Johannes

1 0

Query on interfacing IMX27 keyboard with Dillo browser.
by rmarathe11＠gmail.com Jan. 7, 2010

Jan. 7, 2010

Hello, I am using Dillo as a browser on IMX27 system. (working with latest CVS LTIB code). I wanted to interface imx27 Keyboard with the browser so that the UP/DOWN/etc. keys work on the browser pages. I have been using this with Touchscreen and I wanted to know if the Keyboard can be interfaced too. Presently, I saw that on any Linux installation with Dillo on it, only mouse works as mouse can be moved from one link to other link. But keyboard was not working. I would want to make the Keyboard UP/DOWN arrows take me up and down the links on a page in the Dillo browser. Is it possible to do this ? regards, Rajesh Marathe.

3 2

table/cursor oddity
by corvid＠lavabit.com Jan. 5, 2010

Jan. 5, 2010

A little bug that I just stumbled upon. <table border=1> <tr><td style="cursor:help">one<td style="cursor:wait">two<td>three <tr><td colspan=3>row </table> The style of the first td seems to be the style of the whole table. (I wasn't surprised that the text has the default cursor, since I know there's that weirdness with wordStyle and regular style. Speaking of which, is it spelled out anywhere what is going on with that exactly? I know there have been times when I've been in the area of the table code and some reason why it's necessary has become clear, but I don't think I've ever had the whole shape of the matter in my head.) Hmm. I just changed the first td to style="cursor:help; color:red", and it colored the first td correctly, and now the rest of the table shows the wait cursor. Interesting.

2 2

Query on Dillo browser supporting "frames"
by rmarathe＠i-rode.com Jan. 5, 2010

Jan. 5, 2010

Hi, Will Dillo2 browser support "Frames" in future ? IF yes, what is the time frame for that release ? regards, Rajesh Marathe.

2 1