Search results for "plugin" - Dillo-dev

SSL in the browser

by johannes.hofmann＠gmx.de

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

Oct. 23, 2014

Re: Towards 3.2.0

by Kevin Koster

Rodrigo Arias wrote: > > actions="default Open with external tool" > actions="firefox Open with Firefox" > actions="mpv Open with MPV" > actions="mpv-audio Open with MPV (audio)" > handler="/bin/the-handler" One action which would probably complicate things, but likely be among the most used for me, would actually be something like "View as text" (in Dillo). Effectively the inverse of "Save link as...". Websites with annoying MIME settings can give links that one wants to view as text (eg. source code files), but the server assigns a MIME value to them that makes Dillo download them to file. This would force Dillo to display the link as a Text file regardless. Also the view source plugin/rendering can choke a bit performance-wise (on the modestly-powered computers I use, at least) with the multi-MB webpages that are common today. Just viewing as text might be a quicker option, eg. when looking to manually extract a URL meant to load via Javascript. This would be a separate feature to implement, but maybe it would be a good fit for the same sub-menu. > Then, your handler will be invoked using the label as: > > /bin/the-handler <URL> <action-label> > > And you do whatever you find convenient in your handler, so you have > more context to decide the proper action based on the label. I think > this would cover most of the use cases of opening URLs with other > programs without being too convoluted. What would the default behaviour be? Will Dillo install a default handler with its own separate configuration file for setting up the default 'action' behaviours? Or does the feature only appear after each user has created their own handler?

Oct. 24, 2024

Future of dillo2

by sgeerken＠dillo.org

Hi, just if you were courious: I'm still living and will continue working on dillo. On Sun, Apr 20, Jorge Arellano Cid wrote: > [...] > We could: > > * Attract new developers with a dillo2 release, > leveraging the excellent documentation that we have. We have: - extensive documentations on the critical parts of dillo, expecially on Dw, - a prototype for CSS, and - some more documents and prototypes on future ideas, including scripting and graphical plugins. These should be copied on the web sever, and there should be a prominent note on the web site linking to a new delevolers' section. (Since attracting developers has high priority, this is what a visitor should notice first.) For those not listening to dillo-dev, it is important to know that dillo is still an active project. > * Planning for CSS, floating objects and TABS. > (this are important features to a nice browsing experience) Just FYI: I've started a bit on floats. Jorge, I once told you that it would take a week; actually it is a bit more complicated, nevertheless it is not a big job like CSS. > * Coordinate with FLTK2, DSL (Damn small linux) and other > lightweight distros, Debian installer team, MINIX3, etc. Perhaps we can find there other "lightweight zealots". :-) Sebastian P.S. I'll soon review the changes regarding redrawing and related. When working on floats, I noticed that the redraw optimization after resizes does not work fully correctly, there are situations where only a explicit redraw (e.g. hide and show window) makes size changes visible. P.P.S. In the doxygen documentation, there are two lists, html/bug.html and html/todo.html (generated from the \bug and \todo tags), with open issues. Furthermore, some problems are described in html/fltk-problems.html.

May 6, 2008

--xid option

by Johannes.Hofmann＠gmx.de

On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > attached patch tries to implement the missing --xid option that is > > > > used to embed dillo into the claws mailer. > > > > The right way to do this would probabely be to implement the > > > > complete XEMBED protocol which is also mentioned in > > > > doc/fltk-problems.doc. > > > > However a simple XReparentWindow() seems to work more or less here. > > > > Please test. > > > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > > e.g. hg add xembed.hh xembed.cc > > > > Oh yes. Should be fixed now. > > Btw. I managed to install the claws mail client including the dillo > > plugin and it seems to work fine now with dillo2. That's why I just > > committed the xembed stuff. > > This is very good. > > I'll have to dig for the sylpheed contact to let them know. > Does anybody here know the email? I already contacted them on irc (#claws on freenode). It would be good if this get's some testing as there seems to be some interaction with the WM in use. I now tested it successful on dwm, twm, and fvwm. Also there are probabely more elegant ways to do it, but for now I think it's better than nothing. Cheers, Johannes

May 19, 2009

Cookies performance

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 09:46:01PM +0100, Johannes Hofmann wrote: > On Tue, Jan 12, 2010 at 07:06:12PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > I noticed that since the recent DPI update pages which use > > > > > cookies load slower (e.g. fltk.org) > > > > > Do others also see that? It could also be OS specific. > > > > > > > > I thought it seemed weirdly slow _sometimes_. > > > > I'll have to throw some gprof at it and hope for something > > > > simple and embarrassing. > > > > > > > > (I wonder whether it would be easy to do valgrind with dpid and the > > > > plugins.) > > > > > > I did some truss on the cookies dpi and found that it is reading > > > ~/.dillo/dpid_comm_keys quite often. Maybe that is related. > > > > It looks like it checks it through a_Dpip_check_auth() when it > > gets or sets a msg. As for whether it needs to, I don't know. > > > > I tried a little gprof, but a modest amount of browsing and > > accepting cookies wasn't enough for the dpi to use up enough > > time for gprof to generate stats. > > Yah, I don't think it's CPU bound. There must be something else. I > will have a look at it. Can you please test attached patch, whether it compiles and makes a difference for you? I speeds things up quite a bit here. We might also want to cache SecretKey in a_Dpip_check_auth(). Cheers, Johannes

Jan. 12, 2010

Re: Hardening Dillo with unveil and pledge

by Rodrigo Arias

Hi Alex, On Sat, Jul 20, 2024 at 04:02:54PM +0200, a1ex(a)dismail.de wrote: >Hi list, > >I have been experimenting with unveil[1] and pledge[2] on Dillo to >reduce possible attack surface. Right now these system calls are >exclusive to OpenBSD, but there are projects[3] working to bring them to >Linux and other systems. > >Basically, unveil restricts which areas of the filesystem a program can >access, and pledge restricts which system calls the program is allowed >to make. > >[1] https://man.openbsd.org/unveil.2 >[2] https://man.openbsd.org/pledge.2 >[3] https://justine.lol/pledge/ > >Initial testing indicates that both of these features are working >correctly with Dillo. I am including a patch which provides some basic >filesystem protection, and limits Dillo to the minimum amount of >syscalls possible. If anyone has questions or comments, they are >welcome. Thanks for the patch, I had just opened an issue on this topic a few days ago: https://github.com/dillo-browser/dillo/issues/225 I believe it would be nice to move the network facing code away from the parsers, so the parser code cannot use the network or read the file system. This requires separating them in different processes. I also have to take a look at Justine implementation of pledge(2) for Linux. Constraining the current design may already lead to some improvement. >+ if (unveil("/home", "rwc") == -1) { We may want to constraint this a bit further, so a malicious actor cannot read anything from /home/.config. Maybe only /home/.dillo and the downloads directory would be suitable? >+ if (pledge("stdio rpath wpath cpath inet unix dns tty proc prot_exec", Does this work with plugins, when the dpid daemon is not running?, as I believe it has to fork and exec the dpid program. Easy test: $ dpidc stop $ dillo dpi:/bm/ Best, Rodrigo.

July 20, 2024

Feature Request

by Johannes.Hofmann＠gmx.de

On Sat, Nov 08, 2008 at 04:40:01PM -0500, me at swva wrote: > > I think I'm being unclear, in two ways. > >>> Just to check, I did this as root : >>> >>> [root@Hbsk2 btth]# rpm -q dillo >>> dillo-0.8.6-7.fc9.i386 >>> [root@Hbsk2 btth]# yum update dillo > ^^^^^^^^^^^^^^^^ >>> Loaded plugins: refresh-packagekit >>> updates-newkey | 2.3 kB 00:00 >>> updates | 2.6 kB 00:00 >>> fedora | 2.4 kB 00:00 >>> Setting up Update Process >>> No Packages marked for Update > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> [root@Hbsk2 btth]# > > On Sat, 8 Nov 2008, Johannes Hofmann wrote: > >> dillo-0.8.6 is no longer supported and you should consider to >> upgrade to dillo-2.0. >> But nevertheless for me it also works with dillo-0.8.6. > > For those who run other OSs, what the emphasized lines mean is the 0.8.6 > is what Fedora has, period. (I run F9, the latest release.) Any idea why > it's so far behind?? I didn't realize 1.0 had become official, let alone > 2.0 > >> If you enter "google.com" in the location bar and hit return >> it doesn't go to google? > > It does indeed. I'm putting this badly. > > I run Alpine 2.0; it is set to launch the default browser, which is > dillo -- and URLs in emails are what I use a default browser for. > > Does this mean something in my Alpine settings (and my Pine 4.64 > settings, which it took over) is wrong? My Fedora default browser setting > is simply "dillo %s"; my Alpine setting is something I'll have to dig > for, as it's buried way deep. I don't know what Alpine exactly does, but if I do dillo google.com on the command line, it works fine with both dillo 2.0 and 0.8.6.

Nov. 9, 2008

Re: Updated unveil patch

by Solène Rapenne

Le 28/07/2024 à 19:14, a1ex(a)dismail.de a écrit : > Hi, > > Here is a new patch. I have done quite a bit more work on this and > think it may be close to completion. > > The '~/Downloads' directory has been unveiled to match the behavior of > Firefox and Chromium on OpenBSD, but Dillo's default of '/tmp' > continues to work as well. > > I have also made sure everything works fine when there is no ~/.dillo > directory, Dillo can create it, and also can access the system defaults > in '/usr/local/etc/dillo'. > > dpid is also now unveiled, as well as all of the stock plugins except > hello.dpi, I didn't see any point to that. > > Here are some other tests which I have run: > > - Regular browsing works fine > - Connect to an FTP site and download a file, also view a text file and > view an image > - Open a text and image file from /tmp and ~/Downloads > - Add/remove bookmarks > - Download a file to /tmp and ~/Downloads > - Save a page to /tmp and ~/Downloads > - View source still works > - Fonts and cursor icons are working correctly > - data: uri works correctly with text and images > > So far everything seems to be fine. I will keep testing, but would > really appreciate some help with reviewing this, there could be some > edge-cases which I missed. > > Regards, > Alex > > you should provide a command line argument to disable sandboxing, so in case of a problem users can run dillo without sandboxing and see if it works better, allowing to figure if sandboxing is the root cause of their problem. what happens if you have no ~/.dillo when you start dillo with unveil? why do you need to unveil the same directories multiple times in the code?

July 28, 2024

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

Dillo-dev search results for query "plugin"