[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again
by jcid＠dillo.org
Hi Christian,
Sorry for the late answer, but I've had little spare time,
and several topics to answer.
Probably you have already read:
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht…
an got some info from there.
On Sat, Mar 15, 2008 at 02:02:07PM +0100, Christian Kellermann wrote:
> * Christian Kellermann <Christian.Kellermann(a)nefkom.net> [080315 09:49]:
> > Dear list,
> >
> > In order to fix the https plugin I have stumbled upon the fact,
> > that the former dialog code seems to be removed from cvs. To see
> > what's goign on further down the code I have added a basic Yes/No
> > popup using the existing a_Dialog_choice3 function. For this the
> > numbering of the buttons have changed also in https. Dialogs with
> > more than two alternatives will have the additional choices dropped
> > silently. This is good for now but I really like to have it done
> > right. Which function should get used instead of a_Dialog_choice3?
> >
> > Also what's the real purpose of http_request? At the moment I cheat
> > and set it to url in case it is empty. Which value is to be expected
> > when calling the document root in a URL? "/"? "/index.html"? or am
> > I getting this all wrong?
> >
> > Whith this patch I can bypass the "certificate could not get verified"
> > case but not much further. Also cancelling the dialog seems to leave
> > some data behind, another call of https URLs won't do anything. But
> > this is a bit better than it has been before...
> >
> > I am not sure whether I should stop beating this dead horse or
> > continue. What's your advice?
> >
>
> Ignore the http_request part I figured it out.
>
> Ok, I have changed the proto comparison from "https" -> "proto.https"
> and I am able to view https sites again. This module still needs a
> lot of cleanup. As a next step I want to implement simple certificate
> caching so accepted certificates won't get prompted again. This
> will be memory only at first, making the certificate valid (or
> invalid) as long as the dpid lives.
>
> The updated patch is attached below.
A long time ago, browsing was mainly fetching pages and images.
It made a lot of sense to use an external tool (as wget) to grab
https pages. Implementing this idea with dpi was also simple.
Now, it may be not the case. You have to keep track of certificates,
sessions, sometimes keep an open connection, etc.
Years ago SSL wasn't widespread, today is an everyday need, so it
may make sense to consider having it inside dillo. It can take some
design time at the beginning but will be easier to maintain and extend
than to have it living in an external dpi.
Developers is what we need, so if you want to work on https,
you're more than welcome. Lack of manpower is our biggest problem!
"place" implemented gzip decoding in dillo2, he may help you with
ideas on how to add an extra layer/decoding-stage for SSL.
(With regard to your specific questions about https, you'll
have to wait some time until I can look at it again in depth.
IIRC there was a five option dialog requested through dpip that
sent the answer back on what to do. It was removed from the code
while porting, delayed for future implementation).
Again, my suggestion is to consider an internal implementation.
--
Cheers
Jorge.-
March 15, 2008
Re: Towards 3.2.0
by Rodrigo Arias
Hi all,
On Thu, Oct 24, 2024 at 10:45:49PM +0200, Xavier Del Campo Romero wrote:
>I would have preferred to resume my work on multipart/form-data, but I
>have been too busy with other projects and IRL. The required changes
>were way too complex to shoehorn into this release, so I assume they
>will have to wait for the next one :)
No worries :-)
On Thu, Oct 24, 2024 at 11:09:46PM +0200, a1ex(a)dismail.de wrote:
>I don't know about the complexity, but it worked fine here!
Yeah, but I prefer to move to a new file when the format is more stable,
so you can keep your rules intact. Now I'm experimenting.
>Sounds good, but in that case, maybe we should provide an example
>handler script in the docs, since that could be a barrier for some
>users.
>
>I'm still using a variant of this[1] patch, but with multiple
>entries, which still seems to be the easiest way of allowing external
>actions.
>
>[1] https://alex.envs.net/patches/00-ext-link-handler.patch
Yeah, maybe I could also make it like this so you can specify a program
directly:
actions="Open with external tool:/path/to/the/handler.sh default $URL"
actions="Open as audio:/path/to/the/handler.sh audio \"$URL\""
actions="Open with MPV:mpv $URL"
actions="Open with Firefox:firefox $URL"
But this won't work well when the URL has characters that are
interpreted by the shell.
It "should" be like:
actions="Open with external tool:/path/to/the/handler.sh default \"$URL\""
actions="Open as audio:/path/to/the/handler.sh audio \"$URL\""
actions="Open with MPV:mpv \"$URL\""
actions="Open with Firefox:firefox \"$URL\""
But is quite ugly. And I'll have to check if you can still inject some
command in the URL, which would be dangerous.
On Fri, Oct 25, 2024 at 09:12:21AM +1000, Kevin Koster wrote:
>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.
Yes, I have also experienced this annoyance. It may be nice yes, not
sure how complex to implement.
>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.
I think for very long text files this may continue to choke Dillo. Maybe
you could add a external tool that pipes it to more(1) or less(1).
>> 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?
By default, no extra options. As you add the actions they appear on the
menu. We may want to distribute an example handler for users to have a
reference.
Best,
Rodrigo.
Oct. 25, 2024
Re: Save link as... silent failure on gopher protocol
by Diego
Hello, I'm sending two patches with an idea to solve this problem.
It's a proof of concept that I'm offering to develop and complete, although
I have very little free time.
The first patch works with the latest dillo release (3.3.0) but also works
with the current repository.
It implements changes in dillo, download.dpi, and the file and data DPIs as
examples.
The second patch works with the latest gopher.dpi repository.
The main idea is that the DPIs that handle protocols save the URL and write
the file themselves, coordinating with download.dpi and dillo.
To do this, they implement a new DPI command: `save_url`
d_cmd = a_Dpip_build_cmd("cmd=%s url=%s destination=%s", "save_url", url,
dl_dest);
Dillo initiates a download, sending it to download.dpi as before. If it's
HTTP* or FTP*, it downloads directly as it does now. Otherwise, it will
send a `save_url` command to Dillo to coordinate. This allows Dillo to
notify the user, verify the security of the change, etc.Currently, Dillo
only checks if there's a DPI that handles the requested protocol.
(A new function (`a_Dpiapi_is_service_handled(server_str)`) queries `dpid`
without executing the DPI. No code is modified in `dpid`. Modifying `dpid`
or executing the DPI would allow querying the capabilities of the DPIs, but
it doesn't seem necessary.)
- If a DPI is present, it sends the `save_url` command to the DPI that
coordinates with `download.dpi` via a secondary channel so that downloads
can continue even if all Dillo windows are closed.
- If the protocol isn't handled, it notifies download.dpi through the
secondary channel (this reduces the amount of code).
The next step would be to implement `save_url` in other protocol DPIs.
A possible change to download.dpi once all is done is to leave download.dpi
it as just a GUI for DPIs and extract the code to download HTTP to a DPI.
(There's already ftp.dpi)
One last thing: can you recommend a simple Git manual?
Saludos
Diego.
El lun, 25 may 2026 a las 21:23, Rodrigo Arias (<rodarima(a)gmail.com>)
escribió:
> Hi,
>
> On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote:
> >Good day,
> >
> >I am using dillo 3.3.0 on Slackware64 15.0.
> >
> >If I open a gopher directory, right-click on an item, and click
> >Save link as..., this opens a file save dialog. If i click OK, it
> >dismisses the dialog. I expected it to save something, but it
> >creates no new files.
> >
> >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/
> >Top item: 40282-0
> >
> >I found the following workaround:
> >
> >* Left click 40282-0
> >* Click Save button in browser toolbar
> >
> >This creates a new file as expected.
>
> Yes, this is a known limitation of the downloads in Dillo. Using the
> "Save link as" to fetch a new resource will use wget under the hood,
> which only allows http(s). You can see the message in the console:
>
> > UIcmd_save: /tmp/40282-0.txt
> > ** WARNING **: Ignoring download request for
> > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in cache
> > and not downloadable.
>
> Browsing to the target file makes the gopher plugin fetch the file and
> place it in the Dillo cache (you can see it in about:cache). Then saving
> the current page (or going back and clicking the "Save link as" entry)
> works because it fetches it from the cache.
>
> It is planned to solve this some time in the future, but involves
> complex changes. In the meanwhile, you can use this workaround.
>
> Best,
> Rodrigo.
> _______________________________________________
> Dillo-dev mailing list -- dillo-dev(a)mailman3.com
> To unsubscribe send an email to dillo-dev-leave(a)mailman3.com
>
July 3, 2026
Feature Request
by jcid＠dillo.org
On Sun, Nov 09, 2008 at 01:12:01PM +0100, Michal Nowak wrote:
> Jorge Arellano Cid wrote:
>> On Sat, Nov 08, 2008 at 10:58:43PM +0100, Michal Nowak wrote:
>>> 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
>>>>
>>> That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons:
>>>
>>> 1) No one packed FLTK 2.x, check repository there's still 1.1.9.
>>> 2) Because of (1) no Dillo 2.
>>>
>>> Although Fedora is usually fresh, in case of Dillo it's still on
>>> Dillo 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com)
>>> against Dillo and Package Review for FLTK2, but be aware that having
>>> unstable FLTK 2.x in Fedora might be quite fight. (Believe me I am
>>> Fedora packager.)
>>
>> Dillo2 doesn't need an FLTK2 package installed!
>> It can be statically linked in. One package, that's it.
>> (this is the default BTW).
>>
>
> Sure I am aware of that, but wrt Fedora, it's something neat forbidden
>
> https://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy
>
> unless necessary (and this is not the case).
>
>> Now, if distros need to also provide source packages by policy,
>> then that's a different story.
>>
>
> Correct. FLTK can't just be present in compile time, somehow, toolchain
> has to be clear and for everyone from day0.
>
>> Please clarify me because I've read that complaint a few times,
>> and don't yet know whether it's my fault not making the statical
>> linking clear enough to packagers, or if there's a packaging
>> policy issue I don't know of. :)
>>
>
> From my POV, in distros we don't want static built packages; security
> flaws in linked-in libraries is the main concern. One has to rebuild all
> apps with those libraries, not just the library (obvious).
>
> I don't thing it will be that hard to get FLTK & Dillo2 into Fedora, the
> thing is that no one did it till now :). (And I ma pretty busy at work &
> uni :) ).
Thanks a lot for the explanation!
Although it may be difficult to get a FLTK2 package in the
distro because FLTK2 doesn't have a stable release yet. I mean,
if policies mandate not to include alpha or beta libraries, we're
out...
It'd be good to know this (for Fedora, Ubuntu and Debian at
least). That way we can ask the FLTK team about their schedule
plans.
--
Cheers
Jorge.-
Nov. 9, 2008
[PATCH v2] Unveil patch
by a1ex＠dismail.de
Hi,
Here is version 2 of my unveil patch. Many thanks to Rodrigo for his
kind assistance!
Improvements:
- Unveil is disabled by default. It can be enabled using:
configure --enable-unveil
- There is now a dUnveil() wrapper which simplifies the code and error
handling
- Locale check and custom cursor icons unveil fix
To-Do:
- Add prefs parsing to plugins to get 'save_dir' (may need help here)
- Add a dillorc pref to enable/disable unveil (same issue as above)
- Localize wget and $AUTHORITY
- A few other items from my previous to-do list
Regards,
Alex
diff -upr a/configure.ac b/configure.ac
--- a/configure.ac Sat Jul 27 12:54:47 2024
+++ b/configure.ac Thu Aug 1 16:40:16 2024
@@ -36,6 +36,11 @@ AC_ARG_ENABLE([insure],
[enable_insure=$enableval],
[enable_insure=no])
+AC_ARG_ENABLE([unveil],
+ [AS_HELP_STRING([--enable-unveil], [Build with support for unveil])],
+ [enable_unveil=$enableval],
+ [enable_unveil=no])
+
AC_ARG_ENABLE([ipv6],
[AS_HELP_STRING([--enable-ipv6], [Build with support for IPv6])],
[enable_ipv6=$enableval],
@@ -619,6 +624,9 @@ if test "x$enable_insure" = "xyes" ; then
CC="insure -Zoi \"compiler $CC\""
LIBS="$LIBS -lstdc++-2-libc6.1-1-2.9.0"
fi
+if test "x$enable_unveil" = "xyes" ; then
+ AC_DEFINE([ENABLE_UNVEIL], [1], [Enable unveil])
+fi
if test "x$enable_threaded_dns" = "xyes" ; then
CFLAGS="$CFLAGS -DD_DNS_THREADED"
fi
@@ -725,4 +733,5 @@ _AS_ECHO([ GIF enabled : ${enable_gif}])
_AS_ECHO([ SVG enabled : ${enable_svg}])
_AS_ECHO([])
_AS_ECHO([ HTML tests : ${html_tests_ok}])
+_AS_ECHO([ unveil enabled : ${enable_unveil}])
_AS_ECHO([])
diff -upr a/dpi/bookmarks.c b/dpi/bookmarks.c
--- a/dpi/bookmarks.c Sat Jul 27 12:54:47 2024
+++ b/dpi/bookmarks.c Thu Aug 1 16:40:50 2024
@@ -1606,6 +1606,20 @@ static void termination_handler(int signum)
exit(signum);
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
/*
* -- MAIN -------------------------------------------------------------------
@@ -1617,6 +1631,16 @@ int main(void) {
char *tok;
Dsh *sh;
+ /* Use unveil on OpenBSD */
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ char *dil_bm = dStrconcat(dGethomedir(), "/.dillo/bm.txt", NULL);
+ dUnveil(dil_bm, "rwc");
+ dFree(dil_bm);
+ unveil(NULL, NULL);
+ #endif
+ #endif
+
/* Arrange the cleanup function for terminations via exit() */
atexit(cleanup);
diff -upr a/dpi/cookies.c b/dpi/cookies.c
--- a/dpi/cookies.c Sat Jul 27 12:54:47 2024
+++ b/dpi/cookies.c Thu Aug 1 16:40:50 2024
@@ -1632,6 +1632,20 @@ static void termination_handler(int signum)
exit(signum);
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
/*
* -- MAIN -------------------------------------------------------------------
@@ -1643,6 +1657,16 @@ int main(void) {
int sock_fd, code;
char *buf;
Dsh *sh;
+
+ /* Use unveil on OpenBSD */
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
+ dUnveil(dil_loc, "rwc");
+ dFree(dil_loc);
+ unveil(NULL, NULL);
+ #endif
+ #endif
/* Arrange the cleanup function for terminations via exit() */
atexit(cleanup);
diff -upr a/dpi/datauri.c b/dpi/datauri.c
--- a/dpi/datauri.c Sat Jul 27 12:54:47 2024
+++ b/dpi/datauri.c Thu Aug 1 16:40:50 2024
@@ -280,6 +280,21 @@ static unsigned char *datauri_get_data(char *url, size
return data;
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
+
/*
*
*/
@@ -289,6 +304,17 @@ int main(void)
unsigned char *data;
int rc;
size_t data_size = 0;
+
+ /* Use unveil on OpenBSD */
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ dUnveil("/tmp", "rwc");
+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
+ dUnveil(dil_loc, "rwc");
+ dFree(dil_loc);
+ unveil(NULL, NULL);
+ #endif
+ #endif
/* Initialize the SockHandler */
sh = a_Dpip_dsh_new(STDIN_FILENO, STDOUT_FILENO, 8*1024);
diff -upr a/dpi/downloads.cc b/dpi/downloads.cc
--- a/dpi/downloads.cc Sat Jul 27 12:54:47 2024
+++ b/dpi/downloads.cc Thu Aug 1 16:40:50 2024
@@ -1098,12 +1098,45 @@ static void custLabelMeasure(const Fl_Label* o, int& W
fl_measure(o->value, W, H, interpret_symbols);
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
-
//int main(int argc, char **argv)
int main()
{
int ww = 420, wh = 85;
+
+ /* Use unveil on OpenBSD */
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ dUnveil("/tmp", "rwc");
+ dUnveil("/etc/fonts", "r");
+ dUnveil("/usr/local/bin/wget", "x");
+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL);
+ dUnveil(xauth_loc, "r");
+ dFree(xauth_loc);
+ dUnveil("/usr/local/share/fonts", "r");
+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
+ dUnveil(dil_loc, "rwc");
+ dFree(dil_loc);
+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL);
+ dUnveil(dl_loc, "rwc");
+ dFree(dl_loc);
+ unveil(NULL, NULL);
+ #endif
+ #endif
Fl::lock();
diff -upr a/dpi/file.c b/dpi/file.c
--- a/dpi/file.c Sat Jul 27 12:54:47 2024
+++ b/dpi/file.c Thu Aug 1 16:40:50 2024
@@ -1063,6 +1063,20 @@ static int File_check_fds(uint_t seconds)
return st;
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
int main(void)
{
@@ -1070,6 +1084,19 @@ int main(void)
socklen_t sin_sz;
int sock_fd, c_st, st = 1;
+ /* Use unveil on OpenBSD */
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ dUnveil("/tmp", "rw");
+ char *dl_loc = dStrconcat(dGethomedir(), "/Downloads", NULL);
+ dUnveil(dl_loc, "rw");
+ dFree(dl_loc);
+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
+ dUnveil(dil_loc, "rwc");
+ unveil(NULL, NULL);
+ #endif
+ #endif
+
/* Arrange the cleanup function for abnormal terminations */
if (signal (SIGINT, termination_handler) == SIG_IGN)
signal (SIGINT, SIG_IGN);
diff -upr a/dpi/ftp.c b/dpi/ftp.c
--- a/dpi/ftp.c Sat Jul 27 12:54:47 2024
+++ b/dpi/ftp.c Thu Aug 1 16:40:50 2024
@@ -272,6 +272,21 @@ static int try_ftp_transfer(char *url)
return (no_such_file ? -1 : (aborted ? -2 : nb));
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
+
/*
*
*/
@@ -281,6 +296,21 @@ int main(int argc, char **argv)
char *dpip_tag = NULL, *cmd = NULL, *url = NULL, *url2 = NULL;
int st, rc;
char *p, *d_cmd;
+
+ /* Use unveil on OpenBSD */
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ dUnveil("/tmp", "rwc");
+ dUnveil("/usr/local/bin/wget", "x");
+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
+ dUnveil(dil_loc, "rwc");
+ dFree(dil_loc);
+ char *dl_loc = dStrconcat(dGethomedir(), "/download", NULL);
+ dUnveil(dl_loc, "rwc");
+ dFree(dl_loc);
+ unveil(NULL, NULL);
+ #endif
+ #endif
/* wget may need to write a temporary file... */
rc = chdir("/tmp");
diff -upr a/dpi/vsource.c b/dpi/vsource.c
--- a/dpi/vsource.c Sat Jul 27 12:54:47 2024
+++ b/dpi/vsource.c Thu Aug 1 16:40:50 2024
@@ -178,6 +178,21 @@ void send_html_text(Dsh *sh, const char *url, int data
a_Dpip_dsh_write_str(sh, 1, "</table></body></html>");
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
+
/*
*
*/
@@ -187,6 +202,16 @@ int main(void)
int data_size;
char *dpip_tag, *cmd = NULL, *cmd2 = NULL, *url = NULL, *size_str = NULL;
char *d_cmd;
+
+ /* Use unveil on OpenBSD */
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
+ dUnveil(dil_loc, "r");
+ dFree(dil_loc);
+ unveil(NULL, NULL);
+ #endif
+ #endif
_MSG("starting...\n");
//sleep(20);
diff -upr a/dpid/main.c b/dpid/main.c
--- a/dpid/main.c Sat Jul 27 12:54:47 2024
+++ b/dpid/main.c Thu Aug 1 16:41:04 2024
@@ -220,6 +220,21 @@ static int get_open_max(void)
#endif
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
+
/*! \todo
* \li Add a dpid_idle_timeout variable to dpidrc
* \bug Infinite loop if plugin crashes before it accepts a connection
@@ -236,6 +251,17 @@ int main(void)
services_list = NULL;
//daemon(0,0); /* Use 0,1 for feedback */
/* TODO: call setsid() ?? */
+
+ /* Use unveil on OpenBSD */
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ dUnveil("/usr/local/lib/dillo", "rx");
+ dUnveil("/usr/local/etc/dillo", "r");
+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
+ dUnveil(dil_loc, "rwc");
+ unveil(NULL, NULL);
+ #endif
+ #endif
/* Allow read and write access, but only for the user.
* TODO: can this cause trouble with umount? */
diff -upr a/src/dillo.cc b/src/dillo.cc
--- a/src/dillo.cc Sat Jul 27 12:54:47 2024
+++ b/src/dillo.cc Thu Aug 1 16:40:06 2024
@@ -379,6 +379,21 @@ static DilloUrl *makeStartUrl(char *str, bool local)
return start_url;
}
+/**
+ * Use unveil on OpenBSD
+ */
+static void dUnveil(const char *path, const char *perm)
+{
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ if (unveil(path, perm) == -1) {
+ MSG("unveil(%s, %s) failed: %s\n", path, perm, strerror(errno));
+ exit(1);
+ }
+ #endif
+ #endif
+}
+
/*
* MAIN
*/
@@ -462,7 +477,34 @@ int main(int argc, char **argv)
fclose(fp);
}
dLib_show_messages(prefs.show_msg);
-
+
+ // Use unveil on OpenBSD
+ #ifdef ENABLE_UNVEIL
+ #ifdef __OpenBSD__
+ dUnveil("/usr/local/share/fonts", "r");
+ dUnveil("/usr/local/share/icons", "r");
+ dUnveil("/usr/X11R6/share/X11/locale", "r");
+ dUnveil("/usr/X11R6/lib/X11/fonts", "r");
+ dUnveil("/usr/local/etc/dillo", "r");
+ dUnveil("/tmp", "rwc");
+ dUnveil("/usr/local/bin/dpid", "x");
+ dUnveil("/etc/fonts", "r");
+ dUnveil("/etc/resolv.conf", "r");
+ dUnveil("/etc/ssl/cert.pem", "r");
+ dUnveil(prefs.save_dir, "rwc");
+ char *dil_loc = dStrconcat(dGethomedir(), "/.dillo", NULL);
+ dUnveil(dil_loc, "rwc");
+ dFree(dil_loc);
+ char *icons_loc = dStrconcat(dGethomedir(), "/.icons", NULL);
+ dUnveil(icons_loc, "r");
+ dFree(icons_loc);
+ char *xauth_loc = dStrconcat(dGethomedir(), "/.Xauthority", NULL);
+ dUnveil(xauth_loc, "r");
+ dFree(xauth_loc);
+ unveil(NULL, NULL);
+ #endif
+ #endif
+
// initialize internal modules
a_Dpi_init();
a_Dns_init();
Aug. 1, 2024
Various minor patches
by jcid＠dillo.org
On Wed, Jan 30, 2008 at 03:40:52PM +0100, Christian Kellermann wrote:
> * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:36]:
> > On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote:
> > > * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]:
> > > > 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. ;).
> > > >
> > >
> > > Yes it does describe my problem, but how do we fix this in a portable way?
> >
> >
> > Before this patch, we had no test for iconv. Did it work for you then?
> >
> In a way yes. because my solution was to add -liconv to my LDFLAGS.
Did the new test in configure.in work?
I assume not because of the silence.
You wrote:
> In a way yes. because my solution was to add -liconv to my LDFLAGS.
and
> 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.
I assume you set LDFLAGS=-L/usr/local/lib...
but this is expected to be done by the test at configure.in:96.
The test can fail though! Would you mind posting the output of:
cpp -v
in your system.
--
Cheers
Jorge.-
Jan. 31, 2008
Re: Save link as... silent failure on gopher protocol
by Diego
¿Can i have some feedback? ¿Do the patchs work for you? ¿do it seem a
practical idea? ¿etc?
cheers!
Diego.
El vie, 3 jul 2026 a las 14:17, Diego (<darkspirit5000(a)gmail.com>) escribió:
> Hello, I'm sending two patches with an idea to solve this problem.
> It's a proof of concept that I'm offering to develop and complete,
> although I have very little free time.
>
> The first patch works with the latest dillo release (3.3.0) but also works
> with the current repository.
> It implements changes in dillo, download.dpi, and the file and data DPIs
> as examples.
> The second patch works with the latest gopher.dpi repository.
>
> The main idea is that the DPIs that handle protocols save the URL and
> write the file themselves, coordinating with download.dpi and dillo.
>
> To do this, they implement a new DPI command: `save_url`
> d_cmd = a_Dpip_build_cmd("cmd=%s url=%s destination=%s", "save_url", url,
> dl_dest);
>
> Dillo initiates a download, sending it to download.dpi as before. If it's
> HTTP* or FTP*, it downloads directly as it does now. Otherwise, it will
> send a `save_url` command to Dillo to coordinate. This allows Dillo to
> notify the user, verify the security of the change, etc.Currently, Dillo
> only checks if there's a DPI that handles the requested protocol.
>
> (A new function (`a_Dpiapi_is_service_handled(server_str)`) queries `dpid`
> without executing the DPI. No code is modified in `dpid`. Modifying `dpid`
> or executing the DPI would allow querying the capabilities of the DPIs, but
> it doesn't seem necessary.)
>
> - If a DPI is present, it sends the `save_url` command to the DPI that
> coordinates with `download.dpi` via a secondary channel so that downloads
> can continue even if all Dillo windows are closed.
>
> - If the protocol isn't handled, it notifies download.dpi through the
> secondary channel (this reduces the amount of code).
>
> The next step would be to implement `save_url` in other protocol DPIs.
>
> A possible change to download.dpi once all is done is to leave
> download.dpi it as just a GUI for DPIs and extract the code to download
> HTTP to a DPI. (There's already ftp.dpi)
>
> One last thing: can you recommend a simple Git manual?
>
>
> Saludos
> Diego.
>
> El lun, 25 may 2026 a las 21:23, Rodrigo Arias (<rodarima(a)gmail.com>)
> escribió:
>
>> Hi,
>>
>> On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote:
>> >Good day,
>> >
>> >I am using dillo 3.3.0 on Slackware64 15.0.
>> >
>> >If I open a gopher directory, right-click on an item, and click
>> >Save link as..., this opens a file save dialog. If i click OK, it
>> >dismisses the dialog. I expected it to save something, but it
>> >creates no new files.
>> >
>> >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/
>> >Top item: 40282-0
>> >
>> >I found the following workaround:
>> >
>> >* Left click 40282-0
>> >* Click Save button in browser toolbar
>> >
>> >This creates a new file as expected.
>>
>> Yes, this is a known limitation of the downloads in Dillo. Using the
>> "Save link as" to fetch a new resource will use wget under the hood,
>> which only allows http(s). You can see the message in the console:
>>
>> > UIcmd_save: /tmp/40282-0.txt
>> > ** WARNING **: Ignoring download request for
>> > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in cache
>> > and not downloadable.
>>
>> Browsing to the target file makes the gopher plugin fetch the file and
>> place it in the Dillo cache (you can see it in about:cache). Then saving
>> the current page (or going back and clicking the "Save link as" entry)
>> works because it fetches it from the cache.
>>
>> It is planned to solve this some time in the future, but involves
>> complex changes. In the meanwhile, you can use this workaround.
>>
>> Best,
>> Rodrigo.
>> _______________________________________________
>> Dillo-dev mailing list -- dillo-dev(a)mailman3.com
>> To unsubscribe send an email to dillo-dev-leave(a)mailman3.com
>>
>
July 8, 2026
Re: Save link as... silent failure on gopher protocol
by Rodrigo Arias
Hi,
On Thu, Jul 09, 2026 at 01:37:14AM +0200, Diego wrote:
>¿Can i have some feedback? ¿Do the patchs work for you? ¿do it seem a
>practical idea? ¿etc?
Thanks, I received the patches but I haven't had time to look at this
yet, I have have it in my queue.
Best,
Rodrigo.
>
>cheers!
>Diego.
>
>
>El vie, 3 jul 2026 a las 14:17, Diego (<darkspirit5000(a)gmail.com>) escribió:
>
>> Hello, I'm sending two patches with an idea to solve this problem.
>> It's a proof of concept that I'm offering to develop and complete,
>> although I have very little free time.
>>
>> The first patch works with the latest dillo release (3.3.0) but also works
>> with the current repository.
>> It implements changes in dillo, download.dpi, and the file and data DPIs
>> as examples.
>> The second patch works with the latest gopher.dpi repository.
>>
>> The main idea is that the DPIs that handle protocols save the URL and
>> write the file themselves, coordinating with download.dpi and dillo.
>>
>> To do this, they implement a new DPI command: `save_url`
>> d_cmd = a_Dpip_build_cmd("cmd=%s url=%s destination=%s", "save_url", url,
>> dl_dest);
>>
>> Dillo initiates a download, sending it to download.dpi as before. If it's
>> HTTP* or FTP*, it downloads directly as it does now. Otherwise, it will
>> send a `save_url` command to Dillo to coordinate. This allows Dillo to
>> notify the user, verify the security of the change, etc.Currently, Dillo
>> only checks if there's a DPI that handles the requested protocol.
>>
>> (A new function (`a_Dpiapi_is_service_handled(server_str)`) queries `dpid`
>> without executing the DPI. No code is modified in `dpid`. Modifying `dpid`
>> or executing the DPI would allow querying the capabilities of the DPIs, but
>> it doesn't seem necessary.)
>>
>> - If a DPI is present, it sends the `save_url` command to the DPI that
>> coordinates with `download.dpi` via a secondary channel so that downloads
>> can continue even if all Dillo windows are closed.
>>
>> - If the protocol isn't handled, it notifies download.dpi through the
>> secondary channel (this reduces the amount of code).
>>
>> The next step would be to implement `save_url` in other protocol DPIs.
>>
>> A possible change to download.dpi once all is done is to leave
>> download.dpi it as just a GUI for DPIs and extract the code to download
>> HTTP to a DPI. (There's already ftp.dpi)
>>
>> One last thing: can you recommend a simple Git manual?
>>
>>
>> Saludos
>> Diego.
>>
>> El lun, 25 may 2026 a las 21:23, Rodrigo Arias (<rodarima(a)gmail.com>)
>> escribió:
>>
>>> Hi,
>>>
>>> On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote:
>>> >Good day,
>>> >
>>> >I am using dillo 3.3.0 on Slackware64 15.0.
>>> >
>>> >If I open a gopher directory, right-click on an item, and click
>>> >Save link as..., this opens a file save dialog. If i click OK, it
>>> >dismisses the dialog. I expected it to save something, but it
>>> >creates no new files.
>>> >
>>> >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/
>>> >Top item: 40282-0
>>> >
>>> >I found the following workaround:
>>> >
>>> >* Left click 40282-0
>>> >* Click Save button in browser toolbar
>>> >
>>> >This creates a new file as expected.
>>>
>>> Yes, this is a known limitation of the downloads in Dillo. Using the
>>> "Save link as" to fetch a new resource will use wget under the hood,
>>> which only allows http(s). You can see the message in the console:
>>>
>>> > UIcmd_save: /tmp/40282-0.txt
>>> > ** WARNING **: Ignoring download request for
>>> > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in cache
>>> > and not downloadable.
>>>
>>> Browsing to the target file makes the gopher plugin fetch the file and
>>> place it in the Dillo cache (you can see it in about:cache). Then saving
>>> the current page (or going back and clicking the "Save link as" entry)
>>> works because it fetches it from the cache.
>>>
>>> It is planned to solve this some time in the future, but involves
>>> complex changes. In the meanwhile, you can use this workaround.
>>>
>>> Best,
>>> Rodrigo.
>>> _______________________________________________
>>> Dillo-dev mailing list -- dillo-dev(a)mailman3.com
>>> To unsubscribe send an email to dillo-dev-leave(a)mailman3.com
>>>
>>
>_______________________________________________
>Dillo-dev mailing list -- dillo-dev(a)mailman3.com
>To unsubscribe send an email to dillo-dev-leave(a)mailman3.com
July 12, 2026
towards a consistent UI
by Johannes.Hofmann＠gmx.de
Hi,
-------- Original-Nachricht --------
> Datum: Mon, 11 Aug 2008 12:59:32 -0400
> Von: Jorge Arellano Cid <jcid(a)dillo.org>
> An: dillo-dev(a)dillo.org
> Betreff: Re: [Dillo-dev] towards a consistent UI
> Hi,
>
> Well here's my opinion on these UI points:
>
> On Mon, Aug 04, 2008 at 09:50:24PM +0200, Johannes Hofmann wrote:
> > Hi,
> >
> > I really like the way Ctrl-l now just selects the current
> > URL in normal mode avoiding a dialog window.
>
> Me too!
>
> > In fullscreen mode however, the short switch to normal mode to enter
> > the new URL requires a complete redraw of the page contents.
> > Also the contents "jumps" down for the time the location bar is
> > shown. This can be distracting.
>
> Find text also causes a redraw. Maybe avoiding the redraw in
> both cases is a good solution. Not of high priority unless really
> simple to implement.
I think the flicker can be avoided, but that won't stop the content from
"jumping" in the fullscreen case.
>
> > Do we really want to kill all uses of dialog windows? We still have
> > "Search the Web" anyway.
>
> No. Some dialog windows are quite OK, and there's no need I can see
> to ban them.
Agreed
>
> > Also the location of the "IMG ON/OFF" button seems a bit arbitrary.
>
> I like it where it is, but agree on that it may find a better place.
> Together with the other Panel buttons, my be.
>
Yes maybe. I will try that when I have time.
> > How could a consistent user interface of dillo look like?
> >
> > Here is my proposal - just to start the discussion:
> >
> > * Everything is accessible via the menubar and via keyboard
> > shortcuts. The shortcuts are shown behind the menu entries.
>
> Currently the main model is context sensitive popups (right click).
> There're some things you can't get from them (e.g. Open File), but
> I see no point in duplicating the popup menus from the menu bar.
>
> About everything being accessible via keyboard shortcuts, I don't
> agree. I believe there are simpler ways. For instance if there's a
> shortcut for every popup menu entry, there's a need to remember a lot
> of shortcut/function pairs. Now if there's a shortcut to popup the
> context sensitive menu, and that menu is keyboard operable, IMHO that's
> easier to remember/use.
> If there's a frequently used operation inside a popup, it may have
> its own shortcut.
I think the advantage of a menu bar is that it's easily visible, what functionality
is available. Advanced users will probabely use shortcuts.
But you are right. I forgot about the context menus. The link and image menu
only makes sense as a context menu.
>
> > shortcuts are shown behind the menu entries.
>
> Agreed.
>
> > * All shortcuts are configurable.
>
> Agreed.
>
> >
> > * No more img on/off button. One can use a menubar entry or keyboard
> > shortcut instead.
>
> I prefer the button. It's more visible and gives feedback on its
> current status.
> Firefox has this functionality somewhere, and a few people know
> of it.
Ok.
>
> > * The "Search the Web" button should be just as all the other
> > buttons ("Back", "Forw" ...) and be configurable of course.
>
> Agreed.
> With something like:
> search_url="<title>,<URL>" in dillorc2, with the first
> one being the default for instance.
>
> > Perhaps a single config option like:
> > panel_buttons="back, forw, home, reload, save, stop, book"
>
> I prefer the boolean way (current model).
>
I was looking for a way to make the ordering configurable too.
> > * The "HTML bugs" button in the status bar is ok.
> > It shows the bug-state of the current page.
>
> Agreed!
>
>
> > * "Search the Web" opens the start page of the selected search
> > engine (e.g. google.com) and selects the search text field.
> > I'm not sure about that, but it avoids the dialog window and it makes
> > clear to which search engine the query is sent.
> > The additional page load for the empty search page is only
> > required once - then it's cached.
>
> NO! :-)
>
> I love avoiding the search page. e.g. with google.
>
> ...but, yes, I see there may be cases where the native HTML interface
> is preferred. Maybe a simple flag can help it:
>
> search_url="<title>,<URL>[,LoadPage]"
>
> Thus, with no flag, we get a dialog:
>
> .------------------------------,
> | Search with <title>: |
> | [_________________________] |
> | |
> | [Cancel] [OK] |
> '------------------------------'
>
> and with the "LoadPage" flag, the HTML page.
>
> This can be implemented quickly! ;-)
>
Or a plugin, that presents a HTML page with search forms?
I'm not sure myself :-)
>
> > * In fullscreen mode "Ctrl-l" opens a dialog window again. Any
> > better solution?
>
> If the redraw can be avoided, could be, if not, the dialog may be
> OK. I haven't used this case too much so I don't *feel* the problem.
>
Yes, I was also thinking about reintroducing the dialog in this case.
Cheers,
Johannes
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
Aug. 18, 2008
web bug save?
by bblochl＠arcor.de
Jorge Arellano Cid schrieb:
> 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?
>>>
>
> AFAIS your analysis is correct. There's no problem in increasing the
> web bug image size, specially on these broadband days...
>
> Personally I have hopes on restricting resource loading from other
> sites,
> but as corvid cites, it's non trivial and requires careful thought.
>
> As a highly interested user, you may gather some information on
> web bugs, techniques to avoid them etc. and post a summary of
> your findings here. That would help a lot. We have the knowledge
> on how to code dillo and restricted time to work on it. If you
> can help us everybody gains.
>
>
>
>> 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...
>>
>
> I'm very interested in this topic, although haven't found free time
> these days...
>
>
>
Thank you for your response.
The begin of my web bug adventure was some curiousity as I gamed around
with http://livehttpheaders.mozdev.org. I found some strange things, and
momentarily felt like the guy in "The blue velvet", finding an cut ear
and come into touch with an strange and eval world outside a wardrobe.
The real eval things can only be done by javascript - so dillo is on the
save side.
It may be of general Interest: I found as a countermeasure the plugin
ghostery for firefox. ghostery has a large list of known web bugs and
can block it. Most of that software one may find is googles urchin.js,
but ggogle has a new software ga.js. There was even launched "Turn Key
Web Analytics In A Box" on Friday, December 18, 2009, see
http://www.coradiant.com/news/091209_analyticsbox.htm. The List of web
bugs you can find:
http://code.google.com/p/ghostery/source/browse/trunk/firefox/ghostery-stat…
One may check out a read-only working copy anonymously over HTTP:
http://code.google.com/p/ghostery/source/checkout
As I just pointed out, a dillo user cannot be tracked by any javascript
code. But even a simple Web Bug with a http-rquest to a tracking server
can get a lot of Information about the request AFAIK that is client IP
address, certainly the request date/time, the page requested, HTTP code,
bytes served, user agent, and referer. So the tracker knows the URL of
the page containing the bug and allows the server to determine which
particular Web page the user has accessed. But more, the URL of the bug
can be appended with an arbitrary string in various ways with extra
information to identify the loading conditions of the bug. This extra
information can be added while sending the page or by JavaScript scripts
after the download (but as ponted out - no Javascript with Dillo). Web
bugs can also be used in combination with HTTP cookies (if there are
any) like any other object transferred using the HTTP protocol.
One might say, use a proxy. But I found that nearly all of the free
proxys are real trojans and sending such web bugs, most often in the
advertising pictures. I asked a couple of the providers of free proxy
services. The usual answer was, that they do not send web bugs, but the
bad advertisers do. And usually they offered ma thei payed service that
is free of advertising. And very often that web bug requests will NOT be
send via the proxy!!
You sent me an option switch to forbid dillo to request another domain
as that of the actually used page:
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-September/006844.ht…
How can I patch Dillo in this way?
It might be useful to have that as an option in Dillo, I am shure not
every user is comfortable with that restriction.
Seasons greetings
BB
Dec. 27, 2009