From corvid at lavabit.com Fri Jan 1 00:18:06 2010 From: corvid at lavabit.com (corvid) Date: Fri Jan 1 00:22:22 2010 Subject: [Dillo-dev] patch: .domain cookies from/to domain In-Reply-To: <20091229134413.GA2768@local.gobigwest.com> References: <20091228012141.GC2791@local.gobigwest.com> <20091229123318.GL13066@dillo.org> <20091229134413.GA2768@local.gobigwest.com> Message-ID: <20091231231806.GB2844@local.gobigwest.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? From Johannes.Hofmann at gmx.de Fri Jan 1 20:04:00 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Fri Jan 1 20:06:33 2010 Subject: [Dillo-dev] [bug]: CSS - attack of the mega-images In-Reply-To: <20091230162304.GB3516@omphalos.singularity> References: <20091230162304.GB3516@omphalos.singularity> Message-ID: <20100101190400.GA999@blob.baaderstrasse.com> 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-new-tools.html > > 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 From Johannes.Hofmann at gmx.de Fri Jan 1 20:14:19 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Fri Jan 1 20:16:50 2010 Subject: [Dillo-dev] patch: .domain cookies from/to domain In-Reply-To: <20091231231806.GB2844@local.gobigwest.com> References: <20091228012141.GC2791@local.gobigwest.com> <20091229123318.GL13066@dillo.org> <20091229134413.GA2768@local.gobigwest.com> <20091231231806.GB2844@local.gobigwest.com> Message-ID: <20100101191419.GA1062@blob.baaderstrasse.com> 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. From corvid at lavabit.com Fri Jan 1 20:25:27 2010 From: corvid at lavabit.com (corvid) Date: Fri Jan 1 20:29:39 2010 Subject: [Dillo-dev] patch: .domain cookies from/to domain In-Reply-To: <20100101191419.GA1062@blob.baaderstrasse.com> References: <20091228012141.GC2791@local.gobigwest.com> <20091229123318.GL13066@dillo.org> <20091229134413.GA2768@local.gobigwest.com> <20091231231806.GB2844@local.gobigwest.com> <20100101191419.GA1062@blob.baaderstrasse.com> Message-ID: <20100101192526.GA2748@local.gobigwest.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. From Johannes.Hofmann at gmx.de Sat Jan 2 11:54:49 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Jan 2 11:57:32 2010 Subject: [Dillo-dev] web bug save? In-Reply-To: <20091231121849.GA947@blob.baaderstrasse.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> <20091231121849.GA947@blob.baaderstrasse.com> Message-ID: <20100102105449.GB925@blob.baaderstrasse.com> 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.html > > > > > > > > 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 From corvid at lavabit.com Sat Jan 2 16:43:48 2010 From: corvid at lavabit.com (corvid) Date: Sat Jan 2 16:47:59 2010 Subject: [Dillo-dev] web bug save? In-Reply-To: <20100102105449.GB925@blob.baaderstrasse.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> <20091231121849.GA947@blob.baaderstrasse.com> <20100102105449.GB925@blob.baaderstrasse.com> Message-ID: <20100102154348.GA2726@local.gobigwest.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.html > > > > > > > > > > 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. From Johannes.Hofmann at gmx.de Sat Jan 2 17:02:44 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Jan 2 17:05:16 2010 Subject: [Dillo-dev] web bug save? In-Reply-To: <20100102154348.GA2726@local.gobigwest.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> <20091231121849.GA947@blob.baaderstrasse.com> <20100102105449.GB925@blob.baaderstrasse.com> <20100102154348.GA2726@local.gobigwest.com> Message-ID: <20100102160244.GA929@blob.baaderstrasse.com> 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.html > > > > > > > > > > > > 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. From corvid at lavabit.com Sat Jan 2 17:19:26 2010 From: corvid at lavabit.com (corvid) Date: Sat Jan 2 17:23:36 2010 Subject: [Dillo-dev] web bug save? In-Reply-To: <20100102160244.GA929@blob.baaderstrasse.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> <20091231121849.GA947@blob.baaderstrasse.com> <20100102105449.GB925@blob.baaderstrasse.com> <20100102154348.GA2726@local.gobigwest.com> <20100102160244.GA929@blob.baaderstrasse.com> Message-ID: <20100102161926.GB2726@local.gobigwest.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.html > > > > > > > > > > > > > > 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. From Johannes.Hofmann at gmx.de Sat Jan 2 17:34:07 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Jan 2 17:36:38 2010 Subject: [Dillo-dev] web bug save? In-Reply-To: <20100102161926.GB2726@local.gobigwest.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> <20091231121849.GA947@blob.baaderstrasse.com> <20100102105449.GB925@blob.baaderstrasse.com> <20100102154348.GA2726@local.gobigwest.com> <20100102160244.GA929@blob.baaderstrasse.com> <20100102161926.GB2726@local.gobigwest.com> Message-ID: <20100102163407.GA1200@blob.baaderstrasse.com> 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.html > > > > > > > > > > > > > > > > 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. From corvid at lavabit.com Sat Jan 2 17:47:17 2010 From: corvid at lavabit.com (corvid) Date: Sat Jan 2 17:51:28 2010 Subject: [Dillo-dev] patch: .domain cookies from/to domain In-Reply-To: <20100101192526.GA2748@local.gobigwest.com> References: <20091228012141.GC2791@local.gobigwest.com> <20091229123318.GL13066@dillo.org> <20091229134413.GA2768@local.gobigwest.com> <20091231231806.GB2844@local.gobigwest.com> <20100101191419.GA1062@blob.baaderstrasse.com> <20100101192526.GA2748@local.gobigwest.com> Message-ID: <20100102164717.GC2726@local.gobigwest.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. From corvid at lavabit.com Sat Jan 2 18:07:14 2010 From: corvid at lavabit.com (corvid) Date: Sat Jan 2 18:11:25 2010 Subject: [Dillo-dev] web bug save? In-Reply-To: <20100102163407.GA1200@blob.baaderstrasse.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> <20091231121849.GA947@blob.baaderstrasse.com> <20100102105449.GB925@blob.baaderstrasse.com> <20100102154348.GA2726@local.gobigwest.com> <20100102160244.GA929@blob.baaderstrasse.com> <20100102161926.GB2726@local.gobigwest.com> <20100102163407.GA1200@blob.baaderstrasse.com> Message-ID: <20100102170714.GE2726@local.gobigwest.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.html > > > > > > > > > > > > > > > > > > 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? From Johannes.Hofmann at gmx.de Sat Jan 2 18:15:33 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Jan 2 18:18:03 2010 Subject: [Dillo-dev] web bug save? In-Reply-To: <20100102170714.GE2726@local.gobigwest.com> References: <4B375499.8000206@arcor.de> <20091228020146.GD2791@local.gobigwest.com> <20091231032736.GQ13066@dillo.org> <20091231121849.GA947@blob.baaderstrasse.com> <20100102105449.GB925@blob.baaderstrasse.com> <20100102154348.GA2726@local.gobigwest.com> <20100102160244.GA929@blob.baaderstrasse.com> <20100102161926.GB2726@local.gobigwest.com> <20100102163407.GA1200@blob.baaderstrasse.com> <20100102170714.GE2726@local.gobigwest.com> Message-ID: <20100102171533.GA1662@blob.baaderstrasse.com> 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.html > > > > > > > > > > > > > > > > > > > > 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... From onepoint at starurchin.org Sat Jan 2 19:35:48 2010 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Jan 2 19:36:44 2010 Subject: [Dillo-dev] patch: handle cookie time overflow In-Reply-To: <20091230193219.GB2743@local.gobigwest.com> References: <20091230193219.GB2743@local.gobigwest.com> Message-ID: <20100102183548.GA3475@omphalos.singularity> 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 From corvid at lavabit.com Sat Jan 2 22:02:47 2010 From: corvid at lavabit.com (corvid) Date: Sat Jan 2 22:06:57 2010 Subject: [Dillo-dev] patch: handle cookie time overflow In-Reply-To: <20100102183548.GA3475@omphalos.singularity> References: <20091230193219.GB2743@local.gobigwest.com> <20100102183548.GA3475@omphalos.singularity> Message-ID: <20100102210247.GH2726@local.gobigwest.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. From corvid at lavabit.com Mon Jan 4 02:19:37 2010 From: corvid at lavabit.com (corvid) Date: Mon Jan 4 02:23:52 2010 Subject: [Dillo-dev] table/cursor oddity Message-ID: <20100104011937.GC2833@local.gobigwest.com> A little bug that I just stumbled upon.
onetwothree
row
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. From Johannes.Hofmann at gmx.de Tue Jan 5 11:52:19 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Jan 5 11:54:56 2010 Subject: [Dillo-dev] table/cursor oddity In-Reply-To: <20100104011937.GC2833@local.gobigwest.com> References: <20100104011937.GC2833@local.gobigwest.com> Message-ID: <20100105105218.GA978@blob.baaderstrasse.com> On Mon, Jan 04, 2010 at 01:19:37AM +0000, corvid wrote: > A little bug that I just stumbled upon. > > >
onetwothree >
row >
> > 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.
foo
dillo creates a textblock widget for the
, 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
, 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 foo work, where 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 From rmarathe at i-rode.com Tue Jan 5 13:10:42 2010 From: rmarathe at i-rode.com (Rajesh Marathe) Date: Tue Jan 5 13:12:02 2010 Subject: [Dillo-dev] Query on Dillo browser supporting "frames" Message-ID: <1262693442.3368.9.camel@localhost.localdomain> Hi, Will Dillo2 browser support "Frames" in future ? IF yes, what is the time frame for that release ? regards, Rajesh Marathe. From iveqy at iveqy.com Tue Jan 5 16:02:23 2010 From: iveqy at iveqy.com (Fredrik Gustafsson) Date: Tue Jan 5 16:05:12 2010 Subject: [Dillo-dev] Javascript Message-ID: <20100105150223.GA29541@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 From corvid at lavabit.com Tue Jan 5 16:16:11 2010 From: corvid at lavabit.com (corvid) Date: Tue Jan 5 16:17:11 2010 Subject: [Dillo-dev] Query on Dillo browser supporting "frames" In-Reply-To: <1262693442.3368.9.camel@localhost.localdomain> References: <1262693442.3368.9.camel@localhost.localdomain> Message-ID: <20100105151610.GA2771@local.gobigwest.com> Rajesh wrote: > Will Dillo2 browser support "Frames" in future ? IF yes, what is the > time frame for that release ? I'm not aware of any particular plans to work on it, but of course I'm sure a good patch that integrates well with the existing code would be gladly accepted... From corvid at lavabit.com Tue Jan 5 16:36:24 2010 From: corvid at lavabit.com (corvid) Date: Tue Jan 5 16:37:25 2010 Subject: [Dillo-dev] css :visited and security Message-ID: <20100105153623.GB2771@local.gobigwest.com> The other day, I saw another of those pages about using :visited and display in order to allow others to learn whether the user has visited a page. (I remember Johannes pointing to a page about this last year, too.) I wonder whether it would be sensible to have a dillorc option defaulting to NO for whether to use :visited. From Johannes.Hofmann at gmx.de Tue Jan 5 16:42:23 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Jan 5 16:44:56 2010 Subject: [Dillo-dev] css :visited and security In-Reply-To: <20100105153623.GB2771@local.gobigwest.com> References: <20100105153623.GB2771@local.gobigwest.com> Message-ID: <20100105154223.GA3945@blob.baaderstrasse.com> On Tue, Jan 05, 2010 at 03:36:24PM +0000, corvid wrote: > The other day, I saw another of those pages about using :visited and > display in order to allow others to learn whether the user has visited > a page. (I remember Johannes pointing to a page about this last year, too.) > > I wonder whether it would be sensible to have a dillorc option defaulting > to NO for whether to use :visited. Yes, that sounds good. We should distinguish between remote / embedded CSS and user agent and user stylesheet though. For the latter two we don't need any restrictions. We might also do some other restrictions on remote CSS in the future, e.g. possible dillo specific extensions should also be only accessible via the user agent and user stylesheet. From Johannes.Hofmann at gmx.de Tue Jan 5 20:31:55 2010 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Jan 5 20:34:53 2010 Subject: [Dillo-dev] table/cursor oddity In-Reply-To: <20100104011937.GC2833@local.gobigwest.com> References: <20100104011937.GC2833@local.gobigwest.com> Message-ID: <20100105193155.GA6297@blob.baaderstrasse.com> On Mon, Jan 04, 2010 at 01:19:37AM +0000, corvid wrote: > A little bug that I just stumbled upon. > > >
onetwothree >
row >
> > 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. Should be fixed now. Turned out to be a stupid bug in style.cc. From corvid at lavabit.com Tue Jan 5 22:12:39 2010 From: corvid at lavabit.com (corvid) Date: Tue Jan 5 22:13:38 2010 Subject: [Dillo-dev] want to test some experimental cookies code? Message-ID: <20100105211239.GD2771@local.gobigwest.com> In recent days, I've been making a version of cookies dpi that follows the current cookies draft of the http state working group. I haven't tested it exhaustively yet, but if anyone who uses cookies wants to try it and watch the msgs and so on, let me know. As for how much validity or meaningfulness this draft has, let's see... - They've made the decision to describe the way things currently behave, having learned from the bitter experience of others who made RFC 2109 and RFC 2965*. In 2010, no one has any way to be King of Cookies. They write testcases and try all of the major browsers and decide what they want to write down in their spec when there are differences. - On their mailing list, from the user agents, they have an opera guy, the curl guy, and someone related to firefox, although I didn't take any notice of whether he has a position of authority in firefox or not. - Of course there will be changes. Smallish, I think. A cookie set without an explicit domain goes only to that domain. A cookie with a domain attribute is sent to that domain and any subdomain. A .domain attr cookie can go to domain. As for how to decide to reject cookies for, e.g., .co.uk, I don't think they're ever going to say too much. A cookie can be set for any path, regardless of the url path of the page setting it. Paths are matched when selecting cookies to return, though. Path-matching does work by slashes instead of simple prefixes. An http page can set a secure cookie (just like currently). An example of the little things that may change are that a cookie that is just VALUE instead of NAME=VALUE is currently allowed, but it's not decided for good yet. There are corner cases such as this that maybe they could make illegal without rendering themselves irrelevant. * To be precise, the main author of the RFCs has written that it was at least initially reasonable to think that what they were putting together in rfc 2109 would be adopted by user agents. From rmarathe11 at gmail.com Thu Jan 7 06:03:07 2010 From: rmarathe11 at gmail.com (Rajesh Marathe) Date: Thu Jan 7 06:04:02 2010 Subject: [Dillo-dev] Query on interfacing IMX27 keyboard with Dillo browser. Message-ID: Hello, I am using Dillo as a browser on IMX27 system. (working with latest CVS LTIB code). I wanted to interface imx27 Keyboard with the browser so that the UP/DOWN/etc. keys work on the browser pages. I have been using this with Touchscreen and I wanted to know if the Keyboard can be interfaced too. Presently, I saw that on any Linux installation with Dillo on it, only mouse works as mouse can be moved from one link to other link. But keyboard was not working. I would want to make the Keyboard UP/DOWN arrows take me up and down the links on a page in the Dillo browser. Is it possible to do this ? regards, Rajesh Marathe. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20100107/f75cc604/attachment.html From corvid at lavabit.com Thu Jan 7 16:48:36 2010 From: corvid at lavabit.com (corvid) Date: Thu Jan 7 16:49:37 2010 Subject: [Dillo-dev] Query on interfacing IMX27 keyboard with Dillo browser. In-Reply-To: References: Message-ID: <20100107154836.GA2730@local.gobigwest.com> Rajesh wrote: > I am using Dillo as a browser on IMX27 system. (working with > latest CVS LTIB code). I wanted to interface imx27 > Keyboard with the browser so that the UP/DOWN/etc. keys work on the > browser pages. > I have been using this with Touchscreen and I wanted to know if the > Keyboard can be interfaced too. > > Presently, I saw that on any Linux installation with Dillo on it, only mouse > works as mouse can be moved from one link to other link. But keyboard was > not working. I would want to make the Keyboard UP/DOWN arrows take me up and > down the links on a page in the Dillo browser. Is it possible to do this ? Not currently. I've sort of idly considered what it might take to be able to tab between the various links and form controls, but was stopped by "Hmm, how would you know to break out of a