[SCRIPT] Run Dillo with a random user agent
Hi list, Here is a simple script which runs Dillo with a random user agent on each run. I've been using it for a long time with no issues. It would be interesting to have similar functionality built-in to Dillo at some point, at least for me. $ cat rundillo.sh #!/bin/sh # runs dillo with a random user agent, from a list in agents.txt # the ua must be the last line of dillorc, this deletes it: echo -e '$d\nw\nq'| ed ~/.dillo/dillorc # put a random ua line from agents.txt into the last line of dillorc # each line in agents.txt must include http_user_agent='...' cat ~/.dillo/agents.txt | sort -R | head -1 >> ~/.dillo/dillorc # run dillo: dillo ------------------------------- Here is an example 'agents.txt': http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0' http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0' http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0' http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0' http_user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:123.0) Gecko/20100101 Firefox/123.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:124.0) Gecko/20100101 Firefox/124.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:125.0) Gecko/20100101 Firefox/125.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:126.0) Gecko/20100101 Firefox/126.0' http_user_agent='Mozilla/5.0 (Macintosh; Intel Mac OS X 14.5; rv:127.0) Gecko/20100101 Firefox/127.0' ------------------------------ Just make sure there are no blank lines or comments in agents.txt Anyway, hopefully this will be useful to someone. Enjoy :) -Alex
On Mon, 8 Jul 2024 14:50:08 +0200 <a1ex@dismail.de> wrote:
Hi list,
Here is a simple script which runs Dillo with a random user agent on each run. I've been using it for a long time with no issues. It would be interesting to have similar functionality built-in to Dillo at some point, at least for me.
...
Just to add to this, have you considered the idea of a user agent switcher in Dillo? It would be neat to be able to choose from different profiles and have them applied in real-time without having to restart the browser. For example, the profiles could be something like: 'Default', 'Desktop', 'Mobile', 'Random' I think this could be a valuable feature for many users. I know you have a lot on your plate, but just wanted to throw the idea out there. Thanks, Alex
Hi Alex, On Tue, Jul 09, 2024 at 12:31:29PM +0200, a1ex@dismail.de wrote:
On Mon, 8 Jul 2024 14:50:08 +0200 <a1ex@dismail.de> wrote:
Hi list,
Here is a simple script which runs Dillo with a random user agent on each run. I've been using it for a long time with no issues. It would be interesting to have similar functionality built-in to Dillo at some point, at least for me.
...
Thanks!, I think is a good idea to reduce fingerprinting in Dillo. Have you considered also removing the user agent header completely? I work under the assumption that each Dillo user is uniquely identifiable based on non-JS enabled, other HTTP headers, TLS behavior, TCP and network timing leaked details, unless I have evidence that suggests otherwise. I don't think the web is designed to keep users anonymous and there is only so much we can do. However, I would appreciate efforts towards reducing the fingerprinting information we are leaking. It would be nice to be able to measure it somehow, but I only find JS enabled fingerprinting estimation tests online.
Just to add to this, have you considered the idea of a user agent switcher in Dillo? It would be neat to be able to choose from different profiles and have them applied in real-time without having to restart the browser. For example, the profiles could be something like:
'Default', 'Desktop', 'Mobile', 'Random'
I thought about something like this but for the CSS media selector, not so much for the user agent. I'm not sure if switching the user agent among desktop/mobile would have a measurable effect on the page content. If you want to reduce information leaked by Dillo that can identify a user, I think a good strategy is first to make a service that can measure this information among Dillo users and show the differences it can find among users, much like the EFF does[1]. Maybe we can work with the EFF to improve the support for non-JS browsers, so we can benefit from their pool of users to estimate uniqueness. [1]: https://coveryourtracks.eff.org/ We can also make it cooperate with a Dillo plugin that can have access to network TCP packets and timing information on both ends to emulate an state actor, so we can estimate how much information is being leaked and how much we are reducing it. This is probably something that we may want to bring up to the Tor team to see which strategies the did for the Tor Browser and which ones we can apply to Dillo. See also: https://github.com/dillo-browser/dillo/issues/135 Best, Rodrigo.
Hi Rodrigo, On Sat, 13 Jul 2024 09:54:11 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
Thanks!, I think is a good idea to reduce fingerprinting in Dillo. Have you considered also removing the user agent header completely?
Yes, I ran with no user agent for quite a while in the past, but found that certain sites refused to serve content without it.
I work under the assumption that each Dillo user is uniquely identifiable based on non-JS enabled, other HTTP headers, TLS behavior, TCP and network timing leaked details, unless I have evidence that suggests otherwise.
Probably a good assumption, however I suspect that many sites aren't so advanced and mainly use JS, headers, and IP address for fingerprinting. Randomizing some of the headers may still be valuable.
Just to add to this, have you considered the idea of a user agent switcher in Dillo? It would be neat to be able to choose from different profiles and have them applied in real-time without having to restart the browser. For example, the profiles could be something like:
'Default', 'Desktop', 'Mobile', 'Random'
I thought about something like this but for the CSS media selector, not so much for the user agent. I'm not sure if switching the user agent among desktop/mobile would have a measurable effect on the page content.
I don't know about recently, but in the past certain sites would serve a more Dillo-friendly page if you used a mobile agent like: http_user_agent="Opera/9.60 (J2ME/MIDP; Opera Mini/4.2.13337/458; U; en) Presto/2.2.0" or http_user_agent="Mozilla/5.0 (PSP (PlayStation Portable); 2.00)" Of course those are VERY outdated examples, and are probably no longer effective. I still think that a mobile user agent could cause certain sites to work better, but this would take further study to prove value.
If you want to reduce information leaked by Dillo that can identify a user, I think a good strategy is first to make a service that can measure this information among Dillo users and show the differences it can find among users, much like the EFF does[1]. Maybe we can work with the EFF to improve the support for non-JS browsers, so we can benefit from their pool of users to estimate uniqueness.
[1]: https://coveryourtracks.eff.org/
We can also make it cooperate with a Dillo plugin that can have access to network TCP packets and timing information on both ends to emulate an state actor, so we can estimate how much information is being leaked and how much we are reducing it.
This is probably something that we may want to bring up to the Tor team to see which strategies the did for the Tor Browser and which ones we can apply to Dillo.
I like the idea of emulating the Tor Browser fingerprint, however there could be scenerios where this is undesireable, and may actually draw more attention. Regards, Alex
On Sat, 13 Jul 2024 09:54:11 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
I work under the assumption that each Dillo user is uniquely identifiable based on non-JS enabled, other HTTP headers, TLS behavior, TCP and network timing leaked details, unless I have evidence that suggests otherwise.
I was doing some tests on browserleaks.com with TLS fingerprinting. https://tls.browserleaks.com/iframe/ja3_hash On Dillo with LibreSSL, this hash changes every time I reload the page. On Firefox (which uses NSS), the hash stays the same. I don't know if I understand fully, but it seems like LibreSSL is resistant to this type of fingerprinting. Regards, Alex
Hi, On Sat, Jul 13, 2024 at 08:03:13PM +0200, a1ex@dismail.de wrote:
I was doing some tests on browserleaks.com with TLS fingerprinting.
https://tls.browserleaks.com/iframe/ja3_hash
On Dillo with LibreSSL, this hash changes every time I reload the page. On Firefox (which uses NSS), the hash stays the same. I don't know if I understand fully, but it seems like LibreSSL is resistant to this type of fingerprinting.
Very nice discovery. I can also reproduce the same behavior with LibreSSL, but with OpenSSL it stays the same. Unfortunately, the JA3n hash stays the same for LibreSSL. I also found a way to access the "raw" data in JSON using: https://tls.browserleaks.com/tls With this little patch, the response can be shown in Dillo too: --8<-- diff --git a/src/IO/mime.c b/src/IO/mime.c index 9d5e6738..2361a459 100644 --- a/src/IO/mime.c +++ b/src/IO/mime.c @@ -112,6 +112,9 @@ void a_Mime_init() /* Add a major type to handle all the text stuff */ Mime_add_major_type("text", a_Plain_text); + + /* Display JSON as plain text too */ + Mime_add_major_type("application/json", a_Plain_text); } --8<-- There is also JA4[1,2], which can be displayed here: https://ja4db.com/id/ja4/ https://ja4db.com/id/ja4h/ [1]:https://developers.cloudflare.com/bots/concepts/ja3-ja4-fingerprint/ [2]:https://github.com/FoxIO-LLC/ja4 Both JA4 hashes seem to stay the same on reloading the page using LibreSSL. Best, Rodrigo.
On Sun, Jul 14, 2024 at 03:41:25PM +0200, Rodrigo Arias wrote:
--8<-- diff --git a/src/IO/mime.c b/src/IO/mime.c index 9d5e6738..2361a459 100644 --- a/src/IO/mime.c +++ b/src/IO/mime.c @@ -112,6 +112,9 @@ void a_Mime_init() /* Add a major type to handle all the text stuff */ Mime_add_major_type("text", a_Plain_text); + + /* Display JSON as plain text too */ + Mime_add_major_type("application/json", a_Plain_text);
This should be Mime_add_minor_type() not major ^^'. I opened a PR: https://github.com/dillo-browser/dillo/pull/224 Rodrigo.
participants (2)
-
a1ex＠dismail.de -
Rodrigo Arias