Search results for "plugin" - Dillo-dev

CAPI ignores download requests when not in cache or handled by the downloads DPI.

by p37sitdu＠lavabit.com

On Tue, Jan 01, 2013 at 10:30:04PM +0000, Jeremy Henty wrote: > > p37sitdu at lavabit.com wrote: > > > On Sun, Dec 30, 2012 at 05:23:18PM +0000, Jeremy Henty wrote: > > > > > > I wondered why "Save link as" silently failed on some of my local > > > web pages if I had not already visited the link. It turns out > > > they were "file:///" links and "Save link as" sends a download > > > request which the CAPI silently ignores if the URL is not cached > > > and is not handled by the downloads DPI. > > > [...] > > > > [...] > > Instead, Dillo could download files and pass them to downloads DPI. > > Downloads DPI then shows progress and saves files. As I understand, > > the idea is to have one window for all downloads across many copies > > of Dillo where progress can be shown and requests to cancel them can > > be passed to the right copy of Dillo. > > I wonder what is the real benefit of a separate downloads DPI. Is it > actually useful to have one downloads window for all Dillo processes? I think downloading should not be done by downloads DPI: this way it have to support all the protocols Dillo and its plugins support. But tracking of downloads can be left there so we don't see the difference between two dillo processes and two dillo windows. > The downloads DPI is rather different from all the rest: it is the > only one that links to FLTK and it doesn't send HTML back to Dillo. > Do we really benefit from putting downloading in a separate process? Cookies DPI doesn't send HTML too. Downloads and cookies are server DPIs, they are used to share resources between processes.

Jan. 2, 2013

patch: close windows from menubar

by Johannes.Hofmann＠gmx.de

On Thu, Oct 09, 2008 at 04:26:02PM -0400, Jorge Arellano Cid wrote: > On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote: > > On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote: > > > On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote: > > > > > > > ... why would you want dillo1 and dillo2 at the same time. > > > > > > I don't know. But when you start saying "No-one could *possibly* want > > > to do that, so let's stop supporting it" then you are riding for a > > > fall. Why make ourselves hostages to fortune? Why not make *sure* we > > > avoid the problem rather than gambling that we've second-guessed our > > > entire user base? Murphy's law applies, so play it safe unless > > > there's a compelling reason not to. > > > > You are adding the overhead of changing user behavior though. The claws > > backend might be a good reason, frankly it is the only one I see so far. > > OK, just checked Debian and Ubuntu and both have the dillo > viewer plugin for sylpheed with a dependency on the plain "dillo" > package. > > Looking around in the FLTK docs, there's this function: > > CreatedWindow::set_xid() > > It looks promising. Unfortunately I haven't found a full > code example to make it work. > > If somebody knows how to use it, it'd be simple to make a "drop > in" replacement for dillo1, and avoid the problems discussed in > this thread. I think it's supposed to work more or less like in attached test program. When called with a (decimal) window id (from xlsclients) it draws a small but visible frame on that window. I don't know why it doesn't work correctly. Probabely some more setup necessary... Cheers, Johannes

Oct. 10, 2008

Re: dns over tls or dns over https

by pastebin＠gmx.com

Thanks - good information are you getting my emails to your gmail email? suggestion add 'to search for mbed TLS only' to '--disable-openssl' switch :) why don't you like dnssec? On Sat, 1 Jun 2024 21:58:42 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Sat, Jun 01, 2024 at 01:27:07PM -0600, pastebin(a)gmx.com wrote: > >Hi > > > >could someone give me an idea about dillo using 'dns over tls' or 'dns > >over https'? or using dnssec? > > The mobilized fork has added support for it, as it is provided by > libcurl (which they have switched to): > > > 20240522: New tarball. To enable DNS-over-HTTPS (DoH), you can now set > > the preference dns_over_https_url. > > https://www.toomanyatoms.com/software/mobilized_dillo.html > > My recommendation is to setup a local resolver on your machine, so all > name resolution is handled by it, not just Dillo. Then you can use > whatever mechanism you want (DoH, DoT, DNSSEC...). > > This would be especially useful if you download a file with Dillo, as it > would launch an external wget process. Or if you use any plugin that > performs network operations on its own. > > Here are some docs (even if you don't use Arch): > > https://wiki.archlinux.org/title/DNS-over-HTTPS > https://wiki.archlinux.org/title/DNSSEC > > I didn't check on my own how well that works, but I would rather keep it > out of Dillo if posible. > > >what about dillo using mbed-tls vs openssl? > >the configuration only shows a --disable-mbedtls > > The DNS resolution is done prior to interacting with any TLS library. > There is also a --disable-openssl switch to search for mbed TLS only, > see ./configure --help. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

June 1, 2024

Future of dillo2

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Diego wrote: >> With my recent patch (dpid-cleanup-and-DPIPATH.dillo2) one can use the >> attached script to run dillo in-tree which is nice if you just want to >> try it out but should also be useful for development purposes (easily >> manage different branches without the need to install them somewhere). > > The patch seems good to me, but i have not look it very deep or test it. Some more testing turned out that it's not enough to add another path to search for dpis. With no dpidrc fill_services_list fails: [dpid]: dpid.c:467: fill_services_list: Fatal error [dpid]: - Can't find the directory for dpis. This seems very non-plugin-like to me. What's the point in being able to have dpis in ~/.dillo/... but to actually use them you have to add them to your ~/.dillo/dpidrc. I mean it's okay up to this point, but consider you have one custom dpi in ~/.dillo/... : * in order to use it you have to create a custom dpidrc too * judging by a quick look at dpid.c/register_service I'd say that you have to copy the content of the system wide dpidrc file too since your custom one takes preference over the system wide one * now there's a package installed containing one more dpi. It might be doable to update the system wide dpidrc via a post-install script within the package (though thats error prone, you have to remove your entries on package removal etc.) * but what about the custom dpircs? You cannot have the post-install script modify those as well (well, you could, but naaa) > The idea is that each dpi can have its own files in its directory > (preferences, data, cache files ... ). I could go with preferences and data files, but caching feels like a no-no to me since on most installations the user is unable to write into those directories. Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKgZ9oPmwNWhsaZYRAjL+AJ9SjhWBUNh5WcO51GkJLaqtDyjFEwCeMQkz jkTcvl8xIbP3EedZP8T72fc= =xAX5 -----END PGP SIGNATURE-----

May 13, 2008

web bug save?

by Johannes.Hofmann＠gmx.de

On Fri, Dec 25, 2009 at 05:46:22PM +0000, corvid wrote: > bb wrote: > > *On http://www.dillo.org/ I found the item News and a remark: > > > > 03-Jul-2009 Dillo-2.1.1 has been released to provide a security fix for > > malicious images. I am not shure what is meant with **malicious images? > > Are this so called Web bugs? If yes - how is the blocking done? > > Here's the advisory about the image size problem: > http://www.ocert.org/advisories/ocert-2009-008.html > > > I think there are some strategies possible to prevent a browser from a > > Web Bug attack: > > > > 1. Dont allow to load gifs or pngs from another URL as the actual page > > comes from. (I think to remember that firefox **originally **had such an > > option - not available in the actual version.) > > Here's the beginning of a thread and a patch experimenting with this: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.ht… > (the "same host" option was found to be useless, but I'm still interested in > "same domain") > > > 2. I think one might prepare HTML/CSS not to load such gifs or pngs > > smaller than say about 5x5. Do you think such a measure is feasible in > > Dillo and could that really stop Web Bugs? But I think that there should > > not be a problem to make Web Bugs larger than 1x1pixel as long as they > > are transparent - may be I am wrong, I am just a simple minded user, not > > a web professional. So such a limit might be useless? > > Here's a post and patch experimenting with rejecting images with a dimension > of 0: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007101.html > > > Are there other ideas? I am highly interested in that Web Bug problem. > > I'm glad to hear this, since user interest may encourage things to happen... > Absolutely. We really need to address this. Maybe we can do some more research again about what other browsers or plugins do about this. Cheers, Johannes

Dec. 26, 2009

SSL in the browser

by james.from.wellington＠gmail.com

I've got gmail going, using the ~/.dillo/certs certificate store. It took a bit of poking around, so I'm attaching my notes to myself in case they're useful for someone else. On 10/23/14, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: > On Tue, Oct 21, 2014 at 04:42:24PM +0000, eocene wrote: >> Jorge wrote: >> > Oh, as our mailsearch doesn't work anymore, is there >> > and URL to the original thread (Gmane style) or something? >> > >> > I'd like to remember what the main point of having SSL inside >> > the browser were. I'm getting old. ;) >> >> Looking briefly, I couldn't find relevant discussion. Possibly it >> was off list. My recollection is that, at the time, it had to do with >> seeing how SSL was becoming more and more central to browsing with >> things like 'HTTPS Everywhere' and 'HTTP Strict Transport Security' >> coming along and the issue of privacy gaining increasing public >> awareness. >> >> As for this effort now, I started just by wondering what it would >> look like if I integrated Benjamin's code and took out the windows >> stuff. It was working pretty well very quickly. And now I like how >> much more respectful of servers and resources Dillo can be when >> HTTPS is integrated with the http_max_conns queuing and >> http_persistent_conns. I think Johannes mentioned something about >> Dillo and Tor not working together so well with HTTPS in a dpi, >> but I don't know the details there. > > There is a potential loophole if you start dillo in a torified > environment and dpid is running outside. Then https connections go > via the non-torified https plugin. It's a small detail, but it > happened to me. > I'm mostly interested in getting SSL support from unmaintained > experimental state to properly supported and maintained option. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Oct. 26, 2014

Re: Does :hover work in 3.1.1?

by Steinar Bang

>>>>> Rodrigo Arias <rodarima(a)gmail.com>: > You may want to check: > https://dillo-browser.github.io/dillo.org.html > And: > https://dillo-browser.github.io/release/3.1.0/ Right! I knew that actually, from the mastodon post that brought dillo back into my attention. But when looking for stuff I am lazy and I google rather than remembering, and google still throw up the old pages. I'll link to the updated dillo doc from the oldalbum README when I release the non-javascript version. That should help the teensiest bit, at least (also it's a place I can click to to get there). >> If :hover doesn't work I will have to do it a different way: maybe with >> a separate settings page containing a form...? > I recommend you just don't use a drop down, just an static navigation > menu which would work fine with CSS disabled. Yup, the simplest way would be to have just two links in the <nav> one for each locale/language. But that would be too much clutter, I think...? > You could also use a <select> input with a form but it looks more > complicated. Yes, it is. But it's the road I've started to travel. :-) (remains to see if I will travel it to the end or cut my losses and do something simpler...:-) ) I have some copy-pastable code. I did the authservice login and basic self-service pages non-javascript (authservice started as a forms based login plugin for nginx, using apache shiro), and I have stuff I can copy paste from there: https://github.com/steinarb/authservice I don't like JSP or JSF (feels complicated and cluttered) so I did a simple DIY templating with jersey and jsoup (I write HTML pages and read them into jersey resources with jsoup and replace elment content and fill forms). I was looking for sort of the same feel I had when using CGI.pm back in the day: the state is contained in the form data and used to populate the form in the returned HTML, and jsoup gave me that. The use of jersey is because JAX-RS gives a convenient API to tailor responses (HTTP headers and stuff).

July 27, 2024

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > is not in the default linker path, making the build abort. Add > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > but it turned out that the problem was caused by a libiconv > > > package that was no longer needed. The iconv stuff is now handled > > > in libc on DragonFly... > > > > I have attached the log. Seems like the function signature differs > > on OpenBSD a bit. The testcase modified as such that it includes > > <iconv.h> and calling iconv_open("",""); works for me when doint > > it manually. > > > > I don't know what happens here... > > > > Kind regards, > > Does it fail with current CVS? Sorry, from the log it's clear it doesn't. This page seems to have good info: http://synflood.at/blog/index.php?/plugin/tag/bsd (my understanding of German is barely for survival. ;). -- Cheers Jorge.-

Jan. 30, 2008

dillo-2.1.tar.bz2

by jcid＠dillo.org

Hi, Working on: 1.- Solve the OpenSSL license issue and upload rc3. On Thu, Jun 18, 2009 at 05:24:25PM +0200, Devid Antonio Filoni wrote: > On Wed, Jun 17, 2009 at 11:45 PM, Jorge Arellano Cid<jcid(a)dillo.org> wrote: > > On Wed, Jun 17, 2009 at 10:01:12PM +0200, Devid Antonio Filoni wrote: > > [...] > > ?Devid: please send me the .deb and its directions when done. > DONE! You can find it at https://launchpad.net/~d.filoni/+archive/ppa > . However I found an error checking my package using lintian: > > E: dillo: possible-gpl-code-linked-with-openssl > N: > N: This package appears to be covered by the GNU GPL but depends on the > N: OpenSSL libssl package and does not mention a license exemption or > N: exception for OpenSSL in its copyright file. The GPL (including version > N: 3) is incompatible with some terms of the OpenSSL license, and therefore > N: Debian does not allow GPL-licensed code linked with OpenSSL libraries > N: unless there is a license exception explicitly permitting this. > N: > N: If only the Debian packaging, or some other part of the package not > N: linked with OpenSSL, is covered by the GNU GPL, please add a lintian > N: override for this tag. Lintian currently has no good way of > N: distinguishing between that case and problematic packages. > N: > N: Severity: serious, Certainty: wild-guess > > Can you please fix it? AFAIS, the only program that links to OpenSSL is the https dpi. i.e. The ssl-enabled dillo binary doesn't link to it. https.filter.dpi links to it. IANAL, but it looks like giving permission for this dpi is enough, and it's already done in its sources (dpi/https.c): * [...] * As a special exception permission is granted to link the code of * the https dillo plugin with the OpenSSL project's "OpenSSL" * library, and distribute the linked executables, without including * the source code for OpenSSL in the source distribution. You must * obey the GNU General Public License, version 3, in all respects * for all of the code used other than "OpenSSL". * */ Please let me know if this is _really_ enough or if some extra legal formula must be added somewhere else. TIA. -- Cheers Jorge.-

June 18, 2009

dillo 2.1

by Johannes.Hofmann＠gmx.de

Hi Tomas, On Mon, Jun 22, 2009 at 05:12:07PM +0300, Tomas R wrote: > Been testing dillo 2.1 for some time and would like to share my > experience. > > It's really great to see some basic css support (appearance of most if > not all websites has improved alot), properly resized images, > redirection and basic authentication working now :) > > Anyway, even dillo improved alot recently there still seems to be some > issues. Here are some I've noticed after testing this release for few > days: > Rendering > 1) ubuntu.lt > Not sure if it's dillo fault or website's malformed stylesheet, but > with default dillo settings some of the lithuanian characters are not > displayed. This can be fixed by just adding "* {font-family: > serif !important}" to the style.css. Here is a pic with some of the > places where letters are missing marked in red: > http://img4.imageshack.us/img4/2227/ubuntult.png I guess the problem is that the font simply does not contain those glyphs. There are some rules how this case should be handled, but dillo does not implement them currently. > 2) gmail > It's nice that login works now, but with default dillo settings the > size of most of the text is 1px. This can be partially fixed by adding > font_min_size to dillorc, but it's obviously a dillo bug as this > doesn't happen with links-hacked. I don't have a gmail account, so I can't reproduce it, but there seems to be a general bug in the CSS code that makes fonts smaller than in other browsers. > 3) google > What's with the textarea in the top left corner of the page? And just > for information: signing out doesn't work because it requires basic > javascript support (works with links-hacked). That textarea is in the google page. It's just hidden due to a "display: none" CSS directive which is not supported yet by dillo. Actually I'd like to know the reason why it is there before hiding it. > 4) Black on black, white on white... > http://www.nma-fallout.com/forum/viewtopic.php?t=42776&start=2660&sid=a5712… > For some reason black font color is used here and we get black text on > black background in some posts (doesn't happen with links-hacked). Oh. This is just horrible HTML / CSS, it's full of bugs! The reason for black on black is: <body bgcolor="#000000" text="#C0C0C0" link="#33CC00" vlink="#33CC00" /> I.e. body is immediately closed. But there is tons of other bugs on this page. > http://www.acetoneteam.org/ > Background color is not set here and if we have "body > {background-color: white}" rule in our style.css file, we get white > text on white background. dillo does not handle color definitions of the form rgb(255,255,255) yet. I guess we can fix that. > 5) http://ubuntuforums.org/showthread.php?p=6592005 > What's with the PINK blocks? If that's more of a "feature" then a bug, > can the color be changed by using some css rule? I can't find pink blocks on that page. Where exactly do you see them? Maybe post a screenshot. > 6) http://www.binaryworld.skynet.lt/DUK.html > If we use one link with fragment identifier in the page, all the others > are marked as visited too. Not sure how this should be handled correctly. Someone will have to check the specs. > 7) Authentication > Basic authentication does work now, but at first the server displays a > message saying "wrong credentials or browser doesn't > understand how to supply the credentials" and only then a window > pops up asking for the credentials... > > UI > 1) Positioning the tab close button on the top RIGHT corner of the > browser isn't a good thing because: > a) The distance between the most commonly used buttons and the tab > close button is pretty big (especially when widescreen monitors are > pretty common nowadays); > b) It only allows closing the active tab; > I think it would be much better if all tabs had close buttons or at > least the button was placed near the last tab. Agreed. Patch welcome :) > 2) Trivial but... because the setting to enable/disable image loading > now is in the wrench menu it is two clicks away instead of one as it > used to be in dillo 2.0. Maybe css settings could be left where they are > now, but the setting for enabling/disabling images could be moved where > it was in dillo 2.0? > 3) UPPERCASE letters should be used in the File menu to define keyboard > shortcuts, because now L looks like I (Open url... ctrl+l) > 4) Don't you think "Are you sure you want to close the browser?" > message is pretty annoying? Which one exactly? When exiting dillo with multiple tabs/windows open? I don't think dillo asks a lot for confirmation, but I normally use multiple Ctrl-q's to close all tabs and windows and quit. > > Other: > It seems whoever designed the new website theme has no idea what > READABILITY means... It looks like someone just used some stupid online > color picker, which just picks some similar colors to the one user > chooses. The old website looked MUCH MUCH better. Imho, it's a > regression... Hm I like the new design, but I agree that readability might be a problem. Let's see what other say. > > PS: how to install dillo 2.1 claws-mail plugin? Just install claws and the dillo plugin from source or packages depending on your distribution. Then make sure that dillo-2.1 is the dillo binary in your PATH. Cheers, Johannes

June 22, 2009

Dillo-dev search results for query "plugin"