- Dillo-dev - lists.mailman3.com

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

Re: Option to define external link handler

by Rodrigo Arias

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.

July 13, 2024

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

by Rodrigo Arias

Hi Alex, On Tue, Jul 09, 2024 at 12:31:29PM +0200, a1ex(a)dismail.de wrote: >On Mon, 8 Jul 2024 14:50:08 +0200 ><a1ex(a)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.

July 13, 2024

Re: zoom needs scrolling to maintain center

by pastebin＠gmx.com

isn't there already a scroll up/scroll down command like zoom_in/zoom_out } else if (cmd == KEYS_ZOOM_IN) { a_UIcmd_zoom_in(a_UIcmd_get_bw_by_widget(this)); a_UIcmc_scroll_up(number_lines); <-- ret = 1; On Fri, 12 Jul 2024 23:18:11 +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. > > Dillo needs contributors who can offer patches and support. Please lets > try to pick our battles carefully in order to not overwhelm the already > very busy developer. > > -Alex > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 12, 2024

Re: zoom needs scrolling to maintain center

by a1ex＠dismail.de

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. Dillo needs contributors who can offer patches and support. Please lets try to pick our battles carefully in order to not overwhelm the already very busy developer. -Alex

July 12, 2024

zoom needs scrolling to maintain center

by pastebin＠gmx.com

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 ---

July 12, 2024

dillo css

by pastebin＠gmx.com

Hi the attached html with css that does dropdown box renders fine with seamonkey with the ~/.dillo/style.css or tools/use embedded css it partially succeeds but the drop down fails i have an old dillo css html help file (looks like from 2005) titled Dillo Web Browser :: Cascading Style Sheets and what the current dillo user manual (generated for version 3.1.1) has in it for css any further 3.1.1 css info/help pages? these are quite complicated coding dillo-3.1.1/src/cssparser.cc dillo-3.1.1/src/css.cc

July 11, 2024