April 2026 - Dillo-dev - lists.mailman3.com

Re: [Issue]: Parsing empty domain attributes in cookies

by Rodrigo Arias

Hi Julian, On Mon, Apr 27, 2026 at 11:30:06PM +0200, Julian Jørgensen wrote: >Hi Dillo devs, > >Thanks for a great browser :-). I'm having great fun using it >for accessing smaller sites. However, I might have found a minor issue >with the way it handles cookies. I'm not very familiar with browser, so >the problem is most likely on the site I'm trying to access. > >I use this pretty popular search engine called kagi.com. They have >a html mode, which I enjoy testing in browsers like Dillo. The problem >is that their session cookie is saved with an empty domain like so: >`Domain=;`. > >As far as I can understand from [1], it seems that this should result >in Dillo (the user agent?) ignoring this key/value pair. However, Dillo >will parse the domain as "", which will fail the domain/host >verification later in the program. > >I have attached a git formatted patch to demonstrate the issue. After >applying this change, the kagi.com page works like I would >expect. Thanks for the patch, it seems to work as intended. I also think that ignoring the key/value is the right interpretation from: https://www.rfc-editor.org/rfc/rfc6265#section-5.2.3 > If the attribute-value is empty, the behavior is undefined. However, > the user agent SHOULD ignore the cookie-av entirely. I will merge it after fixing the cookies unit test, so I can add extra cases for empty domains. Best, Rodrigo.

April 29, 2026

[Issue]: Parsing empty domain attributes in cookies

by Julian Jørgensen

Hi Dillo devs, Thanks for a great browser :-). I'm having great fun using it for accessing smaller sites. However, I might have found a minor issue with the way it handles cookies. I'm not very familiar with browser, so the problem is most likely on the site I'm trying to access. I use this pretty popular search engine called kagi.com. They have a html mode, which I enjoy testing in browsers like Dillo. The problem is that their session cookie is saved with an empty domain like so: `Domain=;`. As far as I can understand from [1], it seems that this should result in Dillo (the user agent?) ignoring this key/value pair. However, Dillo will parse the domain as "", which will fail the domain/host verification later in the program. I have attached a git formatted patch to demonstrate the issue. After applying this change, the kagi.com page works like I would expect. Best regards, Julian Jørgensen [1]: https://www.rfc-editor.org/rfc/rfc6265#section-5.2.3

April 27, 2026

Re: Release 3.3.0

by Diego

¡Congratulations! Diego. El dom, 26 abr 2026 a las 21:20, Xavier Del Campo Romero (< xavi92(a)disroot.org>) escribió: > Congratulations and thanks for the hard work, team! > > Best regards, > > Xavi > > On 4/26/26 18:42, Rodrigo Arias wrote: > > Hi, > > > > I'm happy to announce that the Dillo 3.3.0 release is finally out: > > > > https://dillo-browser.org/release/3.3.0/ > > > > It follows the FLTK 1.4.5 release made yesterday, which contains some > > bug fixes for font rendering with Pango/Cairo. > > > > Enjoy!, > > Rodrigo. > > _______________________________________________ > > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com >

April 26, 2026

Re: Release 3.3.0

by Xavier Del Campo Romero

Congratulations and thanks for the hard work, team! Best regards, Xavi On 4/26/26 18:42, Rodrigo Arias wrote: > Hi, > > I'm happy to announce that the Dillo 3.3.0 release is finally out: > > https://dillo-browser.org/release/3.3.0/ > > It follows the FLTK 1.4.5 release made yesterday, which contains some > bug fixes for font rendering with Pango/Cairo. > > Enjoy!, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

April 26, 2026

Release 3.3.0

by Rodrigo Arias

Hi, I'm happy to announce that the Dillo 3.3.0 release is finally out: https://dillo-browser.org/release/3.3.0/ It follows the FLTK 1.4.5 release made yesterday, which contains some bug fixes for font rendering with Pango/Cairo. Enjoy!, Rodrigo.

April 26, 2026

A new SearXNG search randomizer for Dillo

by a1ex＠dismail.de

Hi, I have created a directory and search redirector for unofficial SearXNG instances. These are instances which do not appear on 'searx.space' or 'farside.link'. They usually seem to work better than the official ones, due to the fact that they aren't as highly publicized and have less load. The directory is here: https://alex.envs.net/searxng.html This link will automatically send you to a random instance: https://alex.envs.net/searx-rand.sh Finally, you can search directly from Dillo using a random instance by putting the following line into your dillorc: search_url="us UnScripted https://alex.envs.net/search.sh?%s" If anyone has links to additional SearXNG instances which I have not covered, and are not present on the official list, please let me know! Keep in mind that the instance must work without JavaScript! Regards, Alex

April 25, 2026

[PATCH] Add user-controllable Sec-GPC header

by a1ex＠dismail.de

Hi, The attached patch adds a Sec-GPC header to Dillo. It defaults to ON, and is controllable through a dillorc setting of 'http_sec_gpc'. Also, I changed DNT to be user-controllable with a dillorc setting of 'http_dnt', also defaults to ON. I know that this is too late to get in for the 3.3.0 release, but I'm sending it for review now, and if there are any issues it should allow plenty of time to fix. Regards, Alex

April 15, 2026

Re: [PATCH] Remove deprecated DNT header

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > 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. Sounds reasonable, I agree that allowing the user to control these settings is the right way to go. There was a timely article just yesterday which claims that big-tech is outright ignoring GPC signals: https://www.404media.co/google-microsoft-meta-all-tracking-you-even-when-yo… Even though some fines have already been issued based on GPC, they seem too small to be a real deterrent, and it just amounts to the 'cost of doing business' for these large corporations. It appears that often they don't even bother to pay the fines, and just tie up the courts for years: https://www.irishtimes.com/business/2026/01/12/data-protection-commission-o… So, this will remain an uphill battle, and just sending anti-tracking signals will never be a replacement for aggressive privacy-preserving tactics. Thankfully Dillo has one of the best privacy-preserving features available: no javascript! Rembember people, this is a feature, not a bug! Regards, Alex

April 15, 2026

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