experimental patch: image loading options "same domain", "same host"
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...)
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.-
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.
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.
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: 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-----
On Tue, Sep 15, 2009 at 07:54:44PM +0200, Justus Winter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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
Johannes Hofmann wrote: 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?
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
On Tue, Sep 15, 2009 at 08:08:06PM +0200, Joerg Sonnenberger wrote:
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.
Not sure if that helps here. If the user has a cookie set that authenticates him at www.hisbank.com and a page on www.badguy.com contains an image with the url http://www.hisbank.com?transfer_to_badguy=100000 the browser would happily send the cookie to www.hisbank.com to authenticate him. Of course www.hisbank.com should have additional checks installed that prevent such misuse. Cheers, Johannes
Johannes wrote:
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.
I have also found same_host not to have any value.
Generally, is it really a problem if we load url's from other hosts/domains?
Sites have no right to redirect me to unrelated sites, and sites have no right to subject me to images from unrelated sites.
Or would it be enough to not send cookies or HTTP authentication data when loading such "unsafe" urls?
On Tue, Sep 15, 2009 at 07:21:32PM +0000, corvid wrote:
Johannes wrote:
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.
I have also found same_host not to have any value.
Generally, is it really a problem if we load url's from other hosts/domains?
Sites have no right to redirect me to unrelated sites, and sites have no right to subject me to images from unrelated sites.
I tend to agree. With your patch I noticed that many popular sites contain 1x1 images from some statistics gathering companies. However I think these images do not really leak additional information as the sites could report your IP address behind the scenes as well. Cheers, Johannes
Johannes wrote:
On Tue, Sep 15, 2009 at 07:21:32PM +0000, corvid wrote:
Johannes wrote:
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.
I have also found same_host not to have any value.
Generally, is it really a problem if we load url's from other hosts/domains?
Sites have no right to redirect me to unrelated sites, and sites have no right to subject me to images from unrelated sites.
I tend to agree. With your patch I noticed that many popular sites contain 1x1 images from some statistics gathering companies. However I think these images do not really leak additional information as the sites could report your IP address behind the scenes as well.
I think the term "user agent" for a browser is very apt. These companies ask dillo to serve as an accomplice as they violate the user's right to privacy.
participants (5)
-
4winter＠informatik.uni-hamburg.de -
corvid＠lavabit.com -
jcid＠dillo.org -
joerg.sonnenberger＠web.de -
Johannes.Hofmann＠gmx.de