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! _______________________________________________ Dillo-dev mailing list -- dillo-dev@mailman3.com To unsubscribe send an email to dillo-dev-le...@mailman3.com
