September 2011 - Dillo-dev - lists.mailman3.com

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by corvid＠lavabit.com

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.

Sept. 22, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by rogutes＠googlemail.com

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

Sept. 22, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by obeythepenguin＠gmail.com

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

Sept. 22, 2011

release candidate for dillo-3.0.1 ready for testing

by abe＠deuxchevaux.org

Hi, On Thu, Sep 22, 2011 at 12:46:00PM -0300, Jorge Arellano Cid wrote: > > due to some important privacy fixes we decided to make a > > bugfix release. > > http://www.dillo.org/download/dillo-3.0.1-rc1.tar.bz2 > > is available for download now and want's to be tested. > > Please give it a try and report back. If everything goes smoothly, > > this will become dillo-3.0.1.tar.bz2 on Friday. > > Works OK here (Debian testing amd64). Haven't found time for testing the Debian package build yet, but plan do so later today, including corvid's patch for the redirect filtering issue. 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)

Sept. 22, 2011

release candidate for dillo-3.0.1 ready for testing

by jcid＠dillo.org

On Wed, Sep 21, 2011 at 07:48:31PM +0200, Johannes Hofmann wrote: > Hi, > > due to some important privacy fixes we decided to make a > bugfix release. > http://www.dillo.org/download/dillo-3.0.1-rc1.tar.bz2 > is available for download now and want's to be tested. > Please give it a try and report back. If everything goes smoothly, > this will become dillo-3.0.1.tar.bz2 on Friday. Works OK here (Debian testing amd64). -- Cheers Jorge.-

Sept. 22, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by corvid＠lavabit.com

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?

Sept. 22, 2011

Fwd: Bug#642391: dillo: sane default for http redirects [origin: debian-bts@unpopularminds.org]

by abe＠deuxchevaux.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)

Sept. 22, 2011

I hear there's some SSL unpleasantness going on...

by corvid＠lavabit.com

I wrote: > http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ more: http://www.mail-archive.com/openssl-dev at openssl.org/msg29718.html [Not totally on-topic for dillo, I know, but...]

Sept. 22, 2011

I hear there's some SSL unpleasantness going on...

by corvid＠lavabit.com

http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

Sept. 22, 2011

fltk linkage

by corvid＠lavabit.com

Do we still have a reason for telling people to stick with static linkage when building fltk?

Sept. 22, 2011