- Dillo-dev - lists.mailman3.com

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