Closed Bug 34866 Opened 25 years ago Closed 25 years ago

Pref - Accept images from same domain as originating server

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: markw, Assigned: morse)

Details

Overview Description: In the Preferences dialog, under the section "Cookies and Images", there is a setting to indicate what images should be accepted / rejected. This is a wonderful feature. However, many sites use a dedicated image server to display their own site's images. Under the current situation, if I want to prevent displaying images that originate outside the site's immediate domain (these are typically banner ads), I check "Accept images that come from the originating server only". Unfortunately, in doing this I also end up stripping out the site's (legitimate) images. Therefore, the "Acceptable Images" setting would be much improved with a fourth option: "Accept images that come from the same domain as the originating server". Steps to Reproduce: 1) Remove the contents of your cache so that cached images do not interfere with this test. 2) Check "Accept images that come from the originating server only" in Prefs -> Cookies and Images. 3) Go to a site that uses a dedicated image server (i.e. slashdot.org uses images.slashdot.org as a dedicated image server) Actual Results: No images display. Disclaimer: This feature is actually working as advertised, which is why this is being filed as an "Enhancement", not as a bug. Expected Results: (Actually, for this entry, this section should be called "Requested Results", but Moz developers smile on those who use the bug template, right?) I would like to have an additional setting called "Accept images that come from the same domain as the originating server", which, when set, would alow me to see images that originate from any server within that domain, but not images originating from servers outside that domain. Build Date and Platform: Build ID: 2000040520 file: mozilla-i686-pc-linux-gnu.tar.gz Additional Builds and Platforms: I have not tested this on any other platform, but I presume that settings in the "Preferences" dialog are global, platform independent settings. Additional Builds and Platforms: To sum up, I think an 'enhanced' "Cookies/Images" section in the "Preferences" dialog should look like this: o Accept all images o Accept images that come from the originating server only o Accept images that come from the same domain as the originating server o Reject all images [] Warn me before accepting an image
steve?
Assignee: neeti → morse
Component: Preferences: Backend → XPApps
No, it's not an enhancement request, it's a bug. This is a new feature and obviously is still in flux; after initially implementing it I changed it to do exactly what you are requesting (domain match rather than exact host match). But I guess I didn't test it adequately and I see the results that you are reporting at slashdot.org. So I'll take another look at my coding and figure out why it's not doing what I intended it to do. I'll also change the wording on the pref as you described. Thanks for catching this. BTW, it sounds like you are requesting to have both "accept from originating server only" and "accept from originating domain only". That's not my intention -- there's no need for both and domain is the useful one. Do you really think we should have both?
Severity: enhancement → normal
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → M16
Actually, now that you mention it, simply allowing images from the same domain is probably sufficient (as opposed to clamping down restrictions to the granularity of the individual server). If we wanted to take a vote on it (whether we should have both "originating server" AND "originating domain", or just "originating domain"), I suppose we could but I'm not sure how such a vote should be taken. [Mark thinks about it a little more...] Actually, having both an "originating server" AND an "originating domain" option might confuse some people; they might wonder what the difference is between the two. I think just the "originating domain" option is probably sufficient. NB: Thanks again for this feature. It's my favorite one so far. Also, I'm real impressed with the turnaround time between submitting this bug and hearing back from a developer.
Update: I tested this bug again today with most recent nightly build (Build ID: 2000040616). I removed my cache and went to slashdot.org and I am now able to see images that are served up from the dedicated image server, but the off-site images (the banner ad at the top) does not get displayed. Great work! I think there's only one more thing that should be changed before this bug gets marked as FIXED: Make a small modification to the wording of the option in the preferences dialog. Currently it reads: "Accept images that come from the originating server only" I think that should be changed to: "Accept images that come from the originating site only" It's a small semantic difference, but I think my suggested wording is more correct; it's another way of saying "originating domain" but uses less technical wording that should (hopefully) be less confusing to most users.
Now that's interesting. I didn't see any images when I went to slashdot.com with the pref set. I am using a build from April 5. And I haven't changed anything since then. So I don't understand why it is now working fine for you. In any case, I'll investigate this further in the next few days and see what is going on. And, yes, I'll make that wording change that you suggested. Thanks.
Doh! You're right. I must not have removed the right directory when I tested it earlier. I just tried removing the whole .mozilla/ directory (on my earlier attempt, I only removed '.mozilla/Profile Name/Cache') and got the same behavior as before. So yeah, I guess I was a little hasty in declaring this as fixed. [Mark blushes]
Now I'm confused. I just went to debug this and guess what -- it works as expected. The image on top is blocked but all other images are being displayed. Something very strange is going on here. Could the site be changing its content so that sometimes the images are in the same domain and at other times they are not? That's very unlikely. Wait, I think I just figured out what is happening. There is a bug that I was aware of when I implemented the test for non-originating server (I fully intended to come back and fix it eventually) and I believe that is what is hurting us now. Let me explain. If the pref is set and we are displaying site x.y.com, I'll accept images form z.y.com. But, unfortunately, I won't accept images from y.com. Furthermore, if I am viewing y.com, I won't accept images from x.y.com. Basically I am doing a compare of the string that follows the first dot. This obviously must be fixed. Now in the case of slashdot, the images are coming from x.slashdot.org (I forget what x is). So if you go to http://www.slashdot.org, it all works fine -- the images are displayed. But if you go to http://slashdot.org, you don't see the images. I think that at times I was testing by going to one of those url's and at other times I was going to the other (totally by accident) and that's why it worked for me sometimes but not always. And probably you were doing the same thing. OK, now it's time for me to fix the bug that I was aware of and I'm sure that will take care of the oddities that we were both observing here.
Summary: [RFE] Pref - Accept images from same domain as originating server → Pref - Accept images from same domain as originating server
Fix in hand. Will be checked in just as soon as the M15 freeze is lifted.
Fix checked in. Changed file was nsCookie.cpp
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
BTW, you can't win them all. If you go to http://www.slashdot.com (instead of .org) you will not get the images. Why? Because it gets the images from images.slashdot.org and that is definitely not in the same domain.
A nightly build for Linux wasn't made last night so I can't test the new fix. One should be made tonight though, and when it is I'll grab it and test it.
Allright, I tested this again with last night's build (Build ID 2000041212). I tested the image loading again on slashdot (with the "Accept images from originating server" pref set) and my results were the opposite of the ones you found. slashdot.org - I did not see the ad banner, nor did I see the site images www.slashdot.org - I did not see the ad banner, but *did* see the site imgs So, something is still a little fishy here... FWIW, the behavior I would expect to find would be to see the site images but not the ad banner regardless of whether I prefix the domain name with www. or not. BTW, another good site to test this on is http://tomshardware.com. Also, (and this is a very minor point) I noted that the prefs dialog still reads "Accept images that come from the originating server only", and I thought that was going to be changed from "server" to "site". Thanks again for being so dilligent with this bug.
I'm certainly not seeing what you are seeing. I see the following with the reject-foreign-images pref set: www.slashdot.org: ad banner = NO, images = YES slashdot.org: same as above Further when I went to http://tomshardware.com I received *all* the images. Looking at the page source I see that all images are indeed on the tomshardware.com domain so this behavior is as expected. Yes I forget to update the wording in the pref. Will do that later today when the tree reopens.
Re: Slashdot Here's what I'm getting with the "reget foreign images" pref turned on: (Note: results are the same regardless of whether I'm using an existing profile or create a new profile from scratch.) www.slashdot.org - banner ad: NO, icons: YES (which is what I would expect) slashdot.org - banner ad: NO, icons: NO (which is not what I would expect) Man, that's weird that we're getting conflicting results. I wish I could bring you over to my desk and show you this. Like I mentioned, I'm using a nightly build with the ID 2000041212. Is it possible that the build I'm using doesn't contain your new code? Re: Tom's Hardware This is another one that leaves me scratching my head. Earlier today when I went to http://tomshardware.com (note: no leading www), I couldn't see the little hammer image ("howto64.gif"), among others. Curious, I right-clicked on it, selected "Copy Image Location" and pasted it into an editor. The text that got pasted in said that the image was coming from www7.tomshardware.com (which made this similar to the slashdot.org -> images.slashdot.org situation). I just tried it now and mozilla displays all the "icon" images coming from www.tomshardware.com (which is what I would expect). Maybe there's some rotating / dynamic DNS thing that's making this inconsistent. But I'm also a little surprised that you were able to see _all_ the images as there are a number of ad banners, many of which originate from foreign domains. Examples include: www.ad.tomshardware.com ad.doubleclick.net adforce.imgis.com (via a CGI redirect) I can see none of these. Weird. I should at least be able to see the one(s) originating from www.ad.tomshardware.com. Hmmm. Re: Updating wording Thanks, looking forward to it.
over to tever to verify...this would go to elig, who deals with image stuff, but he's on leave at the present, so i'm taking a best-guess as to who this belongs to for the nonce. :-)
QA Contact: sairuh → tever
verified
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.