- Dillo-dev - lists.mailman3.com

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