Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]
Hi, this bug report came in for dillo 3.0 in Debian Unstable/Testing, see also http://bugs.debian.org/642391 See below for my thoughts. ----- Forwarded message from The Don Lachlan <debian-bts at unpopularminds.org> ----- From: The Don Lachlan <debian-bts at unpopularminds.org> Date: Thu, 22 Sep 2011 02:07:15 -0400 Subject: Bug#642391: dillo: sane default for http redirects To: Debian Bug Tracking System <submit at bugs.debian.org> User-Agent: Mutt/1.5.21 (2010-09-15) Package: dillo Version: 3.0-1 Severity: important Dear Maintainer, By default, Dillo 3.0 does not follow HTTP redirects between second level domains (foo.com -> bar.com), which breaks URL shorteners and many web sites. This is controlled by the configuration option "filter_auto_requests" and defaults to "same_domain". I've attached two patches. The first modifies the source to "allow_all" by default and the commented entry in the rc file; the second modifies the rc file to "allow_all" by default. The first patch is preferable so that 1) the source code defaults match the shipped rc file 2) users who have an existing ~/.dillo/dillorc (and ignore the global dillorc) will receive the proper default of "allow_all" if they lack a "filter_auto_requests" entry -Lachlan (this is a resend, it left my MTA but never reached the bug logs) -- System Information: [...] --- dillo-3.0/dillorc 2011-09-21 15:38:16.664618360 -0400 +++ dillo-3.0/dillorc 2011-09-21 18:21:26.000000000 -0400 @@ -31,7 +31,7 @@ # allow_all # same_domain : Permit www.example.org to load an image from img.example.org, # but not from the unrelated ad.doubleclick.net. -#filter_auto_requests=same_domain +#filter_auto_requests=allow_all # Change the buffering scheme for drawing # 0 no double buffering - useful for debugging --- dillo-3.0/src/prefs.c 2011-09-21 18:52:17.000000000 -0400 +++ dillo-3.0/src/prefs.c 2011-09-21 18:52:54.000000000 -0400 @@ -40,7 +40,7 @@ prefs.buffered_drawing = 1; prefs.contrast_visited_color = TRUE; prefs.enterpress_forces_submit = FALSE; - prefs.filter_auto_requests = PREFS_FILTER_SAME_DOMAIN; + prefs.filter_auto_requests = PREFS_FILTER_ALLOW_ALL; prefs.focus_new_tab = TRUE; prefs.font_cursive = dStrdup(PREFS_FONT_CURSIVE); prefs.font_factor = 1.0; --- dillo/dillorc 2011-09-21 15:38:16.664618360 -0400 +++ dillo/dillorc 2011-09-21 15:38:42.000000000 -0400 @@ -31,7 +31,7 @@ # allow_all # same_domain : Permit www.example.org to load an image from img.example.org, # but not from the unrelated ad.doubleclick.net. -#filter_auto_requests=same_domain +filter_auto_requests=allow_all # Change the buffering scheme for drawing # 0 no double buffering - useful for debugging ----- End forwarded message ----- Until now I noticed the effects of filter_auto_requests just for images and was quite happy with it. But with images you can click on them and they will be loaded. This does not seem to work for cross-domain redirects. And as annoying as URL shorteners are, I usually do like to follow those redirects. Is it possible to separate the settings for images and redirects? Or is it possible to allow those redirect on a case-by-case base? One easy way to do so would to display the content of the redirect page which usually contains a link to the redirect target. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)
Axel wrote:
One easy way to do so would to display the content of the redirect page which usually contains a link to the redirect target.
That's an interesting idea! I should be sleeping, but how does the attached work for you?
Hi corvid, On Thu, Sep 22, 2011 at 01:13:55PM +0000, corvid wrote:
Axel wrote:
One easy way to do so would to display the content of the redirect page which usually contains a link to the redirect target.
That's an interesting idea! I should be sleeping, but
Hehe.
how does the attached work for you?
Exactly as I expected, i.e. fine, only that way less redirection services than expected include links in the 30x page itself. I just clicked through the first 10 pages of my identi.ca home feed and checked all redirection services I found in use plus a standard Apache redirect (Apache 2.2.29 as on Debianb Lenny): OK: Apache 2.2.9 (tested http://blosxom.net/) NO CONTENTS: is.gd (tested: http://is.gd/dLoEoo) OK: identi.ca/url (tested: http://identi.ca/url/53842451) NO CONTENTS: ub0.cc (tested: http://ub0.cc/xm/97) OK: deb.li (tested: http://deb.li/7s0l) NO LINK: ur1.ca (tested: http://ur1.ca/54dz0) NO CONTENTS: lallus.net (tested: http://lallus.net/852) NO CONTENTS: t.co (tested: http://t.co/viemv5qx) OK: goo.gl (tested: http://goo.gl/dzbq8) OK: feedproxy.google.com (tested: http://feedproxy.google.com/~r/OmMalik/~3/Co-kep24E68/) OK: bit.ly (tested: http://bit.ly/njgxiQ) NO CONTENTS: tinyurl.com (tested: http://tinyurl.com/3fg22d8) So I recommend to add the patch anyway, as it makes things way better even if someone wants to filter these redirects, but there's probably need for an at least a little bit more fine grained redirect/image blocking configuration. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)
Axel wrote:
there's probably need for an at least a little bit more fine grained redirect/image blocking configuration.
Here's some code that experiments with letting you list a bunch of filter_auto_requests options in dillorc (same_domain, allow_redirect, allow_image, allow_stylesheet, allow_all), somewhat similar to search_url. Or we could turn it into three boolean preferences. Whatever.
On Thu, 22 Sep 2011 08:18:21 -0400, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi,
this bug report came in for dillo 3.0 in Debian Unstable/Testing, see also http://bugs.debian.org/642391
See below for my thoughts.
... snip...
Until now I noticed the effects of filter_auto_requests just for images and was quite happy with it. But with images you can click on them and they will be loaded. This does not seem to work for cross-domain redirects. And as annoying as URL shorteners are, I usually do like to follow those redirects.
Is it possible to separate the settings for images and redirects? Or is it possible to allow those redirect on a case-by-case base?
One easy way to do so would to display the content of the redirect page which usually contains a link to the redirect target.
Kind regards, Axel
You know, this may be the first time I've agreed with one of Debian's patches. Dillo's default setting breaks many major web sites, including Wikipedia, Google Images, and every photo hosting site. This hurts Dillo's usability, particularly for new and/or less technically knowledgeable users. The average user isn't going to stop and think "oh, these images aren't loading because they're hosted on a different domain"; he's going to think "Dillo is broken because this site doesn't work," and probably switch to a different browser. (Keep in mind, dillo-dev probably represents a small minority of users -- those who are both technically knowledgeable and interested enough to subscribe and participate. But good software can't be designed just for the minority. Firefox isn't popular only for its technical merits, but also because it's easy for people to install and use.) Granted, I like Axel's suggestions -- allow more fine-grained control, and display redirect links. They're much better than the current all-or-nothing approach. I'm just saying while we're at it, maybe we should also reconsider Dillo's IMHO overly paranoid defaults. A lot more people would probably stick with Dillo if it just behaved like they expect it to. ~Benjamin
Benjamin Johnson (2011-09-22 14:47):
On Thu, 22 Sep 2011 08:18:21 -0400, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi,
this bug report came in for dillo 3.0 in Debian Unstable/Testing, see also http://bugs.debian.org/642391
See below for my thoughts.
... snip...
Until now I noticed the effects of filter_auto_requests just for images and was quite happy with it. But with images you can click on them and they will be loaded. This does not seem to work for cross-domain redirects. And as annoying as URL shorteners are, I usually do like to follow those redirects.
Is it possible to separate the settings for images and redirects? Or is it possible to allow those redirect on a case-by-case base?
One easy way to do so would to display the content of the redirect page which usually contains a link to the redirect target.
Kind regards, Axel
You know, this may be the first time I've agreed with one of Debian's patches. Dillo's default setting breaks many major web sites, including Wikipedia, Google Images, and every photo hosting site. This hurts Dillo's usability, particularly for new and/or less technically knowledgeable users. The average user isn't going to stop and think "oh, these images aren't loading because they're hosted on a different domain"; he's going to think "Dillo is broken because this site doesn't work," and probably switch to a different browser.
(Keep in mind, dillo-dev probably represents a small minority of users -- those who are both technically knowledgeable and interested enough to subscribe and participate. But good software can't be designed just for the minority. Firefox isn't popular only for its technical merits, but also because it's easy for people to install and use.)
Granted, I like Axel's suggestions -- allow more fine-grained control, and display redirect links. They're much better than the current all-or-nothing approach. I'm just saying while we're at it, maybe we should also reconsider Dillo's IMHO overly paranoid defaults. A lot more people would probably stick with Dillo if it just behaved like they expect it to.
I, for example, use Firefox with 'permissions.default.image=1', which makes it show the link to 3rd party images instead of loading them. The only place where I really missed images was Wikipedia, for which I added an exception through an add-on. -- -- Rogut?s Sparnuotos
Rogut?s wrote:
Benjamin Johnson (2011-09-22 14:47):
On Thu, 22 Sep 2011 08:18:21 -0400, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi,
this bug report came in for dillo 3.0 in Debian Unstable/Testing, see also http://bugs.debian.org/642391
See below for my thoughts.
... snip...
Until now I noticed the effects of filter_auto_requests just for images and was quite happy with it. But with images you can click on them and they will be loaded. This does not seem to work for cross-domain redirects. And as annoying as URL shorteners are, I usually do like to follow those redirects.
Is it possible to separate the settings for images and redirects? Or is it possible to allow those redirect on a case-by-case base?
One easy way to do so would to display the content of the redirect page which usually contains a link to the redirect target.
Kind regards, Axel
You know, this may be the first time I've agreed with one of Debian's patches. Dillo's default setting breaks many major web sites, including Wikipedia, Google Images, and every photo hosting site. This hurts Dillo's usability, particularly for new and/or less technically knowledgeable users. The average user isn't going to stop and think "oh, these images aren't loading because they're hosted on a different domain"; he's going to think "Dillo is broken because this site doesn't work," and probably switch to a different browser.
(Keep in mind, dillo-dev probably represents a small minority of users -- those who are both technically knowledgeable and interested enough to subscribe and participate. But good software can't be designed just for the minority. Firefox isn't popular only for its technical merits, but also because it's easy for people to install and use.)
Granted, I like Axel's suggestions -- allow more fine-grained control, and display redirect links. They're much better than the current all-or-nothing approach. I'm just saying while we're at it, maybe we should also reconsider Dillo's IMHO overly paranoid defaults. A lot more people would probably stick with Dillo if it just behaved like they expect it to.
I, for example, use Firefox with 'permissions.default.image=1', which makes it show the link to 3rd party images instead of loading them. The only place where I really missed images was Wikipedia, for which I added an exception through an add-on.
Once upon a time, back before the filter era, I experimented with something more fine-grained that understood adblock syntax http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-December/005573.html but it wasn't received very positively -- I think due to not being simple enough.
participants (4)
-
abe＠deuxchevaux.org -
corvid＠lavabit.com -
obeythepenguin＠gmail.com -
rogutes＠googlemail.com