- Dillo-dev - lists.mailman3.com

Re: Fingerprinting lessons from 'curl-impersonate'

by Kevin Koster

On Thu, 2 Jan 2025 00:28:20 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Thu, Jan 02, 2025 at 09:26:13AM +1100, Kevin Koster wrote: > > https://washingtonpost.com/ redirects to > > https://www.washingtonpost.com/ and loads fine for me. > > I tested it and it continues to fail for me with several UA. But after > changing the user agent to mimick an Apple phone it seems to work both > with openssl and mbedtls. For all my tests User-Agent was: Dillo/3.1.0 I'm in Australia. Maybe CDNs are directing my requests to Web servers with different rules than others?

Jan. 2, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Rodrigo Arias

Hi, On Thu, Jan 02, 2025 at 09:26:13AM +1100, Kevin Koster wrote: > https://washingtonpost.com/ redirects to > https://www.washingtonpost.com/ and loads fine for me. I tested it and it continues to fail for me with several UA. But after changing the user agent to mimick an Apple phone it seems to work both with openssl and mbedtls. Here is a working UA I found online: http_user_agent="Mozilla/5.0 (Apple-iPhone7C2/1202.466; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543 Safari/419.3" Same result as you for the previous hosts, both with openssl and mbedtls. It looks like they only discriminate the UA. > https://ebay.com/ redirects to https://www.ebay.com/ and loads for > me (I browse ebay.com.au in Dillo often). Ebay bans User-Agent: Dillo/3.1.1, but others seem to work. The above iPhone UA does. Best, Rodrigo.

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Kevin Koster

Rodrigo Arias wrote: > On Wed, Jan 01, 2025 at 04:16:58PM +0100, a1ex-J7K0XVabL0iELgA04lAiVw(a)public.gmane.org wrote: >> Here are a few example sites which seem to be doing something like that: >> >> https://www.spacecoastdaily.com > > This one seems to be loading for me. Also for me with Dillo 3.1.0 using mbed TLS 2.26.0. >> https://www.lowes.com/ > > Fails with: > > SSL_read() failed: SSL_ERROR_SYSCALL > Tls_close_by_key: Avoiding SSL shutdown for: https://www.lowes.com/ This URL loads for me. Log: Nav_open_url: new url='https://www.lowes.com/' Dns_server [0]: www.lowes.com is 23.54.30.24 23.54.30.14 Connecting to 23.54.30.24:443 www.lowes.com TLSv1.2, cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 >> https://elokata.santanderconsumer.pl > > Fails with: > > TLS ALERT on write: decode error > SSL_read() failed: error:0A000126:SSL routines::unexpected eof while reading > Tls_close_by_key: Avoiding SSL shutdown for: https://elokata.santanderconsumer.pl For me this redirects to: https://elokata.santanderconsumer.pl/Error/SecurityError?Reason=12573334125… Log: Nav_open_url: new url='https://elokata.santanderconsumer.pl' Dns_server [0]: elokata.santanderconsumer.pl is 195.138.208.195 Connecting to 195.138.208.195:443 elokata.santanderconsumer.pl TLSv1.2, cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 Nav_open_url: new url='https://elokata.santanderconsumer.pl/Error/SecurityError?Reason=12573334125…' Connecting to 195.138.208.195:443 But that second URL never loads (no error logged). https://elokata.santanderconsumer.pl redirects to and sucessfully loads an error page in Firefox 128 with NoScript. > Thanks for the list, I will check later each one in case we are doing > something wrong. > >> And of course washingtonpost.com, which you are already aware of. I'm >> sure there are more. > > Yeah, the case of washingtonpost.com is truly appaling. They were just > banning right away anything that is not HTTP/2. When I complained with a > curl reproducer so they allow Dillo via HTTP/1.1, they also banned > curl... https://washingtonpost.com/ redirects to https://www.washingtonpost.com/ and loads fine for me. > Similar problem with ebay.com, due to Akamai (edgesuite). I also > reported it, but so far no reply (this time, no curl reproducer). https://ebay.com/ redirects to https://www.ebay.com/ and loads for me (I browse ebay.com.au in Dillo often).

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Schimon Jehudah

Greetings, and Happy New Year! Client side ----------- Some check/restriction pages are pseudo and can be bypassed with a refresh. See https://greasyfork.org/en/scripts/493323-xhreload It can also work by clicking on the buttons back and forward with some browsers. Server side ----------- However, some are server side, and therefore the so called "PassKey" be required, which is the only reason that I have FF installed, until it is available for Falkon. fixoutlook.org -------------- As was with Outlock which has foisted a modified HTML format, which could not be displayed with other email clients, I would suggest to organize a similar campaign, or better yet, a boycott. It was "fixoutlook.org" and later redirected to "email-standards.org". I sense that it was a form of a controlled opposition in order to make a benevolent display or distration to the public. Boycott ------- Therefore, I suggest to begin a boycott campaign, and consequently teach and inform people of recommended means to publish and serve contents on the internet, including utilization of P2P file-sharing software. It might be too radical to you, yet I am a Jew and I am of the orthodox Jewish sector, and that sector has mostly inner communication exchanges and less with other sectors and authorities (i.e. government). So the practical mean to them, is to boycott and inform others of recommended commercial or cultural practices, if necessary. As a Jew, I am a part of such community of well over a 100K for almost a decade, and I highly recommend to try that practice of boycott. Happy New Year, Schimon On Wed, 1 Jan 2025 14:24:05 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi Kevin, > > On Wed, Jan 01, 2025 at 12:00:32PM +1100, Kevin Koster wrote: > > Yes that seems to work for me too, strangely. Anyway that > > particular URL was just a random example I found in Firefox's > > history. > > I see, here is a similar thread in Palemoon: > https://forum.palemoon.org/viewtopic.php?f=3&t=31339 > > > Seems unlikely that it will be tied to a JS-free option for the > > initial "proof-of-work" challenge. But yes it might be useful after > > completing the first challenge in Firefox, if switching browser > > can work in practice. > > Privacy pass is not tied to a particular challenge. Cloudflare now > supports a JS captcha but other non-JS challenges may be added in the > future. On the other hand, this also opens the door to Apple > enforcing only non-modified iOS systems to access a website, which is > just pure evil, > see: https://educatedguesswork.org/posts/private-access-tokens/ > > I think the idea of private tokens may eventually solve the spam > problem, but I think in its current form is harmful. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > > https://www.spacecoastdaily.com > > This one seems to be loading for me. Interesting. I don't get a TLS error, but it returns a 403 (that's with a FF UA in Dillo). In FF proper, the page loads fine. > Yeah, the case of washingtonpost.com is truly appaling. They were > just banning right away anything that is not HTTP/2. When I > complained with a curl reproducer so they allow Dillo via HTTP/1.1, > they also banned curl... Doubling down on their BS. Luckily nobody needs their site, but it's troubling that these BigCo shits seem to have zero accountability or consequences for their antisocial behavior. Regards, Alex

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Rodrigo Arias

Hi, On Wed, Jan 01, 2025 at 04:16:58PM +0100, a1ex(a)dismail.de wrote: > Hi Rodrigo, > > > I experienced problems with the user-agent being banned, and having to > > impersonate Firefox to load some sites. I haven't found yet examples > > of this deep fingerprinting for TLS or similar, you? > > Here are a few example sites which seem to be doing something like that: > > https://www.spacecoastdaily.com This one seems to be loading for me. > https://www.lowes.com/ Fails with: SSL_read() failed: SSL_ERROR_SYSCALL Tls_close_by_key: Avoiding SSL shutdown for: https://www.lowes.com/ > https://elokata.santanderconsumer.pl Fails with: TLS ALERT on write: decode error SSL_read() failed: error:0A000126:SSL routines::unexpected eof while reading Tls_close_by_key: Avoiding SSL shutdown for: https://elokata.santanderconsumer.pl Thanks for the list, I will check later each one in case we are doing something wrong. > And of course washingtonpost.com, which you are already aware of. I'm > sure there are more. Yeah, the case of washingtonpost.com is truly appaling. They were just banning right away anything that is not HTTP/2. When I complained with a curl reproducer so they allow Dillo via HTTP/1.1, they also banned curl... Similar problem with ebay.com, due to Akamai (edgesuite). I also reported it, but so far no reply (this time, no curl reproducer). I also contacted CloudFlare to see if there could be an option for non-JS browsers to solve a similar challenge so we are not excluded. > PS. Mails from the list don't seem to be coming through to my email > anymore... maybe my provider changed something recently, will have to > investigate. Hmm, I haven't touched anything in the settings... I'll CC you. Best, Rodrigo.

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by a1ex＠dismail.de

Hi Rodrigo, > I experienced problems with the user-agent being banned, and having to > impersonate Firefox to load some sites. I haven't found yet examples > of this deep fingerprinting for TLS or similar, you? Here are a few example sites which seem to be doing something like that: https://www.spacecoastdaily.com https://www.lowes.com/ https://elokata.santanderconsumer.pl And of course washingtonpost.com, which you are already aware of. I'm sure there are more. Regards, Alex PS. Mails from the list don't seem to be coming through to my email anymore... maybe my provider changed something recently, will have to investigate.

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Rodrigo Arias

Hi Kevin, On Wed, Jan 01, 2025 at 12:00:32PM +1100, Kevin Koster wrote: > Yes that seems to work for me too, strangely. Anyway that > particular URL was just a random example I found in Firefox's > history. I see, here is a similar thread in Palemoon: https://forum.palemoon.org/viewtopic.php?f=3&t=31339 > Seems unlikely that it will be tied to a JS-free option for the > initial "proof-of-work" challenge. But yes it might be useful after > completing the first challenge in Firefox, if switching browser > can work in practice. Privacy pass is not tied to a particular challenge. Cloudflare now supports a JS captcha but other non-JS challenges may be added in the future. On the other hand, this also opens the door to Apple enforcing only non-modified iOS systems to access a website, which is just pure evil, see: https://educatedguesswork.org/posts/private-access-tokens/ I think the idea of private tokens may eventually solve the spam problem, but I think in its current form is harmful. Best, Rodrigo.

Jan. 1, 2025

Unsub

by dillo.outsider747＠silomails.com

Unsubscribe me please.

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Kevin Koster

Rodrigo Arias wrote: > On Sun, Jan 05, 2025 at 10:54:39AM -0300, Kevin Koster wrote: >> > Try this in dillorc: >> > >> > http_user_agent="Mozilla/5.0 (PSP (PlayStation Portable); 2.00)" >> >> Same result (and I checked that the User-Agent really changed). >> >> Reloading after a few minutes does seem to work though. For that >> particular website anyway. >> >> Does it happen for you? > > I just checked once and I though it just worked always, but it doesn't > seems so. For me, it looks like there is a 1/2 chance it works or so. > I'm not sure what is triggering the challenge, but it is related to > CloudFlare. > > Opening this link instead seems to always work for me, regardless of the > Dillo user agent: > > https://www.autosurplus.com.au/?kw=Land+Cruiser Yes that seems to work for me too, strangely. Anyway that particular URL was just a random example I found in Firefox's history. > Not entirely sure what criteria they are using. Mimicking Firefox/Chrome > may work but only temporarily until bots do the same. A long term > approach is something like Privacy Pass, but I see several red flags on > that proposal: > > https://privacypass.github.io/ Seems unlikely that it will be tied to a JS-free option for the initial "proof-of-work" challenge. But yes it might be useful after completing the first challenge in Firefox, if switching browser can work in practice.

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Rodrigo Arias

Hi, On Sun, Jan 05, 2025 at 10:54:39AM -0300, Kevin Koster wrote: > > Try this in dillorc: > > > > http_user_agent="Mozilla/5.0 (PSP (PlayStation Portable); 2.00)" > > Same result (and I checked that the User-Agent really changed). > > Reloading after a few minutes does seem to work though. For that > particular website anyway. > > Does it happen for you? I just checked once and I though it just worked always, but it doesn't seems so. For me, it looks like there is a 1/2 chance it works or so. I'm not sure what is triggering the challenge, but it is related to CloudFlare. Opening this link instead seems to always work for me, regardless of the Dillo user agent: https://www.autosurplus.com.au/?kw=Land+Cruiser Not entirely sure what criteria they are using. Mimicking Firefox/Chrome may work but only temporarily until bots do the same. A long term approach is something like Privacy Pass, but I see several red flags on that proposal: https://privacypass.github.io/ Best, Rodrigo.

Jan. 1, 2025

Re: Fingerprinting lessons from 'curl-impersonate'

by Kevin Koster

Rodrigo Arias wrote: > On Sun, Jan 05, 2025 at 08:56:44AM -0300, Kevin Koster wrote: >> OK, here's one: >> https://www.autosurplus.com.au/?rf=kw&kw=Land+Cruiser >> >> The homepage seems to load in Dillo, but searches like that URL >> don't, except sometimes _after_ loading the same URL in Firefox, or >> maybe just waiting a long time (the three minute page auto-refresh >> duration?). I could spend all day trying to narrow down the exact >> behaviour, but it _seems_ to always work in Firefox. > > Try this in dillorc: > > http_user_agent="Mozilla/5.0 (PSP (PlayStation Portable); 2.00)" Same result (and I checked that the User-Agent really changed). Reloading after a few minutes does seem to work though. For that particular website anyway. Does it happen for you?

Dec. 31, 2024

Re: Fingerprinting lessons from 'curl-impersonate'

by Rodrigo Arias

Hi, On Sun, Jan 05, 2025 at 08:56:44AM -0300, Kevin Koster wrote: > OK, here's one: > https://www.autosurplus.com.au/?rf=kw&kw=Land+Cruiser > > The homepage seems to load in Dillo, but searches like that URL > don't, except sometimes _after_ loading the same URL in Firefox, or > maybe just waiting a long time (the three minute page auto-refresh > duration?). I could spend all day trying to narrow down the exact > behaviour, but it _seems_ to always work in Firefox. Try this in dillorc: http_user_agent="Mozilla/5.0 (PSP (PlayStation Portable); 2.00)" Source: https://news.ycombinator.com/item?id=38852310 Best, Rodrigo.

Dec. 31, 2024

Re: Fingerprinting lessons from 'curl-impersonate'

by Kevin Koster

Rodrigo Arias wrote: > On Tue, Dec 31, 2024 at 09:57:34AM +1100, Kevin Koster wrote: >> I've found that sometimes I go to a webpage and see one of the >> "enable Javascript to continue" pages in Dillo, then I load the >> same page in Firefox with NoScript blocking all its scripts, and >> it comes up fine without running any such Javascript. That could >> be just the User-Agent header though because I don't try faking >> that. > > Could this be happening because you have at some point solved a captcha > that had stored a cookie in Firefox, but doesn't load the JS to solve > the captcha in Dillo? No, Firefox is set to delete all cookies upon shut down (which is done frequently), and it seems to do so. > It would be nice to have a test case so I can reproduce this > myself too. OK, here's one: https://www.autosurplus.com.au/?rf=kw&kw=Land+Cruiser The homepage seems to load in Dillo, but searches like that URL don't, except sometimes _after_ loading the same URL in Firefox, or maybe just waiting a long time (the three minute page auto-refresh duration?). I could spend all day trying to narrow down the exact behaviour, but it _seems_ to always work in Firefox. That auto-refreshing page page titled "Just a moment..." and saying "Enable JavaScript and cookies to continue" is typical. Lots of sites use that same anti-scraping/DDoS-protection service. Based on this string in the source code: "/cdn-cgi/challenge-platform/h/b/orchestrate/chl_page/v1" (about the most identifiable thing I could see in the noise), it looks like this is from CloudFlare: https://github.com/scaredos/cfresearch/blob/master/README.md No CloudFlare URLs are set to be allowed through NoScript. But none actually show in the list of blocked scripts for the page when it's loaded in Firefox either - the CloudFlare JS seems to have been bypassed. I also get intermittently blocked by one website in Firefox (gumtree.com.au, not apparantly using CloudFlare) even with scripts enabled. That doesn't happen if I use the same FF version and profile on a different internet connection, so something about some of the IP addresses that my ISP dynamically assigns looks suspicious to some protection service they use. That website requires JS itself, so Dillo isn't an option anyway, but it shows I might have trouble that doesn't happen to people with better-trusted IPs. But, having said all that, I want to point out that getting deep into tricks to work around CloudFlare or other such services is a rabbit hole that I wouldn't ask anyone to go down. If some people enjoy doing that, great, but it's probably better isolated to a separate project like curl-impersonate rather than distracting from the challenge of implementing Web standards for rendering sites that aren't actively trying to block Dillo. Ideally then lots more people start using Dillo and CloudFlare or their users are motivated to fix this at their end (hence why I set an accurate User-Agent in Dillo so Web admins can see it in their logs). Yes in reality that ship sailed many years ago, but I think it's still the only practical approach. >> By the way, being a Git failure, I really can't see where that MD >> document lives. I look at the "rfc" repo via the GitHub website in >> Dillo and there's just a readme. I clone the repo and I just get a >> readme. I had to look back to your RFC repo announcement to find >> that link. I guess they're in separate branches or something but I >> forget things about Git faster than I learn them and can't be >> bothered learning how to use branches yet again today. I really >> think it would be better to list them together somewhere obvious, >> eg. a new Developer Documentation webpage. > > Yes, I'm thinking yet what could be a good organization. At first I was > writing the proposals in Markdown, but I'm considering using HTML > directly so we can do custom things. > > I plan to make the RFCs available in the website, as soon as I think of > a way to automatically render them. OK, great. I guess a Wiki with write access limited to the Dillo maintainers would be another option. fully Dillo-compatible Wikis are probably thin on the ground though (I use Wikepage partly for this reason, but it hasn't had new development since 2008). >> I can see from this URL mangling that there are probably only two >> RFCs so far: >> https://github.com/dillo-browser/rfc/tree/rfc-001/ (rfc-001-dillo-rfc-documents.md) >> https://github.com/dillo-browser/rfc/tree/rfc-002/ (rfc-002-rule-based-content-manipulation.md) >> https://github.com/dillo-browser/rfc/tree/rfc-003/ (404) > > I just added this one today to add support for UNIX sockets in URLs: > > https://dillo-browser.github.io/rfc/003-unix-sockets/ Great!

Dec. 31, 2024

Re: Fingerprinting lessons from 'curl-impersonate'

by Rodrigo Arias

Hi Kevin, On Tue, Dec 31, 2024 at 09:57:34AM +1100, Kevin Koster wrote: > I've found that sometimes I go to a webpage and see one of the > "enable Javascript to continue" pages in Dillo, then I load the > same page in Firefox with NoScript blocking all its scripts, and > it comes up fine without running any such Javascript. That could > be just the User-Agent header though because I don't try faking > that. Could this be happening because you have at some point solved a captcha that had stored a cookie in Firefox, but doesn't load the JS to solve the captcha in Dillo? It would be nice to have a test case so I can reproduce this myself too. > Rather than add Chrome-faking features to Dillo, maybe this would > be an extra application of the Rule-based content manipulation RFC: > https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… > > Make a rule for some sites (or Web server responses?) that has > Dillo call curl-impersonate to retrieve a Web page instead of doing > it in Dillo? I believe this could be doable yes. > By the way, being a Git failure, I really can't see where that MD > document lives. I look at the "rfc" repo via the GitHub website in > Dillo and there's just a readme. I clone the repo and I just get a > readme. I had to look back to your RFC repo announcement to find > that link. I guess they're in separate branches or something but I > forget things about Git faster than I learn them and can't be > bothered learning how to use branches yet again today. I really > think it would be better to list them together somewhere obvious, > eg. a new Developer Documentation webpage. Yes, I'm thinking yet what could be a good organization. At first I was writing the proposals in Markdown, but I'm considering using HTML directly so we can do custom things. I plan to make the RFCs available in the website, as soon as I think of a way to automatically render them. From Dillo it is hard to find the RFCs as the GitHub UI doesn't work. > I can see from this URL mangling that there are probably only two > RFCs so far: > https://github.com/dillo-browser/rfc/tree/rfc-001/ (rfc-001-dillo-rfc-documents.md) > https://github.com/dillo-browser/rfc/tree/rfc-002/ (rfc-002-rule-based-content-manipulation.md) > https://github.com/dillo-browser/rfc/tree/rfc-003/ (404) I just added this one today to add support for UNIX sockets in URLs: https://dillo-browser.github.io/rfc/003-unix-sockets/ But I haven't uploaded it to the RFC repository yet. Best, Rodrigo.

Dec. 30, 2024

Re: Fingerprinting lessons from 'curl-impersonate'

by Kevin Koster

Rodrigo Arias wrote: > On Mon, Dec 30, 2024 at 05:35:50PM +0100, a1ex-J7K0XVabL0iELgA04lAiVw(a)public.gmane.org wrote: >> There was an interesting post[1] on HN today about 'curl-impersonate', >> which is a patch[2] to curl which allows it to act like various big >> browsers, bypassing various fingerprinting techniques which would >> otherwise prevent the client from accessing the page. >> >> Looking at the patch, maybe there could be some useful ideas here for >> Dillo to use to load more sites. The SSL library also obviously plays a >> large role, maybe that's something we will need to consider as well. > > I experienced problems with the user-agent being banned, and having to > impersonate Firefox to load some sites. I haven't found yet examples of > this deep fingerprinting for TLS or similar, you? > > In any case, it would be trivial to discern Dillo as we don't support > JS, so it can be banned if they decide so. I've found that sometimes I go to a webpage and see one of the "enable Javascript to continue" pages in Dillo, then I load the same page in Firefox with NoScript blocking all its scripts, and it comes up fine without running any such Javascript. That could be just the User-Agent header though because I don't try faking that. Rather than add Chrome-faking features to Dillo, maybe this would be an extra application of the Rule-based content manipulation RFC: https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… Make a rule for some sites (or Web server responses?) that has Dillo call curl-impersonate to retrieve a Web page instead of doing it in Dillo? By the way, being a Git failure, I really can't see where that MD document lives. I look at the "rfc" repo via the GitHub website in Dillo and there's just a readme. I clone the repo and I just get a readme. I had to look back to your RFC repo announcement to find that link. I guess they're in separate branches or something but I forget things about Git faster than I learn them and can't be bothered learning how to use branches yet again today. I really think it would be better to list them together somewhere obvious, eg. a new Developer Documentation webpage. I can see from this URL mangling that there are probably only two RFCs so far: https://github.com/dillo-browser/rfc/tree/rfc-001/ (rfc-001-dillo-rfc-documents.md) https://github.com/dillo-browser/rfc/tree/rfc-002/ (rfc-002-rule-based-content-manipulation.md) https://github.com/dillo-browser/rfc/tree/rfc-003/ (404) > In my experiences, it is generally not worth reading the website > that performs this type of discrimination. That's often my approach, but then big offenders are things like government websites which one is obliged to read sometimes.

Dec. 30, 2024

Re: Fingerprinting lessons from 'curl-impersonate'

by Rodrigo Arias

Hi Alex, On Mon, Dec 30, 2024 at 05:35:50PM +0100, a1ex(a)dismail.de wrote: > Hi, > > There was an interesting post[1] on HN today about 'curl-impersonate', > which is a patch[2] to curl which allows it to act like various big > browsers, bypassing various fingerprinting techniques which would > otherwise prevent the client from accessing the page. > > Looking at the patch, maybe there could be some useful ideas here for > Dillo to use to load more sites. The SSL library also obviously plays a > large role, maybe that's something we will need to consider as well. I experienced problems with the user-agent being banned, and having to impersonate Firefox to load some sites. I haven't found yet examples of this deep fingerprinting for TLS or similar, you? In any case, it would be trivial to discern Dillo as we don't support JS, so it can be banned if they decide so. In my experiences, it is generally not worth reading the website that performs this type of discrimination. Best, Rodrigo.

Dec. 30, 2024

Fingerprinting lessons from 'curl-impersonate'

by a1ex＠dismail.de

Hi, There was an interesting post[1] on HN today about 'curl-impersonate', which is a patch[2] to curl which allows it to act like various big browsers, bypassing various fingerprinting techniques which would otherwise prevent the client from accessing the page. Looking at the patch, maybe there could be some useful ideas here for Dillo to use to load more sites. The SSL library also obviously plays a large role, maybe that's something we will need to consider as well. -Alex [1]https://news.ycombinator.com/item?id=42547820 [2]https://github.com/lexiforest/curl-impersonate/blob/main/chrome/patches/c…

Dec. 30, 2024

Re: Towards 3.2.0

by Rodrigo Arias

Hi, > So far this is working flawlessly with every URL I have thrown at it, > including stufff with a lot of symbols, and also extra-long links. I > will keep testing this heavily, but hopefully it's good to go! > > Looks like I will be able to retire my inferior link handler patch now, > thank you very much! Nice!, I will merge it soon then :) Best, Rodrigo.

Dec. 19, 2024

Re: Towards 3.2.0

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I implemented this here using the option "link_action" which will > *only* add new entries to the Link menu: > > https://github.com/dillo-browser/dillo/pull/326 > > https://github.com/dillo-browser/dillo/pull/326.patch > > I set the $url environment variable to hold the link URL and $origin > to hold the current page URL, in case you want to handle links > different based on which page you where clicking from. > > It would be nice if it gets some testing, specially with strange URL > looking cases. Hopefully it covers all your use cases, Alex. So far this is working flawlessly with every URL I have thrown at it, including stufff with a lot of symbols, and also extra-long links. I will keep testing this heavily, but hopefully it's good to go! Looks like I will be able to retire my inferior link handler patch now, thank you very much! Best regards, Alex

Dec. 18, 2024

Re: Towards 3.2.0

by Rodrigo Arias

Hi, On Fri, Oct 25, 2024 at 10:00:44PM +0200, Rodrigo Arias wrote: > Yeah, maybe I could also make it like this so you can specify a > program directly: > > actions="Open with external tool:/path/to/the/handler.sh default $URL" > actions="Open as audio:/path/to/the/handler.sh audio \"$URL\"" > actions="Open with MPV:mpv $URL" > actions="Open with Firefox:firefox $URL" I implemented this here using the option "link_action" which will *only* add new entries to the Link menu: https://github.com/dillo-browser/dillo/pull/326 https://github.com/dillo-browser/dillo/pull/326.patch I set the $url environment variable to hold the link URL and $origin to hold the current page URL, in case you want to handle links different based on which page you where clicking from. It would be nice if it gets some testing, specially with strange URL looking cases. Hopefully it covers all your use cases, Alex. > But this won't work well when the URL has characters that are interpreted by > the shell. > > It "should" be like: > > actions="Open with external tool:/path/to/the/handler.sh default \"$URL\"" > actions="Open as audio:/path/to/the/handler.sh audio \"$URL\"" > actions="Open with MPV:mpv \"$URL\"" > actions="Open with Firefox:firefox \"$URL\"" > > But is quite ugly. And I'll have to check if you can still inject some > command in the URL, which would be dangerous. This doesn't seem to be necessary, $() or $foo are not expanded when they appear in the $url. > > > Then, your handler will be invoked using the label as: > > > > > > /bin/the-handler <URL> <action-label> > > > > > > And you do whatever you find convenient in your handler, so you have > > > more context to decide the proper action based on the label. I think > > > this would cover most of the use cases of opening URLs with other > > > programs without being too convoluted. > > > > What would the default behaviour be? Will Dillo install a default > > handler with its own separate configuration file for setting up the > > default 'action' behaviours? Or does the feature only appear after > > each user has created their own handler? > > By default, no extra options. As you add the actions they appear on the > menu. We may want to distribute an example handler for users to have a > reference. The current design also covers this "tag" mechanism as a specific case: link_action="Open video:my-handler video" link_action="Open audio:my-handler audio" And in my opinion is more simple, as it can be used directly without any script: link_action="Open with MPV:mpv $url" link_action="Open with Firefox:firefox $url" In the future we can also add a similar thing for when Dillo opens an URL but the content type is unknown, so that it offers more options than a download. At that point we will know the content type, so we can do better handling. But let's keep it simple for 3.2.0. Best, Rodrigo.

Dec. 17, 2024

Re: FOSDEM 2025

by Rodrigo Arias

On Mon, Dec 16, 2024 at 10:42:33PM +0100, Xavier Del Campo Romero wrote: > Hi Rodrigo, > > See you there! I am sure it will be an interesting talk. :) Thanks!, see you there :) Rodrigo.

Dec. 17, 2024

Re: FOSDEM 2025

by Rodrigo Arias

On Mon, Dec 16, 2024 at 01:46:03PM +0100, a1ex(a)dismail.de wrote: > That's great Rodrigo, really looking forward to it! Don't know if I can > make it to Brussels in February, but hopefully! > > Looks like there will be some Debian people there too, hopefully they > finally realize that you are legit and update their broken Dillo > package :) That would be nice, let see :-) Rodrigo.

Dec. 17, 2024

Re: FOSDEM 2025

by Xavier Del Campo Romero

Hi Rodrigo, See you there! I am sure it will be an interesting talk. :) Best regards, Xavi On 16/12/24 7:10, Rodrigo Arias wrote: > Hi all, > > I'm pleased to announce I will be going to FOSDEM this year to give a > talk on Dillo and show it live (if all goes well). > > https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resurrecting-the-mi… > > It would be the 25 year anniversary since the first Dillo release, and > 20 years later since Jorge and Sebastian gave their talk at FOSDEM in 2005: > > https://dillo-browser.github.io/old/conferences.html > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Dec. 16, 2024

Re: FOSDEM 2025

by a1ex＠dismail.de

1. Rodrigo already explained to you that this out of scope for the Dillo project. 2. The talk is scheduled to be only 20 minutes long. Are you seriously proposing that he should spend his precious time talking about a feature that nobody here is interested in? Schimon Jehudah <sch(a)fedora.email> wrote: > Congratulations, Rodrigo! > > My you kindly mention the possibility to browse XHTML content which is > stored on XMPP? > > I have made a script for Dillo and I am stil waiting for feedbacks, in > order to finalize for a best and proper usage with Dillo. > > https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/JF… > > Best regards, > Schimon > > On Mon, 16 Dec 2024 07:10:43 +0100 > Rodrigo Arias <rodarima(a)gmail.com> wrote: > > > Hi all, > > > > I'm pleased to announce I will be going to FOSDEM this year to give > > a talk on Dillo and show it live (if all goes well). > > > > https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resurrecting-the-mi… > > > > It would be the 25 year anniversary since the first Dillo release, > > and 20 years later since Jorge and Sebastian gave their talk at > > FOSDEM in 2005: > > > > https://dillo-browser.github.io/old/conferences.html > > > > Best, > > 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

Dec. 16, 2024

Re: FOSDEM 2025

by a1ex＠dismail.de

That's great Rodrigo, really looking forward to it! Don't know if I can make it to Brussels in February, but hopefully! Looks like there will be some Debian people there too, hopefully they finally realize that you are legit and update their broken Dillo package :) Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi all, > > I'm pleased to announce I will be going to FOSDEM this year to give a > talk on Dillo and show it live (if all goes well). > > https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resurrecting-the-mi… > > It would be the 25 year anniversary since the first Dillo release, > and 20 years later since Jorge and Sebastian gave their talk at > FOSDEM in 2005: > > https://dillo-browser.github.io/old/conferences.html > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Dec. 16, 2024

Re: FOSDEM 2025

by Schimon Jehudah

Congratulations, Rodrigo! My you kindly mention the possibility to browse XHTML content which is stored on XMPP? I have made a script for Dillo and I am stil waiting for feedbacks, in order to finalize for a best and proper usage with Dillo. https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/JF… Best regards, Schimon On Mon, 16 Dec 2024 07:10:43 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi all, > > I'm pleased to announce I will be going to FOSDEM this year to give a > talk on Dillo and show it live (if all goes well). > > https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resurrecting-the-mi… > > It would be the 25 year anniversary since the first Dillo release, > and 20 years later since Jorge and Sebastian gave their talk at > FOSDEM in 2005: > > https://dillo-browser.github.io/old/conferences.html > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Dec. 16, 2024

Re: 25 years of Dillo

by Diego

Happy birthday, Dillo!!!¡! Goods! Diego. El lun, 16 dic 2024 a las 0:54, <a1ex(a)dismail.de> escribió: > > I stand with you. > > > Rodrigo Arias <rodarima(a)gmail.com> wrote: > > > Hi all, > > > > Dillo is now 25 years old! > > > > I wrote a special page to celebrate it, with a bit of history: > > > > https://dillo-browser.github.io/25-years/index.html > > > > Best, > > 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

Dec. 16, 2024

FOSDEM 2025

by Rodrigo Arias

Hi all, I'm pleased to announce I will be going to FOSDEM this year to give a talk on Dillo and show it live (if all goes well). https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resurrecting-the-mi… It would be the 25 year anniversary since the first Dillo release, and 20 years later since Jorge and Sebastian gave their talk at FOSDEM in 2005: https://dillo-browser.github.io/old/conferences.html Best, Rodrigo.

Dec. 16, 2024

Re: 25 years of Dillo

by a1ex＠dismail.de

I stand with you. Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi all, > > Dillo is now 25 years old! > > I wrote a special page to celebrate it, with a bit of history: > > https://dillo-browser.github.io/25-years/index.html > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Dec. 15, 2024

Re: 25 years of Dillo

by Xavier Del Campo Romero

Happy birthday, Dillo! Here to 25 more years (if the www does not destroy itself)! Best regards, Xavi On 15 December 2024 22:07:46 CET, Rodrigo Arias <rodarima(a)gmail.com> wrote: >Hi all, > >Dillo is now 25 years old! > >I wrote a special page to celebrate it, with a bit of history: > >https://dillo-browser.github.io/25-years/index.html > >Best, >Rodrigo. >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Dec. 15, 2024

Re: 25 years of Dillo

by yeti

Rodrigo Arias <rodarima(a)gmail.com> wrote: > Dillo is now 25 years old! > > I wrote a special page to celebrate it, with a bit of history: > > https://dillo-browser.github.io/25-years/index.html _ / ) ___ / /__ |-' _) | _) | _) ___|-.____) -- I do not bite, I just want to play.

Dec. 15, 2024

25 years of Dillo

by Rodrigo Arias

Hi all, Dillo is now 25 years old! I wrote a special page to celebrate it, with a bit of history: https://dillo-browser.github.io/25-years/index.html Best, Rodrigo.

Dec. 15, 2024

Re: [PATCH] make downloads.dpi use http_user_agent from dillorc

by Rodrigo Arias

Hi, On Thu, Nov 28, 2024 at 07:02:01PM +0100, Rodrigo Arias wrote: >Hi, > >>I wanted to remind about this patch. Is there anything preventing it >>from going in? > >Mostly, lack of time. I wanted to move the prefs logic so it can be >used from the dpis, and we don't need to reimplement the parsing. But >not sure how hard that would be. What about this: https://github.com/dillo-browser/dillo/pull/319 Patch: https://github.com/dillo-browser/dillo/pull/319.patch So we avoid parsing the preferences again. It works fine with UA with spaces, even if the %s looks like it won't. Best, Rodrigo.

Dec. 10, 2024

Re: [PATCH] make downloads.dpi use http_user_agent from dillorc

by Rodrigo Arias

Hi, >I wanted to remind about this patch. Is there anything preventing it >from going in? Mostly, lack of time. I wanted to move the prefs logic so it can be used from the dpis, and we don't need to reimplement the parsing. But not sure how hard that would be. Best, Rodrigo.

Nov. 28, 2024

Re: [PATCH] make downloads.dpi use http_user_agent from dillorc

by a1ex＠dismail.de

Hi, I wanted to remind about this patch. Is there anything preventing it from going in? This can be considered a privacy leak, since Dillo does not honor the user-specified agent for downloads. Thanks, Alex PS: I'm still maintaining this directory of Dillo-friendly services if anyone has any suggestions or sites to add: https://alex.envs.net/dillectory <a1ex(a)dismail.de> wrote: > Hi, > > Here is a patch which allows wget called from downloads.dpi to use the > user agent provided in dillorc, and fallback to the hardcoded > Dillo/version agent if not defined. > > Regards, > Alex > > diff -upr a/dlib/dlib.c b/dlib/dlib.c > --- a/dlib/dlib.c Sun Aug 11 22:21:59 2024 > +++ b/dlib/dlib.c Tue Sep 3 13:49:00 2024 > @@ -922,6 +922,45 @@ char *dGethomedir (void) > } > > /** > + * Return the http_user_agent value in a static string > + */ > +char *dGetuseragent (void) > +{ > + static char *dillorc = NULL; > + dillorc = dStrconcat(dGethomedir(), "/", ".dillo/dillorc", NULL); > + FILE *In; > + int len; > + char *rcline = NULL, *value = NULL, *p; > + if ((In = fopen(dillorc, "r")) == NULL) { > + DLIB_MSG("dGetuseragent: unable to open dillorc.\n"); > + return ("Dillo/" VERSION); > + } > + while ((rcline = dGetline(In)) != NULL) { > + if (strncmp(rcline, "http_user_agent", 15) == 0) > + break; > + dFree(rcline); > + } > + fclose(In); > + if (!rcline) { > + value = ("Dillo/" VERSION); > + DLIB_MSG("dGetuseragent: no 'http_user_agent' in dillorc.\n"); > + } else { > + len = (int) strlen(rcline); > + if (len && rcline[len - 1] == '\n') > + rcline[len - 1] = 0; > + if ((p = strchr(rcline, '='))) { > + while (*++p == ' '); > + value = dStrdup(p); > + } else { > + value = ("Dillo/" VERSION); > + DLIB_MSG("dGetuseragent: error parsing value in dillorc.\n"); > + } > + } > + dFree(rcline); > + return (value); > +} > + > +/** > * Get a line from a FILE stream. > * Return value: read line on success, NULL on EOF. > */ > diff -upr a/dlib/dlib.h b/dlib/dlib.h > --- a/dlib/dlib.h Sun Aug 11 22:21:59 2024 > +++ b/dlib/dlib.h Tue Sep 3 13:49:00 2024 > @@ -175,6 +175,7 @@ void dLib_show_messages(bool_t show); > */ > char *dGetcwd(void); > char *dGethomedir(void); > +char *dGetuseragent(void); > char *dGetline(FILE *stream); > int dClose(int fd); > int dUsleep(unsigned long us); > diff -upr a/dpi/downloads.cc b/dpi/downloads.cc > --- a/dpi/downloads.cc Sun Aug 11 22:21:59 2024 > +++ b/dpi/downloads.cc Tue Sep 3 13:49:06 2024 > @@ -45,6 +45,7 @@ > #include "config.h" > #include "dpiutil.h" > #include "../dpip/dpip.h" > +#include "../dlib/dlib.h" > > /* > * Debugging macros > @@ -324,7 +325,7 @@ DLItem::DLItem(const char *full_filename, const > char * cookies_path = dStrconcat(dGethomedir(), > "/.dillo/cookies.txt", NULL); dl_argv = new char*[10]; > int i = 0; > - const char *user_agent = "Dillo/" VERSION; > + const char *user_agent = dGetuseragent(); > dl_argv[i++] = (char*)"wget"; > if (stat(fullname, &ss) == 0) > init_bytesize = (int)ss.st_size;

Nov. 28, 2024

XSLT

by Schimon Jehudah

Good day, everyone! I would want to know of an example or an elaboration as of how would it be possible to wriite a plugin which would parse XSLT. I want to know how to trigger Dillo to engage such type of a plugin. P.S. Did anyone examine my XMPP plugin for Dillo, yet? Kind regards, Schimon

Nov. 14, 2024

Re: XMPP PubSub Plugin

by Schimon Jehudah

Good evening! I have made an XMPP plugin for Dillo. I would be grateful for your feedbacks. I would also need instructions as to how to implement configurations. Compulsory options: * JabberID * Password Possible options: * Connection * Timeout I consider to add an interface for JabberID and Password, and I would rather receive instructions from the staff. It is posible to use anonymous accounts, such as anon(a)anon.jabberfr.org, yet I would rather not do so, because: * Most of the anonymous accounts have PubSub disabled, which is exactly the needed feature which this plugin provides. * I do not want to rely on anonymous accounts or any server, because of changes that might occur in any future. P.S. I did not think, that I would be sending a plugin as early as now. Kind regards, Schimon On Thu, 7 Nov 2024 07:45:33 +0200 Schimon Jehudah <sch(a)fedora.email> wrote: > Good day, to one and all! > > My name is Schimon, I am a pianist, attorney at law, and I also work > on software that mainly involve the technologies of Syndication and > XMPP. > > My current intention, is to design an XMPP client, based on Slixmpp, > to allow Dillo to interact with Atom Over XMPP (XEP-0277 and > XEP-0472). > > Atom Over XMPP specifies storage of textual content (be it text or > HTML) on XMPP PubSub nodes. It is useful for publishing (see Libervia, > Movim, Rivista XJP), annotating resources (see Blasta) and for any > sort of mean which may require textual content. > > References: > https://blasta.woodpeckersnest.eu/help/about/xmpp/atomsub > https://blasta.woodpeckersnest.eu/help/about/xmpp/pubsub > > Projects: > https://schapps.woodpeckersnest.eu/blasta/ > https://schapps.woodpeckersnest.eu/rivista/ > > I intend to utilize the Python computer language for this task. > > Any help, encouragement, and especially accompanying (not in the > musical sense) my efforts be welcome. > > This is my first time which I intend to collaborate with Dillo > developers, and I am excited by this opportunity. > > Kind regards, > Schimon

Nov. 9, 2024

Re: Testing without Dillo

by Schimon Jehudah

Good day, Rodrigo. It works! $ printf "<cmd='auth' msg='123456' '><cmd='open_url' url='gemini://woodpeckersnest.space/~schapps/' '>" | ./gemini.filter.dpi Thank you, Schimon On Thu, 7 Nov 2024 21:44:20 +0100 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Thu, Nov 07, 2024 at 05:49:37PM +0200, Schimon Jehudah wrote: > >Is it possible to run Dillo plugins without installing them? > > Try: > > $ printf "<cmd='auth' msg='123456' '><cmd='open_url' url='foo://bar' > '>" | ./foo.filter.dpi > > You can usually ignore the auth part. The response must look like: > > <cmd='start_send_page' url='' '> > Content-type: text/html > > <!DOCTYPE html> > <html> > ... > </html> > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Nov. 8, 2024

Re: Testing without Dillo

by Rodrigo Arias

Hi, On Thu, Nov 07, 2024 at 05:49:37PM +0200, Schimon Jehudah wrote: >Is it possible to run Dillo plugins without installing them? Try: $ printf "<cmd='auth' msg='123456' '><cmd='open_url' url='foo://bar' '>" | ./foo.filter.dpi You can usually ignore the auth part. The response must look like: <cmd='start_send_page' url='' '> Content-type: text/html <!DOCTYPE html> <html> ... </html> Best, Rodrigo.

Nov. 7, 2024

Testing without Dillo

by Schimon Jehudah

Greetings! Is it possible to run Dillo plugins without installing them? I ask for two reasons: 1) Ease of development. 2) I fail to activate plugins. ** ERROR **: [Dpi_read_comm_keys] No such file or directory Dpi_blocking_start_dpid: try 1 [dpid]: a_Misc_mksecret: 1j91dh5 dpid started Dpi_get_server_port: can't read server port from dpid. Dillo: normal exit! Regards, Schimon

Nov. 7, 2024

XMPP PubSub Plugin

by Schimon Jehudah

Good day, to one and all! My name is Schimon, I am a pianist, attorney at law, and I also work on software that mainly involve the technologies of Syndication and XMPP. My current intention, is to design an XMPP client, based on Slixmpp, to allow Dillo to interact with Atom Over XMPP (XEP-0277 and XEP-0472). Atom Over XMPP specifies storage of textual content (be it text or HTML) on XMPP PubSub nodes. It is useful for publishing (see Libervia, Movim, Rivista XJP), annotating resources (see Blasta) and for any sort of mean which may require textual content. References: https://blasta.woodpeckersnest.eu/help/about/xmpp/atomsub https://blasta.woodpeckersnest.eu/help/about/xmpp/pubsub Projects: https://schapps.woodpeckersnest.eu/blasta/ https://schapps.woodpeckersnest.eu/rivista/ I intend to utilize the Python computer language for this task. Any help, encouragement, and especially accompanying (not in the musical sense) my efforts be welcome. This is my first time which I intend to collaborate with Dillo developers, and I am excited by this opportunity. Kind regards, Schimon

Nov. 7, 2024

[PATCH] Hide tab close button

by a1ex＠dismail.de

Hi list, In an attempt to keep the UI as configurable as possible for accessibility and themeing purposes, here is an example patch to hide the close tab button. Since we can already close the tab with the right or middle mouse button click, the button might be useless for some users, and may also be taking up valuable horizontal real-estate in the tab bar. Maybe it seems silly, but when using Dillo on a constrained portrait display, this can be useful. It can probably be made into a dillorc option if there is any interest. --- a/src/uicmd.cc Mon Oct 28 19:01:28 2024 +++ b/src/uicmd.cc Mon Oct 28 19:01:57 2024 @@ -142,7 +142,7 @@ class CustTabs : public Fl_Group { (public) Fl_Group(0,0,ww,th,lbl) { Pack = NULL; focus_counter = 0; - tab_w = 50, tab_h = th, ctab_h = 1, btn_w = 20, ctl_w = 1*btn_w+2; + tab_w = 50, tab_h = th, ctab_h = 1, btn_w = 20; resize(0,0,ww,ctab_h); /* tab buttons go inside a pack within a scroll */ Scroll = new Fl_Scroll(0,0,ww-ctl_w,ctab_h); I've also done some preliminary work to theme the tab bar, scroll bar, url bar, icons, and ui highlights. Dillo isn't really designed for that, so to create a proper user configurable theme-engine will probably be quite a lot of work, and not something that I can handle alone. Regards, Alex

Oct. 28, 2024

Re: Use SIGUSR1 to reload the page!

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I implemented this on the following PR: > > https://github.com/dillo-browser/dillo/pull/290 > > It reloads the focused tabs on all windows of the given Dillo process > when a SIGUSR1 signal arrives. > > Example to reload a local file test.html: > > All Dillo processes: > > echo test.html | entr pkill -SIGUSR1 dillo > > Only one with pid 1234: > > echo test.html | entr kill -SIGUSR1 1234 > > I mostly wanted to quickly reload the changes when I edit an HTML > page, but this can also be used to monitor a remote page over time, > like: > > $ dillo https://twtxt.envs.net/api/plain/tweets & > $ while [ 1 ]; do sleep 10; pkill -SIGUSR1 dillo; done & > > See: https://forums.raspberrypi.com/viewtopic.php?t=330705 > > Could you test it on OpenBSD, I hope the signaling part continues to > work fine there. Nice patch! It seems to be working fine here with no problems. I agree that this is quite useful for editing and monitoring pages, thanks! -Alex

Oct. 25, 2024

Re: Towards 3.2.0

by Rodrigo Arias

Hi all, On Thu, Oct 24, 2024 at 10:45:49PM +0200, Xavier Del Campo Romero wrote: >I would have preferred to resume my work on multipart/form-data, but I >have been too busy with other projects and IRL. The required changes >were way too complex to shoehorn into this release, so I assume they >will have to wait for the next one :) No worries :-) On Thu, Oct 24, 2024 at 11:09:46PM +0200, a1ex(a)dismail.de wrote: >I don't know about the complexity, but it worked fine here! Yeah, but I prefer to move to a new file when the format is more stable, so you can keep your rules intact. Now I'm experimenting. >Sounds good, but in that case, maybe we should provide an example >handler script in the docs, since that could be a barrier for some >users. > >I'm still using a variant of this[1] patch, but with multiple >entries, which still seems to be the easiest way of allowing external >actions. > >[1] https://alex.envs.net/patches/00-ext-link-handler.patch Yeah, maybe I could also make it like this so you can specify a program directly: actions="Open with external tool:/path/to/the/handler.sh default $URL" actions="Open as audio:/path/to/the/handler.sh audio \"$URL\"" actions="Open with MPV:mpv $URL" actions="Open with Firefox:firefox $URL" But this won't work well when the URL has characters that are interpreted by the shell. It "should" be like: actions="Open with external tool:/path/to/the/handler.sh default \"$URL\"" actions="Open as audio:/path/to/the/handler.sh audio \"$URL\"" actions="Open with MPV:mpv \"$URL\"" actions="Open with Firefox:firefox \"$URL\"" But is quite ugly. And I'll have to check if you can still inject some command in the URL, which would be dangerous. On Fri, Oct 25, 2024 at 09:12:21AM +1000, Kevin Koster wrote: >One action which would probably complicate things, but likely be >among the most used for me, would actually be something like "View >as text" (in Dillo). Effectively the inverse of "Save link as...". > >Websites with annoying MIME settings can give links that one wants >to view as text (eg. source code files), but the server assigns a >MIME value to them that makes Dillo download them to file. This >would force Dillo to display the link as a Text file regardless. Yes, I have also experienced this annoyance. It may be nice yes, not sure how complex to implement. >Also the view source plugin/rendering can choke a bit >performance-wise (on the modestly-powered computers I use, at >least) with the multi-MB webpages that are common today. Just >viewing as text might be a quicker option, eg. when looking to >manually extract a URL meant to load via Javascript. I think for very long text files this may continue to choke Dillo. Maybe you could add a external tool that pipes it to more(1) or less(1). >> Then, your handler will be invoked using the label as: >> >> /bin/the-handler <URL> <action-label> >> >> And you do whatever you find convenient in your handler, so you have >> more context to decide the proper action based on the label. I think >> this would cover most of the use cases of opening URLs with other >> programs without being too convoluted. > >What would the default behaviour be? Will Dillo install a default >handler with its own separate configuration file for setting up the >default 'action' behaviours? Or does the feature only appear after >each user has created their own handler? By default, no extra options. As you add the actions they appear on the menu. We may want to distribute an example handler for users to have a reference. Best, Rodrigo.

Oct. 25, 2024

Re: Use SIGUSR1 to reload the page

by Rodrigo Arias

Hi Alex, On Mon, Sep 02, 2024 at 04:04:30PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >I find your recent idea[0] to refresh the page on local file changes >interesting, and it could be a quite useful feature. > >[0] https://github.com/dillo-browser/dillo/issues/255 I implemented this on the following PR: https://github.com/dillo-browser/dillo/pull/290 It reloads the focused tabs on all windows of the given Dillo process when a SIGUSR1 signal arrives. Example to reload a local file test.html: All Dillo processes: echo test.html | entr pkill -SIGUSR1 dillo Only one with pid 1234: echo test.html | entr kill -SIGUSR1 1234 I mostly wanted to quickly reload the changes when I edit an HTML page, but this can also be used to monitor a remote page over time, like: $ dillo https://twtxt.envs.net/api/plain/tweets & $ while [ 1 ]; do sleep 10; pkill -SIGUSR1 dillo; done & See: https://forums.raspberrypi.com/viewtopic.php?t=330705 Could you test it on OpenBSD, I hope the signaling part continues to work fine there. Best, Rodrigo.

Oct. 25, 2024

Re: Towards 3.2.0

by Kevin Koster

Rodrigo Arias wrote: > > actions="default Open with external tool" > actions="firefox Open with Firefox" > actions="mpv Open with MPV" > actions="mpv-audio Open with MPV (audio)" > handler="/bin/the-handler" One action which would probably complicate things, but likely be among the most used for me, would actually be something like "View as text" (in Dillo). Effectively the inverse of "Save link as...". Websites with annoying MIME settings can give links that one wants to view as text (eg. source code files), but the server assigns a MIME value to them that makes Dillo download them to file. This would force Dillo to display the link as a Text file regardless. Also the view source plugin/rendering can choke a bit performance-wise (on the modestly-powered computers I use, at least) with the multi-MB webpages that are common today. Just viewing as text might be a quicker option, eg. when looking to manually extract a URL meant to load via Javascript. This would be a separate feature to implement, but maybe it would be a good fit for the same sub-menu. > Then, your handler will be invoked using the label as: > > /bin/the-handler <URL> <action-label> > > And you do whatever you find convenient in your handler, so you have > more context to decide the proper action based on the label. I think > this would cover most of the use cases of opening URLs with other > programs without being too convoluted. What would the default behaviour be? Will Dillo install a default handler with its own separate configuration file for setting up the default 'action' behaviours? Or does the feature only appear after each user has created their own handler?

Oct. 24, 2024

Re: Towards 3.2.0

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > One of the features I would like to include is the ability to open a > link with an external handler. We have a proof of concept that uses > the rule file, but I think it is too complex for now: > > https://github.com/dillo-browser/dillo/pull/199 I don't know about the complexity, but it worked fine here! > I'm thinking it may be better to add an easier variant first, that we > can extend later. I'm considering adding these to dillorc: > > actions="default Open with external tool" > actions="firefox Open with Firefox" > actions="mpv Open with MPV" > actions="mpv-audio Open with MPV (audio)" > handler="/bin/the-handler" > > Where you can define multiple "actions" but only one "handler". The > actions have a label at the beginning (first word) and a human > readable text that will be presented in the menu. > > Then, your handler will be invoked using the label as: > > /bin/the-handler <URL> <action-label> > > And you do whatever you find convenient in your handler, so you have > more context to decide the proper action based on the label. I think > this would cover most of the use cases of opening URLs with other > programs without being too convoluted. Sounds good, but in that case, maybe we should provide an example handler script in the docs, since that could be a barrier for some users. I'm still using a variant of this[1] patch, but with multiple entries, which still seems to be the easiest way of allowing external actions. [1] https://alex.envs.net/patches/00-ext-link-handler.patch Regards, Alex

Oct. 24, 2024

Re: Towards 3.2.0

by Xavier Del Campo Romero

Hi Rodrigo, I would have preferred to resume my work on multipart/form-data, but I have been too busy with other projects and IRL. The required changes were way too complex to shoehorn into this release, so I assume they will have to wait for the next one :) Best regards, Xavi On 24/10/24 20:49, Rodrigo Arias wrote: > Hi, > > I'm planning to close the feature window shortly, so I will need to > think what else to include for 3.2.0 before it is closed. > > One of the features I would like to include is the ability to open a > link with an external handler. We have a proof of concept that uses the > rule file, but I think it is too complex for now: > > https://github.com/dillo-browser/dillo/pull/199 > > I'm thinking it may be better to add an easier variant first, that we > can extend later. I'm considering adding these to dillorc: > > actions="default Open with external tool" > actions="firefox Open with Firefox" > actions="mpv Open with MPV" > actions="mpv-audio Open with MPV (audio)" > handler="/bin/the-handler" > > Where you can define multiple "actions" but only one "handler". The > actions have a label at the beginning (first word) and a human readable > text that will be presented in the menu. > > Then, your handler will be invoked using the label as: > > /bin/the-handler <URL> <action-label> > > And you do whatever you find convenient in your handler, so you have > more context to decide the proper action based on the label. I think > this would cover most of the use cases of opening URLs with other > programs without being too convoluted. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Oct. 24, 2024

Towards 3.2.0

by Rodrigo Arias

Hi, I'm planning to close the feature window shortly, so I will need to think what else to include for 3.2.0 before it is closed. One of the features I would like to include is the ability to open a link with an external handler. We have a proof of concept that uses the rule file, but I think it is too complex for now: https://github.com/dillo-browser/dillo/pull/199 I'm thinking it may be better to add an easier variant first, that we can extend later. I'm considering adding these to dillorc: actions="default Open with external tool" actions="firefox Open with Firefox" actions="mpv Open with MPV" actions="mpv-audio Open with MPV (audio)" handler="/bin/the-handler" Where you can define multiple "actions" but only one "handler". The actions have a label at the beginning (first word) and a human readable text that will be presented in the menu. Then, your handler will be invoked using the label as: /bin/the-handler <URL> <action-label> And you do whatever you find convenient in your handler, so you have more context to decide the proper action based on the label. I think this would cover most of the use cases of opening URLs with other programs without being too convoluted. Best, Rodrigo.

Oct. 24, 2024