- Dillo-dev - lists.mailman3.com

Re: [PATCH] Remove deprecated DNT header

by Rodrigo Arias

Hi, On Tue, Apr 14, 2026 at 09:59:56PM +0200, Rodrigo Arias wrote: >I reached out to the EFF to ask if they still recommend the DNT header, >and see if they can provide more data or details as to why. The EFF seem to still encourage it, at least for the Privacy Badger extension: >From Privacy Badger's perspective, the benefits appear to continue to >outweigh the costs. Here is the relevant issue: > > https://github.com/EFForg/privacybadger/issues/2950 Best, Rodrigo.

April 14, 2026

Re: [PATCH] Remove deprecated DNT header

by Rodrigo Arias

Hi, On Tue, Apr 14, 2026 at 08:11:14AM +0000, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> >The 'Do Not Track' header has been abandoned by W3C and most major >> >browsers. Very few advertising companies actually supported DNT. >> >> Yes, that was the case already when it was merged in 2013, but there was >> the idea that it won't cause harm: >> >> commit b2be12828a20c54b325a4f31ca62959ea12f642b >> Author: corvid <corvid(a)dillo.org> >> Date: Sun Sep 15 18:48:13 2013 +0000 >> >> DNT will at least do no harm >> >> The whole situation is a manifestation of corporate rule, but >> - it seems that the EU has some data protection laws that could make it >> worth something in principle there. >> - some large corporations have been shamed into claiming that they will do >> a tiny bit of something based on the header value. > >At this point I don't think it's reasonable to expect that any >corporation will honor it "out of the goodness of their hearts". > >The industry has moved on to Sec-GPC, which appears to at least have >some legal backing to it. Maybe it makes more sense to simply change >the DNT header to Sec-GPC? > >https://en.wikipedia.org/wiki/Global_Privacy_Control I think sending the Sec-GPC header by default may be good idea. I suggest adding these two options to control the headers (NO = no header is sent): http_dnt=YES http_sec_gpc=YES However, I don't want to introduce any new features or changes in the HTTP headers for this release as we are already closing the 3.3.0. I reached out to the EFF to ask if they still recommend the DNT header, and see if they can provide more data or details as to why. If there is enough evidence that we should not send DNT, then I don't have any opposition to remove it by default. But I would like to keep it as an option for those users that still want to enable it. Best, Rodrigo.

April 14, 2026

Re: [PATCH] Remove deprecated DNT header

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >The 'Do Not Track' header has been abandoned by W3C and most major > >browsers. Very few advertising companies actually supported DNT. > > Yes, that was the case already when it was merged in 2013, but there was > the idea that it won't cause harm: > > commit b2be12828a20c54b325a4f31ca62959ea12f642b > Author: corvid <corvid(a)dillo.org> > Date: Sun Sep 15 18:48:13 2013 +0000 > > DNT will at least do no harm > > The whole situation is a manifestation of corporate rule, but > - it seems that the EU has some data protection laws that could make it > worth something in principle there. > - some large corporations have been shamed into claiming that they will do > a tiny bit of something based on the header value. At this point I don't think it's reasonable to expect that any corporation will honor it "out of the goodness of their hearts". The industry has moved on to Sec-GPC, which appears to at least have some legal backing to it. Maybe it makes more sense to simply change the DNT header to Sec-GPC? https://en.wikipedia.org/wiki/Global_Privacy_Control Regards, Alex

April 14, 2026

Re: [PATCH] Remove deprecated DNT header

by Rodrigo Arias

Hi Alex, On Mon, Apr 13, 2026 at 09:09:29AM +0000, a1ex(a)dismail.de wrote: >Hi, > >The 'Do Not Track' header has been abandoned by W3C and most major >browsers. Very few advertising companies actually supported DNT. Yes, that was the case already when it was merged in 2013, but there was the idea that it won't cause harm: commit b2be12828a20c54b325a4f31ca62959ea12f642b Author: corvid <corvid(a)dillo.org> Date: Sun Sep 15 18:48:13 2013 +0000 DNT will at least do no harm The whole situation is a manifestation of corporate rule, but - it seems that the EU has some data protection laws that could make it worth something in principle there. - some large corporations have been shamed into claiming that they will do a tiny bit of something based on the header value. >https://en.wikipedia.org/wiki/Do_Not_Track > >Sending this header may actually make Dillo MORE trackable. What situation do you have in mind?, is it something that can be measured experimentally? Best, Rodrigo.

April 13, 2026

[PATCH] Remove deprecated DNT header

by a1ex＠dismail.de

Hi, The 'Do Not Track' header has been abandoned by W3C and most major browsers. Very few advertising companies actually supported DNT. https://en.wikipedia.org/wiki/Do_Not_Track Sending this header may actually make Dillo MORE trackable. The attached patch removes it. Regards, Alex

April 13, 2026

Re: [Feat. req.?]: Diacritic-sensitive search (Ctrl+Find)

by Juan M Sevilla

Hi, 7 Apr 2026 20:30:01 +0200 Rodrigo Arias: > I don't think the matching algorithm would be trivial. For example, > should "una" match both "una" and "uña" in Spanish? What about other > languages? That's fair. I would say that's the reason why it would have to be an optional filter, so users could disable it on those cases. > The current search algorithm matches bytes as-is. Trying to do > something clever would require us to iterate by glyphs instead, which > would be harder to implement and require more computational cost. > > I would wait until we have strong evidence that this feature is > needed and the cost of the implementation is worth it. I agree. Thank you for considering it! For now, it's not so difficult to type the variations of words one want to find. Even for misspelled words: I can omit the accentuated character; on some cases, I may look for another related word, etc. > Thanks for testing! Be sure to use the latest commit of FLTK from > their master branch in GitHub, as they contain recent fixes (few > weeks ago) for font rendering. I'll certainly check it out! I was using the Debian stable version: FLTK 1.4.3 Kind regards!

April 13, 2026

Released 3.3.0-rc1

by Rodrigo Arias

Hi, The release candidate 3.3.0-rc1 is available here: https://dillo-browser.org/release/3.3.0-rc1/ Let me know if you encounter any issues so I can fix them before the 3.3.0 release. Best, Rodrigo.

April 12, 2026

Re: [Feat. req.?]: Diacritic-sensitive search (Ctrl+Find)

by Rodrigo Arias

Hi Juan, On Sun, Apr 05, 2026 at 11:53:03AM -0300, Juan M Sevilla wrote: >Hi, > >It would be great if, as there is a case-sensitive search, there >were a diacritic-sensitive option. In fact, I would expect by default >that if I search for "esta", Dillo would also find "ésta". Another >example would be searching for "accion" that matches both singular >"acción" (with accent) and plural "acciones" (without accent). That's >Spanish specific, but we may want that for any language, i.e. several >diactritical marks: ` ^ ´ ¸ ¨ I don't think the matching algorithm would be trivial. For example, should "una" match both "una" and "uña" in Spanish? What about other languages? Firefox for example matches both but I wouldn't see it as the correct behavior (they are two unrelated words in Spanish). >I don't know how hard it would be to implement, just wanted to mention >it as a useful feature. The current search algorithm matches bytes as-is. Trying to do something clever would require us to iterate by glyphs instead, which would be harder to implement and require more computational cost. I would wait until we have strong evidence that this feature is needed and the cost of the implementation is worth it. >As a good news, I wanted to say that, with the experimental fltk-1.4 >flavor, I can use my preferred font (Atkinson Hyperlegible Next) and all >absent glyphs are displayed accordingly —a bit off the line I should >say, but I knew graphical glitches are to be expected. Thanks for testing! Be sure to use the latest commit of FLTK from their master branch in GitHub, as they contain recent fixes (few weeks ago) for font rendering. Best, Rodrigo.

April 7, 2026

[Feat. req.?]: Diacritic-sensitive search (Ctrl+Find)

by Juan M Sevilla

Hi, It would be great if, as there is a case-sensitive search, there were a diacritic-sensitive option. In fact, I would expect by default that if I search for "esta", Dillo would also find "ésta". Another example would be searching for "accion" that matches both singular "acción" (with accent) and plural "acciones" (without accent). That's Spanish specific, but we may want that for any language, i.e. several diactritical marks: ` ^ ´ ¸ ¨ I don't know how hard it would be to implement, just wanted to mention it as a useful feature. As a good news, I wanted to say that, with the experimental fltk-1.4 flavor, I can use my preferred font (Atkinson Hyperlegible Next) and all absent glyphs are displayed accordingly —a bit off the line I should say, but I knew graphical glitches are to be expected. Best regards!

April 5, 2026

Re: [PATCH] Fix display of disabled options in configure.ac

by Rodrigo Arias

Hi, On Mon, Mar 23, 2026 at 10:57:40AM +0000, a1ex(a)dismail.de wrote: >Hi, > >There are a couple of missing variables in configure.ac which result >in missing info when disabling some options via configure: > >Features: > > Cookies enabled: no > XEmbed enabled : no > JPEG enabled : no > PNG enabled : no > GIF enabled : no > SVG enabled : no > WEBP enabled : > Brotli enabled : > IPv6 enabled : no > Control socket : no (experimental) > >We are missing variables for WEBP and Brotli. > >The attached patch fixes this. Thanks Alex, merged: https://git.dillo-browser.org/dillo/commit/?id=70bdaca96a05e207848a0f6b30c0… Best, Rodrigo.

March 23, 2026