- Dillo-dev - lists.mailman3.com

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