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.htm...
(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-statu... 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.htm... 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
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again. http://www.dillo.org/test/filtering.2.patch from the main directory of the dillo source, "patch -p1 < filtering.2.patch" and then put filter_auto_requests=same_domain in ~/.dillorc
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch! Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
[Somebodey wrote:] I have also found same_host not to have any value.
Generally, is it really a problem if we load url's from other hosts/domains?
Sites have no right to redirect me to unrelated sites, and sites have no right to subject me to images from unrelated sites.
I tend to agree. With your patch I noticed that many popular sites contain 1x1 images from some statistics gathering companies. However I think these images do not really leak additional information as the sites could report your IP address behind the scenes as well.
The IP sometimes is not one-to-one (proxies, NATs, etc). The cookie guarantees user tracking, when they're using the same IP or even the same machine!
I think the term "user agent" for a browser is very apt. These companies ask dillo to serve as an accomplice as they violate the user's right to privacy.
Privacy is very complex to achieve. Very accurate knowledge in a broad range is necessary. Sometimes I wonder whether connecting through to a TOR network could help us a lot with it. -- Cheers Jorge.-
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch!
Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs.
[Somebodey wrote:] I have also found same_host not to have any value.
Generally, is it really a problem if we load url's from other hosts/domains?
Sites have no right to redirect me to unrelated sites, and sites have no right to subject me to images from unrelated sites.
I tend to agree. With your patch I noticed that many popular sites contain 1x1 images from some statistics gathering companies. However I think these images do not really leak additional information as the sites could report your IP address behind the scenes as well.
The IP sometimes is not one-to-one (proxies, NATs, etc). The cookie guarantees user tracking, when they're using the same IP or even the same machine!
I think the term "user agent" for a browser is very apt. These companies ask dillo to serve as an accomplice as they violate the user's right to privacy.
Privacy is very complex to achieve. Very accurate knowledge in a broad range is necessary. Sometimes I wonder whether connecting through to a TOR network could help us a lot with it.
You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc. Cheers, Johannes
Johannes wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
Sometimes I wonder whether connecting through to a TOR network could help us a lot with it.
You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc.
I have warnings in the FAQ and dillorc that the wget env variables would need to be set appropriately, but it would be nice to have dillo send that to the dpi in requests so that it can set the environment for sure before execing wget.
I wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
Sometimes I wonder whether connecting through to a TOR network could help us a lot with it.
You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc.
I have warnings in the FAQ and dillorc that the wget env variables would need to be set appropriately, but it would be nice to have dillo send that to the dpi in requests so that it can set the environment for sure before execing wget.
I just committed a patch to set the environment variable from the preference if it wasn't already set. issues: - maybe we should have an ftp_proxy pref, too. - ISTR that dillo doesn't understand user/pass in URLs. This means that dillo doesn't do the right thing if - the env var has the user/pass - dillo is setting the env for wget.
I wrote:
I wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
Sometimes I wonder whether connecting through to a TOR network could help us a lot with it.
You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc.
I have warnings in the FAQ and dillorc that the wget env variables would need to be set appropriately, but it would be nice to have dillo send that to the dpi in requests so that it can set the environment for sure before execing wget.
I just committed a patch to set the environment variable from the preference if it wasn't already set.
issues: - maybe we should have an ftp_proxy pref, too. - ISTR that dillo doesn't understand user/pass in URLs. This means that dillo doesn't do the right thing if - the env var has the user/pass - dillo is setting the env for wget.
It turns out that if I want to add the ability for ftp/downloads to do the right thing with the no_proxy pref as well, I would have to send a no_proxy arg to the dpi. It would be cleaner to send the proxy URL to the dpi (and set/clear it there in the environment for wget) every time that it's needed than to have the proxy URL in the environment and send a no_proxy arg when it's needed. So I'm going to back out that change.
On Tue, Jan 12, 2010 at 06:50:01AM +0000, corvid wrote:
I wrote:
I wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
Sometimes I wonder whether connecting through to a TOR network could help us a lot with it.
You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc.
I have warnings in the FAQ and dillorc that the wget env variables would need to be set appropriately, but it would be nice to have dillo send that to the dpi in requests so that it can set the environment for sure before execing wget.
I just committed a patch to set the environment variable from the preference if it wasn't already set.
issues: - maybe we should have an ftp_proxy pref, too. - ISTR that dillo doesn't understand user/pass in URLs. This means that dillo doesn't do the right thing if - the env var has the user/pass - dillo is setting the env for wget.
It turns out that if I want to add the ability for ftp/downloads to do the right thing with the no_proxy pref as well, I would have to send a no_proxy arg to the dpi.
It would be cleaner to send the proxy URL to the dpi (and set/clear it there in the environment for wget) every time that it's needed than to have the proxy URL in the environment and send a no_proxy arg when it's needed.
So the idea is to always use command line arguments instead of environment variables? Sounds good to me. Cheers, Johannes
I wrote:
I wrote:
I wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
Sometimes I wonder whether connecting through to a TOR network could help us a lot with it.
You can already use dillo with privoxy and tor. We could perhaps make it more convenient to configure such a setup. We also would need to make sure that really all requests go through the proxy, e.g. I'm not sure, whether wget called from dowload.dpi uses the proxy from dillorc.
I have warnings in the FAQ and dillorc that the wget env variables would need to be set appropriately, but it would be nice to have dillo send that to the dpi in requests so that it can set the environment for sure before execing wget.
I just committed a patch to set the environment variable from the preference if it wasn't already set.
issues: - maybe we should have an ftp_proxy pref, too. - ISTR that dillo doesn't understand user/pass in URLs. This means that dillo doesn't do the right thing if - the env var has the user/pass - dillo is setting the env for wget.
It turns out that if I want to add the ability for ftp/downloads to do the right thing with the no_proxy pref as well, I would have to send a no_proxy arg to the dpi.
It would be cleaner to send the proxy URL to the dpi (and set/clear it there in the environment for wget) every time that it's needed than to have the proxy URL in the environment and send a no_proxy arg when it's needed.
So I'm going to back out that change.
This turns out to be a somewhat complicated situation. I naively imagined that whatever I found in wget's 1500-line manpage was what there was, but since wget is a gnu program, it's a subset selected who-knows-how. wget understands the http_proxy, https_proxy, and ftp_proxy environment vars. dillo understands the http_proxy environment var. If it is not set, dillo will use the http_proxy pref. dillo uses its http_proxy value for both http and the https plugin. Whatever we might do to get *_proxy set a certain way in the environment in the downloads/ftp dpis, wgetrc can override them. - should the https plugin use the https_proxy environment var if it's set? I'm leaning toward no. - should dillo try to set the https_proxy env var from the http_proxy pref for the benefit of the downloads dpi? Well, the downloads dpi doesn't like https anyway right now because we haven't given it any sort of #ifdef ENABLE_SSL add argument "--no-check-certificate" #endif, but we could and probably should add the argument. As for the question, ... not sure. (Maybe we should just let wget do all of our https, at least instead of the current plugin.) - should dillo have https_proxy prefs and ftp_proxy prefs? On one hand it might minimize confusion, but then I could take the same amount of space in dillorc to write a big comment explaining all of this. (The unpleasant part of putting things in dillorc or explaining things in dillorc is that I know that no one who upgrades is going to look through it meticulously to see what tiny things have changed.) wget also understands the no_proxy environment variable and wgetrc option. Dillo understands the no_proxy preference. Coincidentally(?), they have the same format. - Should dillo set the env var for wget from the pref if not set? I think so, for the benefit of http downloads. - Should dillo use the env var for itself if set? I kind of don't want to add the complexity. I don't know. (And to get user/pass into wget for proxy, it seems that the proper thing is to stuff them into the env var *_proxy urls.) Anyway, I'm finding this all somewhat tricky to think about.
On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch!
Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs.
What do you think about just flagging suspicious images with some browser specific CSS thing (class, id, pseudo-class we.) Then we can specify something like img:-dillo-potential-web-bug {display: none} or img:-dillo-potential-web-bug {border: 2px solid red} Other browser also have specific extensions like this, e.g. -moz-broken, -moz-user-disabled Cheers, Johannes
Johannes wrote:
On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch!
Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs.
What do you think about just flagging suspicious images with some browser specific CSS thing (class, id, pseudo-class we.) Then we can specify something like
img:-dillo-potential-web-bug {display: none}
or
img:-dillo-potential-web-bug {border: 2px solid red}
Other browser also have specific extensions like this, e.g. -moz-broken, -moz-user-disabled
CSS might be completely disabled.
On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch!
Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs.
What do you think about just flagging suspicious images with some browser specific CSS thing (class, id, pseudo-class we.) Then we can specify something like
img:-dillo-potential-web-bug {display: none}
or
img:-dillo-potential-web-bug {border: 2px solid red}
Other browser also have specific extensions like this, e.g. -moz-broken, -moz-user-disabled
CSS might be completely disabled.
Remote CSS yes, but this stuff would be put into the user agent stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). These two can't be disabled.
Johannes wrote:
On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch!
Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs.
What do you think about just flagging suspicious images with some browser specific CSS thing (class, id, pseudo-class we.) Then we can specify something like
img:-dillo-potential-web-bug {display: none}
or
img:-dillo-potential-web-bug {border: 2px solid red}
Other browser also have specific extensions like this, e.g. -moz-broken, -moz-user-disabled
CSS might be completely disabled.
Remote CSS yes, but this stuff would be put into the user agent stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). These two can't be disabled.
Oh, I see. I don't want to make requests for those images at all, though.
On Sat, Jan 02, 2010 at 04:19:26PM +0000, corvid wrote:
Johannes wrote:
On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch!
Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs.
What do you think about just flagging suspicious images with some browser specific CSS thing (class, id, pseudo-class we.) Then we can specify something like
img:-dillo-potential-web-bug {display: none}
or
img:-dillo-potential-web-bug {border: 2px solid red}
Other browser also have specific extensions like this, e.g. -moz-broken, -moz-user-disabled
CSS might be completely disabled.
Remote CSS yes, but this stuff would be put into the user agent stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). These two can't be disabled.
Oh, I see.
I don't want to make requests for those images at all, though.
Yes, but provided I can get the display:none stuff working some day, they would not be loaded at all if img:-dillo-potential-web-bug {display: none} is set. Additionally the user could do some fancy stuff by overriding this setting in his user stylesheet. I think disabling image loading is implemented similarly in other browsers.
Johannes wrote:
On Sat, Jan 02, 2010 at 04:19:26PM +0000, corvid wrote:
Johannes wrote:
On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch!
Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs.
What do you think about just flagging suspicious images with some browser specific CSS thing (class, id, pseudo-class we.) Then we can specify something like
img:-dillo-potential-web-bug {display: none}
or
img:-dillo-potential-web-bug {border: 2px solid red}
Other browser also have specific extensions like this, e.g. -moz-broken, -moz-user-disabled
CSS might be completely disabled.
Remote CSS yes, but this stuff would be put into the user agent stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). These two can't be disabled.
Oh, I see.
I don't want to make requests for those images at all, though.
Yes, but provided I can get the display:none stuff working some day, they would not be loaded at all if
img:-dillo-potential-web-bug {display: none}
is set. Additionally the user could do some fancy stuff by overriding this setting in his user stylesheet. I think disabling image loading is implemented similarly in other browsers.
Oh, I see (again :) It would be nice to have something like you said before, with a pixmap (or alt text) making it clear what's going on, and that can be clicked to load or whatever. Would we implement the content property or something?
On Sat, Jan 02, 2010 at 05:07:14PM +0000, corvid wrote:
Johannes wrote:
On Sat, Jan 02, 2010 at 04:19:26PM +0000, corvid wrote:
Johannes wrote:
On Sat, Jan 02, 2010 at 03:43:48PM +0000, corvid wrote:
Johannes wrote:
On Thu, Dec 31, 2009 at 01:18:49PM +0100, Johannes Hofmann wrote:
On Thu, Dec 31, 2009 at 12:27:36AM -0300, Jorge Arellano Cid wrote:
On Mon, Dec 28, 2009 at 02:01:46AM +0000, corvid wrote:
bb wrote:
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.htm...
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.
I just remembered that I had another version later in the thread, and I just took a couple of minutes to get the patch to apply cleanly again.
I like the patch!
Please set PREFS_FILTER_SAME_DOMAIN as the default, so we can give it broader testing from the Hg repo. My idea is to commit, if you agree, and to polish from the repo.
I also agree. It would be cool if we could replace rejected web bugs with some ugly little pixmap, so people see them on the page and can analyze the url. That could also help with improving our heuristics to find the web bugs.
What do you think about just flagging suspicious images with some browser specific CSS thing (class, id, pseudo-class we.) Then we can specify something like
img:-dillo-potential-web-bug {display: none}
or
img:-dillo-potential-web-bug {border: 2px solid red}
Other browser also have specific extensions like this, e.g. -moz-broken, -moz-user-disabled
CSS might be completely disabled.
Remote CSS yes, but this stuff would be put into the user agent stylesheet (css.cc) or the user stylesheet (~/.dillo/style.css). These two can't be disabled.
Oh, I see.
I don't want to make requests for those images at all, though.
Yes, but provided I can get the display:none stuff working some day, they would not be loaded at all if
img:-dillo-potential-web-bug {display: none}
is set. Additionally the user could do some fancy stuff by overriding this setting in his user stylesheet. I think disabling image loading is implemented similarly in other browsers.
Oh, I see (again :)
It would be nice to have something like you said before, with a pixmap (or alt text) making it clear what's going on, and that can be clicked to load or whatever. Would we implement the content property or something?
Maybe that would work. I haven't verified it though. This is all just an idea. Let's see whether I can come up with some real code...
participants (4)
-
bblochl＠arcor.de -
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de