- Dillo-dev - lists.mailman3.com

[PATCH] Toolbar zoom control button

by a1ex＠dismail.de

Hi list, Here is an improved version of my previous patch. The icon is fixed, it's basic but does the job. If someone wants to make a prettier one, I'm open to it. Other improvements as discussed with Rodrigo: - Middle click resets zoom level - There is now a 'show_zoom' preference in dillorc (enabled by default) - The save button has been disabled by default - The zoom button has been moved to the right of the refresh button Please let me know if you find any issues, and hope you enjoy it :) Regards, Alex diff -upr a/dillorc b/dillorc --- a/dillorc Sun Jul 14 18:25:44 2024 +++ b/dillorc Sun Jul 14 18:25:59 2024 @@ -366,7 +366,8 @@ ui_tab_bg_color=#b7beb7 #show_forw=YES #show_home=YES #show_reload=YES -#show_save=YES +#show_zoom=YES +#show_save=NO #show_stop=YES #show_bookmarks=YES #show_tools=YES diff -upr a/src/pixmaps.h b/src/pixmaps.h --- a/src/pixmaps.h Sun Jul 14 18:25:44 2024 +++ b/src/pixmaps.h Sun Jul 14 18:25:59 2024 @@ -809,6 +809,35 @@ static const char *const tools_xpm[] = { " -&X6&=# ", " "}; +/* XPM */ +static const char *const zoom_xpm[] = { +"22 22 3 1", +" c None", +"1 c #B3B3B3", +"2 c #000000", +" 111111 ", +" 1122222211 ", +" 122 221 ", +" 12 21 ", +" 12 21 ", +" 12 11 21 ", +" 12 1221 21 ", +" 12 1221 21 ", +"12 1221 21", +"12 1111221111 21", +"12 122222222221 21", +"12 122222222221 21", +"12 1111221111 21", +"12 1221 21", +" 12 1221 21 ", +" 12 1221 21 ", +" 12 11 21 ", +" 12 21 ", +" 12 2221 ", +" 122 2211221 ", +" 1122222211 1221", +" 111111 122"}; + /* Small icons here */ /* XPM */ @@ -1408,6 +1437,29 @@ static const char *const tools_s_xpm[] = { " u-%#*%0", " feww0g" }; + +/* XPM */ +static const char *const zoom_s_xpm[] = { +"16 16 3 1", +" c None", +"1 c #000000", +"2 c #B3B3B3", +" 222222 ", +" 21111112 ", +" 21 12 ", +" 21 22 12 ", +" 21 2112 12 ", +"21 2112 12", +"21 22211222 12", +"21 2111111112 12", +"21 2111111112 12", +"21 22211222 12", +" 21 2112 12 ", +" 21 2112 122 ", +" 21 22 11112", +" 211111122111", +" 222222 211", +" 22"}; /* XPM */ static const char *const new_s_xpm[] = { diff -upr a/src/prefs.c b/src/prefs.c --- a/src/prefs.c Sun Jul 14 18:25:44 2024 +++ b/src/prefs.c Sun Jul 14 18:25:59 2024 @@ -103,7 +103,8 @@ void a_Prefs_init(void) prefs.show_progress_box = TRUE; prefs.show_quit_dialog = TRUE; prefs.show_reload = TRUE; - prefs.show_save = TRUE; + prefs.show_zoom = TRUE; + prefs.show_save = FALSE; prefs.show_url = TRUE; prefs.show_search = TRUE; prefs.show_stop = TRUE; diff -upr a/src/prefs.h b/src/prefs.h --- a/src/prefs.h Sun Jul 14 18:25:44 2024 +++ b/src/prefs.h Sun Jul 14 18:25:59 2024 @@ -81,6 +81,7 @@ typedef struct { bool_t show_forw; bool_t show_home; bool_t show_reload; + bool_t show_zoom; bool_t show_save; bool_t show_stop; bool_t show_bookmarks; diff -upr a/src/prefsparser.cc b/src/prefsparser.cc --- a/src/prefsparser.cc Sun Jul 14 18:25:44 2024 +++ b/src/prefsparser.cc Sun Jul 14 18:25:59 2024 @@ -213,6 +213,7 @@ void PrefsParser::parse(FILE *fp) { "show_progress_box", &prefs.show_progress_box, PREFS_BOOL, 0 }, { "show_quit_dialog", &prefs.show_quit_dialog, PREFS_BOOL, 0 }, { "show_reload", &prefs.show_reload, PREFS_BOOL, 0 }, + { "show_zoom", &prefs.show_zoom, PREFS_BOOL, 0 }, { "show_save", &prefs.show_save, PREFS_BOOL, 0 }, { "show_url", &prefs.show_url, PREFS_BOOL, 0 }, { "show_search", &prefs.show_search, PREFS_BOOL, 0 }, diff -upr a/src/ui.cc b/src/ui.cc --- a/src/ui.cc Sun Jul 14 18:25:44 2024 +++ b/src/ui.cc Sun Jul 14 18:25:59 2024 @@ -38,7 +38,7 @@ struct iconset { Fl_Image *ImgMeterOK, *ImgMeterBug, - *ImgHome, *ImgReload, *ImgSave, *ImgBook, *ImgTools, + *ImgHome, *ImgReload, *ImgZoom, *ImgSave, *ImgBook, *ImgTools, *ImgClear,*ImgSearch, *ImgHelp, *ImgLeft, *ImgLeftIn, *ImgRight, *ImgRightIn, *ImgStop, *ImgStopIn; }; @@ -48,6 +48,7 @@ static struct iconset standard_icons = { new Fl_Pixmap(mini_bug_xpm), new Fl_Pixmap(home_xpm), new Fl_Pixmap(reload_xpm), + new Fl_Pixmap(zoom_xpm), new Fl_Pixmap(save_xpm), new Fl_Pixmap(bm_xpm), new Fl_Pixmap(tools_xpm), @@ -67,6 +68,7 @@ static struct iconset small_icons = { standard_icons.ImgMeterBug, new Fl_Pixmap(home_s_xpm), new Fl_Pixmap(reload_s_xpm), + new Fl_Pixmap(zoom_s_xpm), new Fl_Pixmap(save_s_xpm), new Fl_Pixmap(bm_s_xpm), new Fl_Pixmap(tools_s_xpm), @@ -356,6 +358,15 @@ static void b1_cb(Fl_Widget *wid, void *cb_data) wid->y() + wid->h()); } break; + case UI_ZOOM: + if (b == FL_LEFT_MOUSE) { + a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_RIGHT_MOUSE) { + a_UIcmd_zoom_out(a_UIcmd_get_bw_by_widget(wid)); + } else if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_zoom_reset(a_UIcmd_get_bw_by_widget(wid)); + } + break; default: break; } @@ -429,6 +440,7 @@ void UI::make_toolbar(int tw, int th) Forw = make_button("Forw", icons->ImgRight, icons->ImgRightIn, UI_FORW); Home = make_button("Home", icons->ImgHome, NULL, UI_HOME); Reload = make_button("Reload", icons->ImgReload, NULL, UI_RELOAD); + Zoom = make_button("Zoom", icons->ImgZoom, NULL, UI_ZOOM); Save = make_button("Save", icons->ImgSave, NULL, UI_SAVE); Stop = make_button("Stop", icons->ImgStop, icons->ImgStopIn, UI_STOP); Bookmarks = make_button("Book", icons->ImgBook, NULL, UI_BOOK); @@ -438,6 +450,7 @@ void UI::make_toolbar(int tw, int th) Forw->set_tooltip("Next page"); Home->set_tooltip("Go to the Home page"); Reload->set_tooltip("Reload"); + Zoom->set_tooltip("Zoom: left-click, Zoom out: right-click, Reset: middle"); Save->set_tooltip("Save this page"); Stop->set_tooltip("Stop loading"); Bookmarks->set_tooltip("View bookmarks"); @@ -952,6 +965,8 @@ void UI::customize() Home->hide(); if ( !prefs.show_reload ) Reload->hide(); + if ( !prefs.show_zoom ) + Zoom->hide(); if ( !prefs.show_save ) Save->hide(); if ( !prefs.show_stop ) diff -upr a/src/ui.hh b/src/ui.hh --- a/src/ui.hh Sun Jul 14 18:25:44 2024 +++ b/src/ui.hh Sun Jul 14 18:25:59 2024 @@ -19,6 +19,7 @@ typedef enum { UI_FORW, UI_HOME, UI_RELOAD, + UI_ZOOM, UI_SAVE, UI_STOP, UI_BOOK, @@ -124,7 +125,7 @@ class UI : public CustGroupVertical { CustTabs *Tabs; CustGroupVertical *TopGroup; - CustButton *Back, *Forw, *Home, *Reload, *Save, *Stop, *Bookmarks, + CustButton *Back, *Forw, *Home, *Reload, *Zoom, *Save, *Stop, *Bookmarks, *Tools, *Clear, *Search, *Help, *BugMeter, *FileButton; CustGroupHorizontal *LocBar, *NavBar, *StatusBar; Fl_Input *Location;

July 14, 2024

Re: Fingerprinting with JA3 and JA4 hashes

by Rodrigo Arias

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.

July 14, 2024

Re: Fingerprinting with JA3 and JA4 hashes

by Rodrigo Arias

Hi, On Sat, Jul 13, 2024 at 08:03:13PM +0200, a1ex(a)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.

July 14, 2024

Re: [SCRIPT] Run Dillo with a random user agent

by a1ex＠dismail.de

On Sat, 13 Jul 2024 09:54:11 +0200 Rodrigo Arias <rodarima(a)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

July 13, 2024

Re: [PATCH] Toolbar button to control zoom level

by a1ex＠dismail.de

On Sat, 13 Jul 2024 11:07:10 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > >all that is needed now is the 'magnifying glass' icon above the word > >Zoom 'borrowed' from the 'search button' :) > > There is a button there, but with the default Dillo options the color > of the icon is very similar to the background (attached screenshot) > and is barely visible. I think Alex may be using a different color > scheme. You are correct. The patch was just a proof of concept, and I didn't spend too much time on the icon. Since there appears to be interest in this feature, I will work on a more complete patch which will address that, and the items mentioned below. > I'm thinking if we could hide the save button by default and put the > zoom there instead, as save is available from the page menu either > way, and I think the zoom button would be used more frequently. > > We probably should add a "show_zoom" preference too in dillorc. Also > we may want to use the middle click to reset the zoom level. Agreed! Thanks, Alex

July 13, 2024

Re: Option to define external link handler

by Rodrigo Arias

Hi Diego On Sat, Jul 13, 2024 at 01:36:19PM +0200, Diego wrote: >I think a good way is to reduce functionality to a minimum. Not to make a >full scripting language, but rather moderately complex hook rules that can >call external scripts or DPIs with complex functionality. This is not a scripting language, just a way to describe rules that can be transformed in quick operations at runtime. We won't be reinventing JS. >Another mistake that can be made is to replace the DPI infrastructure. I >think a cooperation between the two is better. There is no plan to remove the support for DPI plugins, just to increase the capabilities for hooking. >DPIs and authorized scripts can set temporary rules and be called by dillo >on events. >Fixed rules in a rules file call complex scripts or DPIs. That's more or less the idea. >The problem with the DPI infrastructure is that it is an unfinished >infrastructure with very little documentation. There are other structural problems, please check the related issues. https://github.com/dillo-browser/dillo/issues/65 https://github.com/dillo-browser/dillo/issues/56 Best, Rodrigo.

July 13, 2024

Re: [SCRIPT] Run Dillo with a random user agent

by a1ex＠dismail.de

Hi Rodrigo, On Sat, 13 Jul 2024 09:54:11 +0200 Rodrigo Arias <rodarima(a)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

July 13, 2024

Re: Option to define external link handler

by Diego

El sáb, 13 jul 2024 a las 10:01, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > On Mon, Jul 08, 2024 at 09:59:20AM +1000, Kevin Koster wrote: > >That would be great. Provided it doesn't actually end up as complicated > >as iptables configuration of course. :) > > Yeah, I'll have to think how to avoid that too :-) > > I'm putting my thoughts into an RFC here: > > > https://github.com/dillo-browser/rfc/blob/rfc-002/rfc-002-rule-based-conten… > > (On Dillo it renders ok without remote CSS) > > Let's see if I can keep it simple. > > Rodrigo. > I think a good way is to reduce functionality to a minimum. Not to make a full scripting language, but rather moderately complex hook rules that can call external scripts or DPIs with complex functionality. Another mistake that can be made is to replace the DPI infrastructure. I think a cooperation between the two is better. DPIs and authorized scripts can set temporary rules and be called by dillo on events. Fixed rules in a rules file call complex scripts or DPIs. The problem with the DPI infrastructure is that it is an unfinished infrastructure with very little documentation. For example: uncontrolled mime types can be implemented by sending a DPI command to the DPI service "mime.<mime_type_name>" and using the same functions as vsource. To handle, for example, text/markdow or image/webp, put mime.text/markdown=... and mime.imge/webp=... in dpidrc. I think this is the only way to have a lightweight device with more functionality loaded only when used. (Sorry for my English. My native language is Spanish) Diego Sáenz

July 13, 2024

Re: [PATCH] Toolbar button to control zoom level

by Rodrigo Arias

Hi, > Here is an updated patch with a better icon and fixed tooltip. > Hopefully somebody finds it useful :) Thanks! I applied it from the attached file, like this: $ cd src $ md5sum /tmp/zoom-button.patch c8d48b41f30ba889ddd610860ecdc310 /tmp/patches/zoom-button.patch $ patch -p1 < /tmp/zoom-button.patch patching file pixmaps.h patching file ui.cc patching file ui.hh In the future, please perform the diffs from the top level directory, like so: $ diff -up dillo-orig/ dillo-mod/ (Or better, via "git format-patch" if you use git) >all that is needed now is the 'magnifying glass' icon above the word >Zoom 'borrowed' from the 'search button' :) There is a button there, but with the default Dillo options the color of the icon is very similar to the background (attached screenshot) and is barely visible. I think Alex may be using a different color scheme. I'm thinking if we could hide the save button by default and put the zoom there instead, as save is available from the page menu either way, and I think the zoom button would be used more frequently. We probably should add a "show_zoom" preference too in dillorc. Also we may want to use the middle click to reset the zoom level. Best, Rodrigo.

July 13, 2024

Re: zoom needs scrolling to maintain center

by Rodrigo Arias

Hi, On Fri, Jul 12, 2024 at 11:18:11PM +0200, a1ex(a)dismail.de wrote: >On Fri, 12 Jul 2024 12:04:30 -0600 >pastebin(a)gmx.com wrote: > >> Hi >> >> with left mouse click on zoom button -> screen get bigger and screen >> slides down - so when leaves the viewport it needs a scroll up so >> center remains and zoom is userfull >> >> with right mouse click on zoom button -> screen get smaller and >> screen slides down - so when viewport is off the physical screena >> scroll down - do nothing when viewport is <= the physical screen > >Thats true. I think the zoom code right now just relies on a >StyleEngine action, which isn't really designed for that. What you >are suggesting would probably take quite a bit more work. I think we could approximate it by assuming that each element will be magnified by the same amount. Therefore, if you measure the distance in pixels of the current view from the top of the page, Y, and then you increase the zoom by a factor of 1.2, then you should scroll to 1.2*Y to compensate it. Here is a "graphical" visualization but in horizontal rather than vertically: 0 5 10 15 0 5 10 15 AAAABBBBCCCCDDDD --> AAAAABBBBBCCCCCDDDDD ^ ^ Y=10 x1.2 Y=12 This won't work with cases where the text is constrained into a container that has 100% width (or some other relative size), as it would change the breaking point of the lines, causing the scroll approximation to fail. A more accurate and complex approach is to take the position of some elements in the current view, and then try to locate them after zooming and then scroll there. I opened an issue here to track it: https://github.com/dillo-browser/dillo/issues/221 Rodrigo.

July 13, 2024