- Dillo-dev - lists.mailman3.com

Javascript

by iveqy＠iveqy.com

Hi, I'm a big dillo fan and a fltk user. Dillo is the fastest browser I ever seens and I strongly like it (too bad fltk 1.3 isn't used but that I believe is to blame the fltk team for). Anyway, now that CSS is almost done, I wonder how the future for javascript support looks. The old discussions I found about this looks to be outdated with the CSS changes. I also found a patch to allow javascript in dillo, but that patch didn't seemed to use the dpi-interface. Would it be possible to use dpi to use the v8 enginge for dillo? -- Regards iveqy

Jan. 5, 2010

Query on Dillo browser supporting "frames"

by rmarathe＠i-rode.com

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

Jan. 5, 2010

table/cursor oddity

by Johannes.Hofmann＠gmx.de

On Mon, Jan 04, 2010 at 01:19:37AM +0000, corvid wrote: > 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.) If there is e.g. <div style="background-color:red">foo</div> dillo creates a textblock widget for the <div>, which will have a style set with backgoundColor red. Then the word foo is added. The question is what style should the word get? If it would get the same style as the textblock, we would draw a red background for each word again, which is unnecessary as the textblock has a red bg already. More important, it would simply be wrong for things like borders. We want the border around the whole <div>, not around each word. So basically for words we use the style of the containing textblock with resetValues() called plus some minor modifications to make things like <span style="background-color:red">foo</span> work, where <span> does not add a new widget to the textblock (this is the inheritBackgroundColor stuff). > > 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. Interesting indeed :-) I will have a look at this. Cheers, Johannes

Jan. 5, 2010

table/cursor oddity

by corvid＠lavabit.com

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.

Jan. 4, 2010

patch: handle cookie time overflow

by corvid＠lavabit.com

Jeremy wrote: > On Wed, Dec 30, 2009 at 07:32:19PM +0000, corvid wrote: > > > ... but maybe you will know a nicer calculation, or a portability > > subtlety that I should handle. > > > [...] > > +#define DILLO_TIME_MAX ((time_t) ((1UL << (sizeof(time_t) * 8 - 1)) - 1)) > > Quoting "man -S 0p types.h" > > * time_t and clock_t shall be integer or real-floating types. > > So at least in theory you should not assume that time_t is an integer > type. I've no idea how likely that is to be wrong in practice. (On > my system time_t is long.) Unfortunatly "man sysconf" does not > describe any maximum time value constant. Hmm... well, at least it wouldn't be any worse than it already is! There's a bunch of time_t <-> long in dpi/cookies.c.

Jan. 2, 2010

patch: handle cookie time overflow

by onepoint＠starurchin.org

On Wed, Dec 30, 2009 at 07:32:19PM +0000, corvid wrote: > ... but maybe you will know a nicer calculation, or a portability > subtlety that I should handle. > [...] > +#define DILLO_TIME_MAX ((time_t) ((1UL << (sizeof(time_t) * 8 - 1)) - 1)) Quoting "man -S 0p types.h" * time_t and clock_t shall be integer or real-floating types. So at least in theory you should not assume that time_t is an integer type. I've no idea how likely that is to be wrong in practice. (On my system time_t is long.) Unfortunatly "man sysconf" does not describe any maximum time value constant. Some Googling suggests that time_t is almost always a signed integer type. This is interesting: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/mktime.c /* The maximum and minimum values for the integer type T. These macros have undefined behavior if T is signed and has padding bits. If this is a problem for you, please let us know how to fix it for your host. */ #define TYPE_MINIMUM(t) \ ((t) (! TYPE_SIGNED (t) \ ? (t) 0 \ : TYPE_SIGNED_MAGNITUDE (t) \ ? ~ (t) 0 \ : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))) #define TYPE_MAXIMUM(t) \ ((t) (! TYPE_SIGNED (t) \ ? (t) -1 \ : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))) Regards, Jeremy Henty

Jan. 2, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 02, 2010 at 05:07:14PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Jan 02, 2010 at 04:19:26PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote: > > > > > > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > > > > > > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > > > > > > > > bb wrote: > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > I just remembered that I had another version later in the thread, > > > > > > > > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > > > > > > > > > > > > > > > http://www.dillo.org/test/filtering.2.patch > > > > > > > > > > > > > > > > I like the patch! > > > > > > > > > > > > > > > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > > > > > > > > give it broader testing from the Hg repo. My idea is to commit, > > > > > > > > if you agree, and to polish from the repo. > > > > > > > > > > > > > > I also agree. > > > > > > > It would be cool if we could replace rejected web bugs with some > > > > > > > ugly little pixmap, so people see them on the page and can analyze > > > > > > > the url. > > > > > > > That could also help with improving our heuristics to find the > > > > > > > web bugs. > > > > > > > > > > > > What do you think about just flagging suspicious images with some > > > > > > browser specific CSS thing (class, id, pseudo-class we.) > > > > > > Then we can specify something like > > > > > > > > > > > > img:-dillo-potential-web-bug {display: none} > > > > > > > > > > > > or > > > > > > > > > > > > img:-dillo-potential-web-bug {border: 2px solid red} > > > > > > > > > > > > Other browser also have specific extensions like this, e.g. > > > > > > -moz-broken, -moz-user-disabled > > > > > > > > > > CSS might be completely disabled. > > > > > > > > Remote CSS yes, but this stuff would be put into the user agent > > > > stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). > > > > These two can't be disabled. > > > > > > Oh, I see. > > > > > > I don't want to make requests for those images at all, though. > > > > Yes, but provided I can get the display:none stuff working some day, > > they would not be loaded at all if > > > > img:-dillo-potential-web-bug {display: none} > > > > is set. Additionally the user could do some fancy stuff by > > overriding this setting in his user stylesheet. > > I think disabling image loading is implemented similarly in other > > browsers. > > Oh, I see (again :) > > It would be nice to have something like you said before, with a pixmap > (or alt text) making it clear what's going on, and that can be clicked > to load or whatever. > Would we implement the content property or something? Maybe that would work. I haven't verified it though. This is all just an idea. Let's see whether I can come up with some real code...

Jan. 2, 2010

web bug save?

by corvid＠lavabit.com

Johannes wrote: > On Sat, Jan 02, 2010 at 04:19:26PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote: > > > > > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > > > > > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > > > > > > > bb wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > > > I just remembered that I had another version later in the thread, > > > > > > > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > > > > > > > > > > > > > http://www.dillo.org/test/filtering.2.patch > > > > > > > > > > > > > > I like the patch! > > > > > > > > > > > > > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > > > > > > > give it broader testing from the Hg repo. My idea is to commit, > > > > > > > if you agree, and to polish from the repo. > > > > > > > > > > > > I also agree. > > > > > > It would be cool if we could replace rejected web bugs with some > > > > > > ugly little pixmap, so people see them on the page and can analyze > > > > > > the url. > > > > > > That could also help with improving our heuristics to find the > > > > > > web bugs. > > > > > > > > > > What do you think about just flagging suspicious images with some > > > > > browser specific CSS thing (class, id, pseudo-class we.) > > > > > Then we can specify something like > > > > > > > > > > img:-dillo-potential-web-bug {display: none} > > > > > > > > > > or > > > > > > > > > > img:-dillo-potential-web-bug {border: 2px solid red} > > > > > > > > > > Other browser also have specific extensions like this, e.g. > > > > > -moz-broken, -moz-user-disabled > > > > > > > > CSS might be completely disabled. > > > > > > Remote CSS yes, but this stuff would be put into the user agent > > > stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). > > > These two can't be disabled. > > > > Oh, I see. > > > > I don't want to make requests for those images at all, though. > > Yes, but provided I can get the display:none stuff working some day, > they would not be loaded at all if > > img:-dillo-potential-web-bug {display: none} > > is set. Additionally the user could do some fancy stuff by > overriding this setting in his user stylesheet. > I think disabling image loading is implemented similarly in other > browsers. Oh, I see (again :) It would be nice to have something like you said before, with a pixmap (or alt text) making it clear what's going on, and that can be clicked to load or whatever. Would we implement the content property or something?

Jan. 2, 2010

patch: .domain cookies from/to domain

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > To me it seems reasonable what other browsers do here, even if the > > standard states it differently. > > I've discovered that the http-state working group is actively trying to > come up with something that reflects what is good and sensible for clients > and servers to do. > So I'm reading through their mailing list archives and all that... Their algorithm is that you pretend that you don't see any leading dots, and the domain-matching is done such that the .domain cookie is sent with queries to both sub.domain and domain. So that's the currently "normal" thing... Interestingly (alarmingly), only RFC cookies specify path/domain when sent from user agent to server, and, as I've said, pretty much everything ignores RFCness, so for instance if there could be a NAME=VAL1 sub.domain cookie and a NAME=VAL2 domain cookie and you have one of them, it's the task of people writing the server code to make sure they can tell what it belongs to. And if a user agent accidentally accepts/sends a cookie for a tld or something, no one will realize this. Speaking of alarming, it seems that it's normal to accept cookies for /path1 sent from /path2. That's irritating in part because I just disallowed that the other day.

Jan. 2, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 02, 2010 at 04:19:26PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote: > > > > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > > > > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > > > > > > bb wrote: > > > > > > > > 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. > > > > > > > > > > > > > > I just remembered that I had another version later in the thread, > > > > > > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > > > > > > > > > > > http://www.dillo.org/test/filtering.2.patch > > > > > > > > > > > > I like the patch! > > > > > > > > > > > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > > > > > > give it broader testing from the Hg repo. My idea is to commit, > > > > > > if you agree, and to polish from the repo. > > > > > > > > > > I also agree. > > > > > It would be cool if we could replace rejected web bugs with some > > > > > ugly little pixmap, so people see them on the page and can analyze > > > > > the url. > > > > > That could also help with improving our heuristics to find the > > > > > web bugs. > > > > > > > > What do you think about just flagging suspicious images with some > > > > browser specific CSS thing (class, id, pseudo-class we.) > > > > Then we can specify something like > > > > > > > > img:-dillo-potential-web-bug {display: none} > > > > > > > > or > > > > > > > > img:-dillo-potential-web-bug {border: 2px solid red} > > > > > > > > Other browser also have specific extensions like this, e.g. > > > > -moz-broken, -moz-user-disabled > > > > > > CSS might be completely disabled. > > > > Remote CSS yes, but this stuff would be put into the user agent > > stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). > > These two can't be disabled. > > Oh, I see. > > I don't want to make requests for those images at all, though. Yes, but provided I can get the display:none stuff working some day, they would not be loaded at all if img:-dillo-potential-web-bug {display: none} is set. Additionally the user could do some fancy stuff by overriding this setting in his user stylesheet. I think disabling image loading is implemented similarly in other browsers.

Jan. 2, 2010

web bug save?

by corvid＠lavabit.com

Johannes wrote: > On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote: > > Johannes wrote: > > > On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote: > > > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > > > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > > > > > bb wrote: > > > > > > > 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. > > > > > > > > > > > > I just remembered that I had another version later in the thread, > > > > > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > > > > > > > > > http://www.dillo.org/test/filtering.2.patch > > > > > > > > > > I like the patch! > > > > > > > > > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > > > > > give it broader testing from the Hg repo. My idea is to commit, > > > > > if you agree, and to polish from the repo. > > > > > > > > I also agree. > > > > It would be cool if we could replace rejected web bugs with some > > > > ugly little pixmap, so people see them on the page and can analyze > > > > the url. > > > > That could also help with improving our heuristics to find the > > > > web bugs. > > > > > > What do you think about just flagging suspicious images with some > > > browser specific CSS thing (class, id, pseudo-class we.) > > > Then we can specify something like > > > > > > img:-dillo-potential-web-bug {display: none} > > > > > > or > > > > > > img:-dillo-potential-web-bug {border: 2px solid red} > > > > > > Other browser also have specific extensions like this, e.g. > > > -moz-broken, -moz-user-disabled > > > > CSS might be completely disabled. > > Remote CSS yes, but this stuff would be put into the user agent > stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). > These two can't be disabled. Oh, I see. I don't want to make requests for those images at all, though.

Jan. 2, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote: > > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > > > > bb wrote: > > > > > > 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. > > > > > > > > > > I just remembered that I had another version later in the thread, > > > > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > > > > > > > http://www.dillo.org/test/filtering.2.patch > > > > > > > > I like the patch! > > > > > > > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > > > > give it broader testing from the Hg repo. My idea is to commit, > > > > if you agree, and to polish from the repo. > > > > > > I also agree. > > > It would be cool if we could replace rejected web bugs with some > > > ugly little pixmap, so people see them on the page and can analyze > > > the url. > > > That could also help with improving our heuristics to find the > > > web bugs. > > > > What do you think about just flagging suspicious images with some > > browser specific CSS thing (class, id, pseudo-class we.) > > Then we can specify something like > > > > img:-dillo-potential-web-bug {display: none} > > > > or > > > > img:-dillo-potential-web-bug {border: 2px solid red} > > > > Other browser also have specific extensions like this, e.g. > > -moz-broken, -moz-user-disabled > > CSS might be completely disabled. Remote CSS yes, but this stuff would be put into the user agent stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). These two can't be disabled.

Jan. 2, 2010

web bug save?

by corvid＠lavabit.com

Johannes wrote: > On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote: > > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > > > bb wrote: > > > > > 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. > > > > > > > > I just remembered that I had another version later in the thread, > > > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > > > > > http://www.dillo.org/test/filtering.2.patch > > > > > > I like the patch! > > > > > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > > > give it broader testing from the Hg repo. My idea is to commit, > > > if you agree, and to polish from the repo. > > > > I also agree. > > It would be cool if we could replace rejected web bugs with some > > ugly little pixmap, so people see them on the page and can analyze > > the url. > > That could also help with improving our heuristics to find the > > web bugs. > > What do you think about just flagging suspicious images with some > browser specific CSS thing (class, id, pseudo-class we.) > Then we can specify something like > > img:-dillo-potential-web-bug {display: none} > > or > > img:-dillo-potential-web-bug {border: 2px solid red} > > Other browser also have specific extensions like this, e.g. > -moz-broken, -moz-user-disabled CSS might be completely disabled.

Jan. 2, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote: > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > > bb wrote: > > > > 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. > > > > > > I just remembered that I had another version later in the thread, > > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > > > http://www.dillo.org/test/filtering.2.patch > > > > I like the patch! > > > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > > give it broader testing from the Hg repo. My idea is to commit, > > if you agree, and to polish from the repo. > > I also agree. > It would be cool if we could replace rejected web bugs with some > ugly little pixmap, so people see them on the page and can analyze > the url. > That could also help with improving our heuristics to find the > web bugs. What do you think about just flagging suspicious images with some browser specific CSS thing (class, id, pseudo-class we.) Then we can specify something like img:-dillo-potential-web-bug {display: none} or img:-dillo-potential-web-bug {border: 2px solid red} Other browser also have specific extensions like this, e.g. -moz-broken, -moz-user-disabled Cheers, Johannes

Jan. 2, 2010

patch: .domain cookies from/to domain

by corvid＠lavabit.com

Johannes wrote: > To me it seems reasonable what other browsers do here, even if the > standard states it differently. I've discovered that the http-state working group is actively trying to come up with something that reflects what is good and sensible for clients and servers to do. So I'm reading through their mailing list archives and all that... What I can say so far is: I was very wrong when I thought that trying to follow the cookie RFCs was good or important.

Jan. 1, 2010

patch: .domain cookies from/to domain

by Johannes.Hofmann＠gmx.de

On Thu, Dec 31, 2009 at 11:18:06PM +0000, corvid wrote: > I wrote: > > Jorge wrote: > > > On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote: > > > > 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... > > > > > > AFAIS it would provide a very good way for tracking what pages > > > a user is reading to big hosting sites. e.g. blogspot.com > > > > I believe in that case, subdomains of blogspot.com would already be able > > to read/write a .blogspot.com cookie. > > > > > If you're using a unique IP, it may not add much, but if you're > > > behind a NAT or proxy or similar, this cookie singles out you. > > > > > > Considering most browsers allow these cookies, chances of > > > finding tracking code using this technique increases! Probably > > > only opaqued by the much bigger privacy hole javascript provides. > > > > > > :) > > > > > > > Unless someone tells me not to within the next few days, I'll commit > > > > something along the lines of this patch. > > > > > > I'd use a cookiesrc option set to NO by default instead of the > > > #define. > > > > > > Maybe allowing to set it by site (as the rest of cookiesrc) is > > > not a bad idea too. After all, people would enable it when they > > > need a specific site to work. > > > > Setting it by site sounds like a good idea. > > I'm thinking about the exact form of this now. > cookiesrc could look something like > example.com ACCEPT_SESSION SEND_DOTDOMAIN_COOKIES > but that's weird and hard to understand. > > Any thoughts on how to make something decent? Maybe I'm missing the point in the previous discussion, but do we really need this configurable? Why do we need to handle the host example.com differently from e.g. foo.example.com? To me it seems reasonable what other browsers do here, even if the standard states it differently.

Jan. 1, 2010

[bug]: CSS - attack of the mega-images

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Wed, Dec 30, 2009 at 04:23:04PM +0000, Jeremy Henty wrote: > > 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.) Thanks for the nice example. Actually I don't quite understand how this piece of CSS works because I haven't looked at float: in detail yet. However, if I remove the float:left; part, then even firefox blows up the images. As dillo currently just ignores float:left, I'd say there is not much we can do for now - other thank implement float support of course :-) Cheers, Johannes

Jan. 1, 2010

patch: .domain cookies from/to domain

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote: > > > 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... > > > > AFAIS it would provide a very good way for tracking what pages > > a user is reading to big hosting sites. e.g. blogspot.com > > I believe in that case, subdomains of blogspot.com would already be able > to read/write a .blogspot.com cookie. > > > If you're using a unique IP, it may not add much, but if you're > > behind a NAT or proxy or similar, this cookie singles out you. > > > > Considering most browsers allow these cookies, chances of > > finding tracking code using this technique increases! Probably > > only opaqued by the much bigger privacy hole javascript provides. > > > > :) > > > > > Unless someone tells me not to within the next few days, I'll commit > > > something along the lines of this patch. > > > > I'd use a cookiesrc option set to NO by default instead of the > > #define. > > > > Maybe allowing to set it by site (as the rest of cookiesrc) is > > not a bad idea too. After all, people would enable it when they > > need a specific site to work. > > Setting it by site sounds like a good idea. I'm thinking about the exact form of this now. cookiesrc could look something like example.com ACCEPT_SESSION SEND_DOTDOMAIN_COOKIES but that's weird and hard to understand. Any thoughts on how to make something decent?

Jan. 1, 2010

web bug save?

by corvid＠lavabit.com

Johannes wrote: > On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > > Sometimes I wonder whether > > connecting through to a TOR network could help us a lot with it. > > You can already use dillo with privoxy and tor. We could perhaps > make it more convenient to configure such a setup. > We also would need to make sure that really all requests go through > the proxy, e.g. I'm not sure, whether wget called from dowload.dpi > uses the proxy from dillorc. I have warnings in the FAQ and dillorc that the wget env variables would need to be set appropriately, but it would be nice to have dillo send that to the dpi in requests so that it can set the environment for sure before execing wget.

Dec. 31, 2009

web bug save?

by Johannes.Hofmann＠gmx.de

On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote: > On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > > bb wrote: > > > 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. > > > > I just remembered that I had another version later in the thread, > > and I just took a couple of minutes to get the patch to apply cleanly again. > > > > http://www.dillo.org/test/filtering.2.patch > > I like the patch! > > Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can > give it broader testing from the Hg repo. My idea is to commit, > if you agree, and to polish from the repo. I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs. > > > > > [Somebodey wrote:] > > > I have also found same_host not to have any value. > > > > > > > Generally, is it really a problem if we load url's from other > > > > hosts/domains? > > > > > > Sites have no right to redirect me to unrelated sites, and > > > sites have no right to subject me to images from unrelated sites. > > > > I tend to agree. With your patch I noticed that many popular sites > > contain 1x1 images from some statistics gathering companies. > > However I think these images do not really leak additional information as > > the sites could report your IP address behind the scenes as well. > > The IP sometimes is not one-to-one (proxies, NATs, etc). The > cookie guarantees user tracking, when they're using the same IP > or even the same machine! > > > I think the term "user agent" for a browser is very apt. > > These companies ask dillo to serve as an accomplice > > as they violate the user's right to privacy. > > Privacy is very complex to achieve. Very accurate knowledge in > a broad range is necessary. Sometimes I wonder whether > connecting through to a TOR network could help us a lot with it. You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc. Cheers, Johannes

Dec. 31, 2009

web bug save?

by jcid＠dillo.org

On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote: > bb wrote: > > 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. > > I just remembered that I had another version later in the thread, > and I just took a couple of minutes to get the patch to apply cleanly again. > > http://www.dillo.org/test/filtering.2.patch I like the patch! Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo. > > [Somebodey wrote:] > > I have also found same_host not to have any value. > > > > > Generally, is it really a problem if we load url's from other > > > hosts/domains? > > > > Sites have no right to redirect me to unrelated sites, and > > sites have no right to subject me to images from unrelated sites. > > I tend to agree. With your patch I noticed that many popular sites > contain 1x1 images from some statistics gathering companies. > However I think these images do not really leak additional information as > the sites could report your IP address behind the scenes as well. The IP sometimes is not one-to-one (proxies, NATs, etc). The cookie guarantees user tracking, when they're using the same IP or even the same machine! > I think the term "user agent" for a browser is very apt. > These companies ask dillo to serve as an accomplice > as they violate the user's right to privacy. Privacy is very complex to achieve. Very accurate knowledge in a broad range is necessary. Sometimes I wonder whether connecting through to a TOR network could help us a lot with it. -- Cheers Jorge.-

Dec. 31, 2009

patch: handle cookie time overflow

by corvid＠lavabit.com

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.

Dec. 30, 2009

[bug]: CSS - attack of the mega-images

by onepoint＠starurchin.org

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

Dec. 30, 2009

patch: .domain cookies from/to domain

by corvid＠lavabit.com

I realized that there's an asymmetry in the dillo code with it accepting but not sending .example.com for a host example.com, when this asymmetry is not in the spec, AFAICT. Cookies are to be rejected if the "value for the request-host does not domain-match the Domain attribute", and "Host A's name domain-matches host B's if * both host names are IP addresses and their host name strings match exactly; or * both host names are FQDN strings and their host name strings match exactly; or * A is a FQDN string and has the form NB, where N is a non-empty name string, B has the form .B', and B' is a FQDN string. (So, x.y.com domain-matches .y.com but not y.com.)" So it seems that we "shouldn't" accept them in the first place.

Dec. 29, 2009

table/cell width problem

by Johannes.Hofmann＠gmx.de

-------- Original-Nachricht -------- > Datum: Tue, 29 Dec 2009 13:54:45 +0000 > Von: "corvid" <corvid(a)lavabit.com> > An: dillo-dev(a)dillo.org > Betreff: Re: [Dillo-dev] table/cell width problem > Jorge wrote: > > On Sun, Dec 27, 2009 at 05:27:08AM +0000, corvid wrote: > > > 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. > > > > IIRC a CSS-aware user agent can act as if old HTML presentation > > directives weren't there. Which could apply here. > > > > OTOH I don't know whether this would cause more harm. > > Let's suppose that it had been specified as <table style="width:100%">, > then. Enabling the code in dw/table.cc around line 697 seems to change this behaviour. Not sure if it already fixes it though. Cheers, Johannes -- Preisknaller: GMX DSL Flatrate f?r nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02

Dec. 29, 2009

table/cell width problem

by corvid＠lavabit.com

Jorge wrote: > On Sun, Dec 27, 2009 at 05:27:08AM +0000, corvid wrote: > > 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. > > IIRC a CSS-aware user agent can act as if old HTML presentation > directives weren't there. Which could apply here. > > OTOH I don't know whether this would cause more harm. Let's suppose that it had been specified as <table style="width:100%">, then.

Dec. 29, 2009

patch: .domain cookies from/to domain

by corvid＠lavabit.com

Jorge wrote: > On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote: > > 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... > > AFAIS it would provide a very good way for tracking what pages > a user is reading to big hosting sites. e.g. blogspot.com I believe in that case, subdomains of blogspot.com would already be able to read/write a .blogspot.com cookie. > If you're using a unique IP, it may not add much, but if you're > behind a NAT or proxy or similar, this cookie singles out you. > > Considering most browsers allow these cookies, chances of > finding tracking code using this technique increases! Probably > only opaqued by the much bigger privacy hole javascript provides. > > :) > > > Unless someone tells me not to within the next few days, I'll commit > > something along the lines of this patch. > > I'd use a cookiesrc option set to NO by default instead of the > #define. > > Maybe allowing to set it by site (as the rest of cookiesrc) is > not a bad idea too. After all, people would enable it when they > need a specific site to work. Setting it by site sounds like a good idea.

Dec. 29, 2009

table/cell width problem

by jcid＠dillo.org

On Sun, Dec 27, 2009 at 05:27:08AM +0000, corvid wrote: > 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. IIRC a CSS-aware user agent can act as if old HTML presentation directives weren't there. Which could apply here. OTOH I don't know whether this would cause more harm. -- Cheers Jorge.-

Dec. 29, 2009

patch: .domain cookies from/to domain

by jcid＠dillo.org

On Mon, Dec 28, 2009 at 01:21:41AM +0000, corvid wrote: > 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... AFAIS it would provide a very good way for tracking what pages a user is reading to big hosting sites. e.g. blogspot.com If you're using a unique IP, it may not add much, but if you're behind a NAT or proxy or similar, this cookie singles out you. Considering most browsers allow these cookies, chances of finding tracking code using this technique increases! Probably only opaqued by the much bigger privacy hole javascript provides. :) > Unless someone tells me not to within the next few days, I'll commit > something along the lines of this patch. I'd use a cookiesrc option set to NO by default instead of the #define. Maybe allowing to set it by site (as the rest of cookiesrc) is not a bad idea too. After all, people would enable it when they need a specific site to work. -- Cheers Jorge.-

Dec. 29, 2009

Problem while running Dillo2 browser on latest CVS LTIB code + IMX27 ADS

by jcid＠dillo.org

On Mon, Dec 28, 2009 at 04:49:42PM +0530, Rajesh Marathe wrote: > 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 ? Assuming you have the X server already running, run dillo as the same user that has the X server running (not root). Dillo needs the X server (or kdrive) to run. If you can run the fltk demo, dillo should run too. -- Cheers Jorge.-

Dec. 28, 2009

Problem while running Dillo2 browser on latest CVS LTIB code + IMX27 ADS

by rmarathe＠i-rode.com

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.

Dec. 28, 2009

web bug save?

by corvid＠lavabit.com

bb wrote: > 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. I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again. http://www.dillo.org/test/filtering.2.patch from the main directory of the dillo source, "patch -p1 < filtering.2.patch" and then put filter_auto_requests=same_domain in ~/.dillorc

Dec. 28, 2009

patch: .domain cookies from/to domain

by corvid＠lavabit.com

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!

Dec. 28, 2009

secure cookies

by corvid＠lavabit.com

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

Dec. 27, 2009

web bug save?

by bblochl＠arcor.de

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

Dec. 27, 2009

table/cell width problem

by corvid＠lavabit.com

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.

Dec. 27, 2009

are cookies supposed to be working nowadays?

by corvid＠lavabit.com

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

Dec. 27, 2009

[un]highlighting and drawing lines

by corvid＠lavabit.com

Yesterday, I noticed that simply clicking on a random spot on a page caused a bunch of drawLine()s. This turned out to be an unnecessary unhighlight. The attached code is what I got from playing around to see how much highlighting and unhighlighting is unnecessary. (Highlighting part of a single word was still relatively inefficient, but there was a variable named brute_highllighting controlling it, so I figured it was for a good reason.) However, if I move the mouse around more rapidly, I get a lot fewer mouse motion notifications, which means to some degree that we're doing redraws when the motion is slow enough that we can more likely afford it. It might be different over a network; I don't know. Any opinions?

Dec. 26, 2009

[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

patch: no size 0 images

by corvid＠lavabit.com

Just a little toy to ignore images of size 0. I also tried checking for display:none, but this made css very unhappy when it reached the noncss hints code later in the function. I didn't bother to try to fit it in with the neighboring code yet, since I don't know how well this will go over. So far, a bit of browsing has mostly shown me that there is a company at scorecardresearch.com that has infected a nontrivial portion of the web. (Of course we could still dig up the same-domain code and do something with that instead.)

Dec. 22, 2009

patch: vertical-align

by corvid＠lavabit.com

I just put up a new version. I had introduced a bug while cleaning up the code yesterday. I would've expected it to have broken everything quickly and horribly, but somehow I managed to run happily for hours before triggering the bug.

Dec. 22, 2009