- Dillo-dev - lists.mailman3.com

experimental patch: image loading options "same domain", "same host"

by joerg.sonnenberger＠web.de

On Tue, Sep 15, 2009 at 07:36:31PM +0200, Johannes Hofmann wrote: > Or would it be enough to not send cookies or HTTP authentication > data when loading such "unsafe" urls? Cookies have an explicit domain part if they are supposed to apply to more than the current host. HTTP authentication is URL specific or at most host specific. Joerg

Sept. 15, 2009

experimental patch: image loading options "same domain", "same host"

by Johannes.Hofmann＠gmx.de

On Tue, Sep 15, 2009 at 07:54:44PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Johannes Hofmann wrote: > > Hello, > > > > On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: > >> Jorge wrote: > >>> On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > >>>> I just put together a somewhat hacky patch to > >>>> add "same host" and "same domain" for image loading > >>>> from the tools button (or dillorc) > >>>> http://www.dillo.org/test/img_loading_options.patch > >>>> > >>>> I ran on it as long as I could tolerate images over > >>>> dialup (not long :), so here it is, and I will clean > >>>> it up if there is interest shown in getting it into > >>>> dillo. > >>> Good! I've had a similar idea for a long time. > >>> > >>> Since before the url filtering thread, I believe a simple > >>> blocking scheme based on same host/domain cuts most of the > >>> problem (bandwidth, privacy, tracking, web bugs etc). > >>> > >>> I'd suggest to add the filtering function in Capi. This is > >>> to make a_Capi_open_url() call a check function, e.g. > >>> > >>> if (Capi_filters_check_url(...) < 0) > >>> /* abort */ > >>> > >>> (you may add a ParentUrl DilloUrl to the webstructure). > >>> > >>> The point is to be able to reuse and improve the filter. > >>> (e.g. for CSS urls, sound streams, etc). > >>> > >>> > >>>> (I would probably want to change the names of the > >>>> dillorc choices for image loading, make the internal > >>>> value into an enum, look at the loadImages/autoload_image > >>>> code duplication, etc., etc... Oh, and look up how > >>>> to fix the tools menu width...) > >>> Something like: > >>> > >>> filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > >>> > >>> should be enough to get started. > >> I made a new one: > >> http://www.dillo.org/test/filtering.1.patch > >> > >> It doesn't have the menu stuff, so you have to > >> set the preference. > > > > Hm... With "same_host" many sites no longer work because they seem > > to use redirects (e.g. heise.de -> www.heise.de) > > And once I have entered heise.de, www.heise.de doesn't work either. > > > > Generally, is it really a problem if we load url's from other > > hosts/domains? > > > > Or would it be enough to not send cookies or HTTP authentication > > data when loading such "unsafe" urls? > If you're trying to protect dillo users from {X,C}SRF attacks then > stripping http authentication and cookies is a first step but it won't > protect users of intranet applications that rely on the users ip address > for authentication (think home routers with web interface). Ouch. Is there some general agreement on what web browsers should do in this regard?

Sept. 15, 2009

experimental patch: image loading options "same domain", "same host"

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: > Hello, > > On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: >> Jorge wrote: >>> On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: >>>> I just put together a somewhat hacky patch to >>>> add "same host" and "same domain" for image loading >>>> from the tools button (or dillorc) >>>> http://www.dillo.org/test/img_loading_options.patch >>>> >>>> I ran on it as long as I could tolerate images over >>>> dialup (not long :), so here it is, and I will clean >>>> it up if there is interest shown in getting it into >>>> dillo. >>> Good! I've had a similar idea for a long time. >>> >>> Since before the url filtering thread, I believe a simple >>> blocking scheme based on same host/domain cuts most of the >>> problem (bandwidth, privacy, tracking, web bugs etc). >>> >>> I'd suggest to add the filtering function in Capi. This is >>> to make a_Capi_open_url() call a check function, e.g. >>> >>> if (Capi_filters_check_url(...) < 0) >>> /* abort */ >>> >>> (you may add a ParentUrl DilloUrl to the webstructure). >>> >>> The point is to be able to reuse and improve the filter. >>> (e.g. for CSS urls, sound streams, etc). >>> >>> >>>> (I would probably want to change the names of the >>>> dillorc choices for image loading, make the internal >>>> value into an enum, look at the loadImages/autoload_image >>>> code duplication, etc., etc... Oh, and look up how >>>> to fix the tools menu width...) >>> Something like: >>> >>> filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} >>> >>> should be enough to get started. >> I made a new one: >> http://www.dillo.org/test/filtering.1.patch >> >> It doesn't have the menu stuff, so you have to >> set the preference. > > Hm... With "same_host" many sites no longer work because they seem > to use redirects (e.g. heise.de -> www.heise.de) > And once I have entered heise.de, www.heise.de doesn't work either. > > Generally, is it really a problem if we load url's from other > hosts/domains? > > Or would it be enough to not send cookies or HTTP authentication > data when loading such "unsafe" urls? If you're trying to protect dillo users from {X,C}SRF attacks then stripping http authentication and cookies is a first step but it won't protect users of intranet applications that rely on the users ip address for authentication (think home routers with web interface). Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqv1OQACgkQoPmwNWhsaZb+FACghNtaYfxcboMp1ovLmBZoy7LK MW4An08UfIfzcU2ktLqtmTLmfivzrECR =NrPe -----END PGP SIGNATURE-----

Sept. 15, 2009

experimental patch: image loading options "same domain", "same host"

by Johannes.Hofmann＠gmx.de

Hello, On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > > > I just put together a somewhat hacky patch to > > > add "same host" and "same domain" for image loading > > > from the tools button (or dillorc) > > > http://www.dillo.org/test/img_loading_options.patch > > > > > > I ran on it as long as I could tolerate images over > > > dialup (not long :), so here it is, and I will clean > > > it up if there is interest shown in getting it into > > > dillo. > > > > Good! I've had a similar idea for a long time. > > > > Since before the url filtering thread, I believe a simple > > blocking scheme based on same host/domain cuts most of the > > problem (bandwidth, privacy, tracking, web bugs etc). > > > > I'd suggest to add the filtering function in Capi. This is > > to make a_Capi_open_url() call a check function, e.g. > > > > if (Capi_filters_check_url(...) < 0) > > /* abort */ > > > > (you may add a ParentUrl DilloUrl to the webstructure). > > > > The point is to be able to reuse and improve the filter. > > (e.g. for CSS urls, sound streams, etc). > > > > > > > (I would probably want to change the names of the > > > dillorc choices for image loading, make the internal > > > value into an enum, look at the loadImages/autoload_image > > > code duplication, etc., etc... Oh, and look up how > > > to fix the tools menu width...) > > > > Something like: > > > > filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > > > > should be enough to get started. > > I made a new one: > http://www.dillo.org/test/filtering.1.patch > > It doesn't have the menu stuff, so you have to > set the preference. Hm... With "same_host" many sites no longer work because they seem to use redirects (e.g. heise.de -> www.heise.de) And once I have entered heise.de, www.heise.de doesn't work either. Generally, is it really a problem if we load url's from other hosts/domains? Or would it be enough to not send cookies or HTTP authentication data when loading such "unsafe" urls? Cheers, Johannes

Sept. 15, 2009

organizational boundaries [Re: [Dillo-dev] experimental patch: image loading options "same domain", "same host"]

by corvid＠lavabit.com

Looking around some more for information on how to deal with the fact that, e.g., www.dillo.org and hg.dillo.org are one thing and bbc.co.uk and theregister.co.uk aren't. (I'd like a better name for this than the "same domain" that I've been using.) And I discovered http://publicsuffix.org Perhaps someday we could let people stuff this big long list into .dillo/ if they want to.

Sept. 12, 2009

experimental patch: image loading options "same domain", "same host"

by corvid＠lavabit.com

Jorge wrote: > On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > > I just put together a somewhat hacky patch to > > add "same host" and "same domain" for image loading > > from the tools button (or dillorc) > > http://www.dillo.org/test/img_loading_options.patch > > > > I ran on it as long as I could tolerate images over > > dialup (not long :), so here it is, and I will clean > > it up if there is interest shown in getting it into > > dillo. > > Good! I've had a similar idea for a long time. > > Since before the url filtering thread, I believe a simple > blocking scheme based on same host/domain cuts most of the > problem (bandwidth, privacy, tracking, web bugs etc). > > I'd suggest to add the filtering function in Capi. This is > to make a_Capi_open_url() call a check function, e.g. > > if (Capi_filters_check_url(...) < 0) > /* abort */ > > (you may add a ParentUrl DilloUrl to the webstructure). > > The point is to be able to reuse and improve the filter. > (e.g. for CSS urls, sound streams, etc). > > > > (I would probably want to change the names of the > > dillorc choices for image loading, make the internal > > value into an enum, look at the loadImages/autoload_image > > code duplication, etc., etc... Oh, and look up how > > to fix the tools menu width...) > > Something like: > > filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > > should be enough to get started. I made a new one: http://www.dillo.org/test/filtering.1.patch It doesn't have the menu stuff, so you have to set the preference.

Sept. 12, 2009

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by Johannes.Hofmann＠gmx.de

On Thu, Sep 10, 2009 at 12:59:30PM -0400, Jorge Arellano Cid wrote: > Hi there, > > > On Sun, Aug 30, 2009 at 09:30:39AM -0400, Jorge Arellano Cid wrote: > > On Sat, Aug 29, 2009 at 01:06:36PM +0200, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > do you plan to answer this mail? > > > > Sorry I've been lost with other activities. > > > > > My point here is that we should > > > stick with fltk2 until there is an official release of fltk1.3. > > > > Yes. I agree. We went with unreleased FLTK2 and it has caused > > lots of problems (despite statical linking). > > > > > If there are license issues with fltk2 they should be handled > > > between debian and the fltk community. Of course we could try to > > > help. > > > > It looks like FLTK2 is quite stalled. Of course we can knock > > the door again. Maybe this is also a good time to ask for > > fltk1.3's timeline again. The last time, the optimistic release > > date was near the middle of 2009. > > > > > > > Date: Sat, 22 Aug 2009 18:40:03 +0200 > > > From: Devid Antonio Filoni <devidfil(a)gmail.com> > > > Subject: [Dillo-dev] Switch to fltk1.3? > > > To: dillo-dev(a)dillo.org > > > > > > Hi, > > > is possible to switch to fltk1.3? I sent a lot of emails to fltk > > > developers trying to get the license issue of fltk2 > > > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but > > > I still (after months of sent emails) haven't gotten a reply. dillo is > > > going to be removed from Debian and Ubuntu repositories because it > > > depends on removed packages and the newest dillo release cannot be > > > uploaded because fltk2 is not in the repositories and it cannot be > > > accepted due to the license issue. Is possible to switch to fltk1.3 or > > > to another toolkit please? > > > > > > Thanks, > > > Devid Antonio Filoni > > > > Hi Devid, > > > > We plan to switch to fltk1.3 soon. The point is to have a solid > > release date to start the port. When we started with fltk2 it was > > supposed to be released soon... :P > > > > I'm writing to the fltk1.3 team. Stay tuned. > > > Excellent news on this thread! > > > On Thu, Sep 10, 2009 at 09:17:52AM +0200, Matthias Melcher wrote: > > > > On 09.09.2009, at 17:35, Jorge Arellano Cid wrote: > > > >> Hi, > >> > >> Devid confirmed the proposed patch is OK! > > > > "Updated license to remain in the spirit of the original FLTK 2 license, > > but at the same time complying to Debian license requirements." > > > AFAIU this means the next FLTK2 snapshot will have the license > change, and distros can package it with no concerns. > > Details here: > > http://fltk.org/newsgroups.php?s4036+gfltk.commit+v4055+T0 > > To us, it means we can untroubledly keep our fltk2-based dillo > until fltk-1.3 sees an official release, and have it packaged by > the main distros, without any legal troubles. > > :-) Great! Thanks to everybody involved to get this resolved! Cheers, Johannes

Sept. 10, 2009

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by jcid＠dillo.org

Hi there, On Sun, Aug 30, 2009 at 09:30:39AM -0400, Jorge Arellano Cid wrote: > On Sat, Aug 29, 2009 at 01:06:36PM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > > > do you plan to answer this mail? > > Sorry I've been lost with other activities. > > > My point here is that we should > > stick with fltk2 until there is an official release of fltk1.3. > > Yes. I agree. We went with unreleased FLTK2 and it has caused > lots of problems (despite statical linking). > > > If there are license issues with fltk2 they should be handled > > between debian and the fltk community. Of course we could try to > > help. > > It looks like FLTK2 is quite stalled. Of course we can knock > the door again. Maybe this is also a good time to ask for > fltk1.3's timeline again. The last time, the optimistic release > date was near the middle of 2009. > > > > Date: Sat, 22 Aug 2009 18:40:03 +0200 > > From: Devid Antonio Filoni <devidfil(a)gmail.com> > > Subject: [Dillo-dev] Switch to fltk1.3? > > To: dillo-dev(a)dillo.org > > > > Hi, > > is possible to switch to fltk1.3? I sent a lot of emails to fltk > > developers trying to get the license issue of fltk2 > > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but > > I still (after months of sent emails) haven't gotten a reply. dillo is > > going to be removed from Debian and Ubuntu repositories because it > > depends on removed packages and the newest dillo release cannot be > > uploaded because fltk2 is not in the repositories and it cannot be > > accepted due to the license issue. Is possible to switch to fltk1.3 or > > to another toolkit please? > > > > Thanks, > > Devid Antonio Filoni > > Hi Devid, > > We plan to switch to fltk1.3 soon. The point is to have a solid > release date to start the port. When we started with fltk2 it was > supposed to be released soon... :P > > I'm writing to the fltk1.3 team. Stay tuned. Excellent news on this thread! On Thu, Sep 10, 2009 at 09:17:52AM +0200, Matthias Melcher wrote: > > On 09.09.2009, at 17:35, Jorge Arellano Cid wrote: > >> Hi, >> >> Devid confirmed the proposed patch is OK! > > "Updated license to remain in the spirit of the original FLTK 2 license, > but at the same time complying to Debian license requirements." AFAIU this means the next FLTK2 snapshot will have the license change, and distros can package it with no concerns. Details here: http://fltk.org/newsgroups.php?s4036+gfltk.commit+v4055+T0 To us, it means we can untroubledly keep our fltk2-based dillo until fltk-1.3 sees an official release, and have it packaged by the main distros, without any legal troubles. :-) -- Cheers Jorge.-

Sept. 10, 2009

experimental patch: image loading options "same domain", "same host"

by jcid＠dillo.org

On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > I just put together a somewhat hacky patch to > add "same host" and "same domain" for image loading > from the tools button (or dillorc) > http://www.dillo.org/test/img_loading_options.patch > > I ran on it as long as I could tolerate images over > dialup (not long :), so here it is, and I will clean > it up if there is interest shown in getting it into > dillo. Good! I've had a similar idea for a long time. Since before the url filtering thread, I believe a simple blocking scheme based on same host/domain cuts most of the problem (bandwidth, privacy, tracking, web bugs etc). I'd suggest to add the filtering function in Capi. This is to make a_Capi_open_url() call a check function, e.g. if (Capi_filters_check_url(...) < 0) /* abort */ (you may add a ParentUrl DilloUrl to the webstructure). The point is to be able to reuse and improve the filter. (e.g. for CSS urls, sound streams, etc). > (I would probably want to change the names of the > dillorc choices for image loading, make the internal > value into an enum, look at the loadImages/autoload_image > code duplication, etc., etc... Oh, and look up how > to fix the tools menu width...) Something like: filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} should be enough to get started. -- Cheers Jorge.-

Sept. 7, 2009

experimental patch: image loading options "same domain", "same host"

by corvid＠lavabit.com

I just put together a somewhat hacky patch to add "same host" and "same domain" for image loading from the tools button (or dillorc) http://www.dillo.org/test/img_loading_options.patch I ran on it as long as I could tolerate images over dialup (not long :), so here it is, and I will clean it up if there is interest shown in getting it into dillo. (I would probably want to change the names of the dillorc choices for image loading, make the internal value into an enum, look at the loadImages/autoload_image code duplication, etc., etc... Oh, and look up how to fix the tools menu width...)

Sept. 7, 2009