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)
Tracking
(Not tracked)
VERIFIED
FIXED
M16
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
Assignee | ||
Comment 2•25 years ago
|
||
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
Reporter | ||
Comment 3•25 years ago
|
||
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.
Reporter | ||
Comment 4•25 years ago
|
||
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.
Assignee | ||
Comment 5•25 years ago
|
||
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.
Reporter | ||
Comment 6•25 years ago
|
||
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]
Assignee | ||
Comment 7•25 years ago
|
||
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
Assignee | ||
Comment 8•25 years ago
|
||
Fix in hand. Will be checked in just as soon as the M15 freeze is lifted.
Assignee | ||
Comment 9•25 years ago
|
||
Fix checked in. Changed file was nsCookie.cpp
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•25 years ago
|
||
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.
Reporter | ||
Comment 11•25 years ago
|
||
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.
Reporter | ||
Comment 12•25 years ago
|
||
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.
Assignee | ||
Comment 13•25 years ago
|
||
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.
Reporter | ||
Comment 14•25 years ago
|
||
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.
Comment 15•25 years ago
|
||
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
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•