December 2024 - Dillo-dev - lists.mailman3.com

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