33576 - Redesign of "accept images only from originating server" pref

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Preferences, defect)

Description

[jay garcia]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; N; Win98; en-US; m14)
BuildID:    32708

Prefs/cookies and images/accept images only from originating server - causes
SEARCH button to disappear on Altavista

Reproducible: Always
Steps to Reproduce:
1. Configure prefs to "accept images only from originating server"
2. Visit Altavista
3. No SEARCH button
4. Configure prefs to "accept all images"
5. Revisit Altavista
6. Search Button is present


Actual Results:  No search button	

Expected Results:  Expect to see the search button when configured to "accept
images only from originating server".

Comment 1

[Asa Dotzler [:asa]]

Does the search button utilize an image from a different server?

Comment 2

[jay garcia]

The SEARCH button image is originating from another server as per:

 http://a12.g.akamai.net/7/12/282/79f2845b1f889a/www.altavista.com/i/search.gif

So now what does this do to the pref? We are going to encounter more of this 
issue.

Comment 3

[Asa Dotzler [:asa]]

Not sure I see a way around this. If you want the search button then don't
enable that pref or convince altavista to move the image to the same server. The
pref is supposed to reject images from other servers (not exactly sure why
anyone would want to do this in the first place).  Sounds like a WONTFIX or
INVALID.   Am I missing something here?

Comment 4

[jay garcia]

I don't think there's much chance of convincing AV to rearrange their server. 
What concerns me the most is with the pref enabled there is going to be a flood 
of Q's in the support groups a la "The button's not there in xxx.xxx.xxx", etc 
ad nauseum !! And then it's going to be "our fault" :o(

My suggestion is to leave the feature enabled as-is, as the benefits far 
outweigh the problems that may crop up. I think we can close this issue now.

Comment 5

[Asa Dotzler [:asa]]

-> sending to UI Feedback for discussion.  I think maybe we need a good warning
on the enabling of that pref and it should definitely default to allowing all
images.

Comment 6

[jay garcia]

Yes, definitely. Anything to avoid the whining in the groups.

Comment 7

[Asa Dotzler [:asa]]

Jay sent this to me as a possible warning. (and I'm confirming this too)

WARNING: Enabling this feature may cause some sites to operate
incorrectly, ie., Form Submit Buttons as images that originate from
another server may not appear, resulting in no way to send the form
results.

Should this be in Preferences?

Comment 8

[jay garcia]

It's an awful lot of text but if there is a reasonable spot to add it then maybe
someone with vast experience in writing tech manuals could shorten it a bit.
Otherwise, go for it!

Comment 9

[Brendan Donohoe]

What exactly is the benefit of this feature?  Blocking advertisements?  If so, 

then it's a feature designed around the implementation and not the goal.  If the 

implementation can cause significant problems (as seems to be the case here) then 

the goal is not reached.  IMHO, the solution is a better design (which is 

admittedly not an easy thing to do in this case; selective filtering never is), 

not a warning label.



Reassigning to German for comment.

Comment 10

[german]

Yes I agree, its not clear what the pref is supposed to do. First time I am
seeing this in the product. As is it's not clear from the description what this
supposed to be good for. Also users may set the pref(not knowing what it does,
thinking it increases their level of privacy/security), and then not see the
consequences until later. For endusers the search btn on altavista is a control
not an image.
Unless somebody can convincingly make a good case for this feature I think it
should be removed asap. If this was really meant to kill advertising this
feature (even once relabeled) is implemented in such a primitive way that it
does more harm than good.
Passing on to Ben as moz UI module owner.

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

bouncing over to steve as he owns this feature

Comment 12

[Stephen P. Morse]

I'm open to suggestions as to how better to determine a foreign image.  This is 
obviously a new feature and may need some fine tuning to get it right.

But it is doing what it was intended to do so I could close it out as invalid. 
Furthermore, the user had to explicitly set the pref (it is not the default).

However I will keep it open so we can keep thinking about it and maybe come up 
with the right heuristic.  Pushing out to M18 for now but that doesn't mean that 
I won't work on it sooner if someone comes up with the right suggestion.    
Perhaps the right suggestion is to drop this choice completely (just leave in 
"accept all" and "reject all").

Comment 13

[jay garcia]

As the 'user' that found this problem my suggestion is to leave the feature 
as-is. So far I have only found this error on AltaVista and I think that this 
will be the exception by far and not the rule. If Q's arise in the support 
groups we simply blame it on the originating site. :-)

Comment 14

[Stephen P. Morse]

I should add that I have already refined the heuristic somewhat.  Initially I 
was checking for an exact host match.  That meant that site x.netscape.com 
couldn't put up images from y.netscape.com.  I modified it to include domain 
matches instead.  There might be more fine tuning needed in that regard.

Comment 15

[Eli Goldberg]

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas ([e-mail]).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to [e-mail].)

Comment 16

[Matthew T (active 1999-2002)]

Steve, you can't assume a given number of domain levels like that. If you allow 
x.netscape.com to put up images from y.netscape.com, then you have the problem of 
moneysuckers.com.au being able to put up images from annoying-ads.com.au, and 
boring.co.uk being able to put up images from imagespewers.co.uk, and so on.

Resummarizing and reclassifying to more accurately reflect the problem. I'll try 
to come up with a UI solution soon.

Comment 17

[Stephen P. Morse]

Sure it fails for the counter-example you gave.  And we all know about the 
problem with domain cookies when country-urls are used.  But I'm not trying to 
get it right 100% of the time, only most of the time.  That's why I said I am 
using an heuristic.  If it fails for country urls, so be it.  At least it works 
for the .com, .net, etc urls which are the more prevelant.

Comment 18

[Matthew T (active 1999-2002)]

Ok, my suggestion:
* Remove the global `only images from this server' pref. As cited in this bug, it
  just can't work, when many popular sites (such as AltaVista and Apple) contract
  out their image serving to companies like Akamaitech.
* Change the `Block This Image' context menu item to `Block Images ...'. Have it
  pop up a dialog which looks something like this:
  +------------------------------------------------------+
  |[] Block Images ::::::::::::::::::::::::::::::::::::::|
  +------------------------------------------------------+
  | In the future, Mozilla will block images which:      |
  |                                                      |
  | ( ) are the same size as this image (149 x 32)       |
  | ( ) come from the same domain as this image          |
  | (*) are both the same size and from the same domain  |
  |                                                      |
  | Domain for blocking:                                 |
  | (*) x42.ads.admeisters.com                           |
  | ( ) *.ads.admeisters.com                             |
  | ( ) *.admeisters.com                                 |
  | ( ) *.com                                            |
  |                                                      |
  | ( Help )                      ( Cancel ) (( Block )) |
  +------------------------------------------------------+

I think that would solve everybody's problems (except AOL's, of course) ...

Comment 19

[Frank de Lange]

Or it might be possible to integrate the Junkbuster proxy into Mozilla. This
way, you can also block certain paths within a domain. Some domains actually
contain useful information, even the doubleclick ones (they host a CPAN site to
which people are automatically directed from the CPAN web page...). The context
menu could be updated by adding an `advanced' option, where you can enter a
regexp to block.

Comment 20

[Stephen P. Morse]

These ideas are all well and good for the advanced user.  However I was more 
interested in simplicity of use when I implemented it.  Just right-clicking on 
an image to reject it, or setting a couple of prefs for additional filtering.  
And the prefs were designed to parallel the cookie prefs which also added to the  
ease of use (and understanding) on the part of the user.

Comment 21

[Mark Whitley]

I've been meaning to write up an additional bug report on this topic, but

since this report has already been filed, I'll just add my comments.



Here is what I would like to see for the image blocking pref dialog:



   ( ) Accept all images

   ( ) Reject all images

   ( ) Block Certain Images

       [ ] Block images that originate from a foreign domain

       [ ] Block images that come from sites in this file

           [___________________] (enter file or URL)

       [ ] Block images that match the following regex

           [___________________]

       [ ] Warn me before accepting any other images





The ( ) are radio buttons (meaning, they are exclusive), the [ ] are check

boxes (non-exclusive), and the [_____] are text fields. The check boxes are

grayed out until you click "Block Certain Images".



The "block file" field could take either a file name on your local hard drive

or an http:// URL. This would allow, say, Junkbuster for example to maintain a

RTBHL listing of undesirable-image spewing sites. Additionally, this file

could be the same one read by the "Image Manager" when it displays blocked /

non-blocked sites.



The default text in the regex field could be "ad[^.]*\.[^.]*\.com" (without

the " qoutes). Optionally, this could be a multi-line text field instead of a

single-line text field to allow N regexes to be entered (seperated by carriage

returns).



The "Warn me before accepting any other images" is a catch-all at the end for

the extra paranoid among us. If an image isn't filtered by any of the previous

rules.



I think this strikes a balance between 'sophisticated image blocking features'

and 'not overwhelming novice users'. Arguably, the most confusing option here

is the regex text field, but putting in the default I mentioned should work in

90% of the cases and spare the novice user of having to purchase an O'Reilly

book or three just to get through his prefrences dialog.

Comment 22

[Stephen P. Morse]

Comments received from Aydin Edguer:

I think your basic heuristic "if not from 'same site' then 'block'" is valid.
I like it and appreciate the fact that you have provided such a feature.

The questions are the meaning of "same site" and "block".

I would like to see "block" provide at least a similar level of controls
to those found for cookies:
  a) Accept All
  b) Accept Only Same Server
  c) Warn Before Accepting

It would be nice to see another option:
  d) Warn Before Accepting Not Same Server

This is separate from the issue of "Auto download" vs "Manual download".

Please note that combining "Manual download" with "Warn Before Accepting"
(giving image size if possible) is a nice way to help those who have low
bandwidth links, but need to read/navigate some sites that use images which
are small or difficult to "click" to download, by allowing the browser to
do the work of locating the images and giving the user the choice of which
to accept/use.

Additional Comments From Matthew Thomas 2000-04-28 07:48
> Steve, you can't assume a given number of domain levels like that.
> If you allow x.netscape.com to put up images from y.netscape.com,
> then you have the problem of moneysuckers.com.au being able to put up
> images from annoying-ads.com.au, and boring.co.uk being able to put up
> images from imagespewers.co.uk, and so on.

Additional Comments From [e-mail] 2000-04-28 07:57
> Sure it fails for the counter-example you gave.  And we all know about
> the problem with domain cookies when country-urls are used.  But I'm not
> trying to get it right 100% of the time, only most of the time.
> That's why I said I am using an heuristic.  If it fails for country urls,
> so be it.  At least it works for the .com, .net, etc urls which are the
> more prevelant.

It looks like you are using a simple heuristic of compare the top two
components of the domain name.

  fails  www.annoying-ads.com.au -> com.au
  fails  moneysuckers.com.au -> com.au
  fails  annoying-ads.com.au -> com.au
  works  x.netscape.com -> netscape.com
  works  netscape.com -> netscape.com
  works? slashdot.com. -> slashdot.com

[The question mark is because I do not know how your parser deals with
 trailing dots in host names.]

A simple alternative heuristic is to compare the top N-1 components (removing
only the first component) with a minimum of two components.

  works  www.annoying-ads.com.au -> annoying-ads.com.au
  fails  moneysuckers.com.au -> com.au
  fails  annoying-ads.com.au -> com.au
  works  x.netscape.com -> netscape.com
  works  netscape.com -> netscape.com
  works? slashdot.com. -> slashdot.com

A slightly more advanced heuristic is to check the length of the Nth (the last)
component and using it to set the minimum value.
  =2 letter -> minimum = 3
  >2 letter -> minimum = 2

  works  www.annoying-ads.com.au -> annoying-ads.com.au
  works  moneysuckers.com.au -> moneysuckers.com.au
  works  annoying-ads.com.au -> annoying-ads.com.au
  works  x.netscape.com -> netscape.com
  works  netscape.com -> netscape.com
  works? slashdot.com. -> slashdot.com

The reason for using ">2" rather than "3" is that there have been some
proposals to add new top level domains (TLDs) that have more than three
letters.  I don't know of any one letter TLDs or proposals for them, so
I don't know what the default should be for "1".

I think that the heuristic can be further improved (complicated?) by
providing a per-domain exception list.

So, for "altavista.com", the user could add "akamai.net" as an acceptable
alternative domain.  This would work for other places who have different
domain names (like "dec.com" vs "digital.com" - same name, different days).

If "Warn Before Accepting Not Same Server" was an option then the exception
list could be built by the browser based on a "Accept, Accept and Add Rule,
Reject" dialog box.

Comment 23

[german]

I am not sure images per se can be said to track user behavior. It is links that 
get clicked, that are usaully based off 
images. Problem is from a user perspective the intent/benefit is not clear at 
all. Why should a user not want to see 
images? 

There is no clear relationship for an end-user at all between images and tracking 
browsing habits. Furthermore this feature 
being placed next to cookies will almost ensure that users will only find it by 
accident. I think the way it is currently 
presented it is only useful to a small sliver of the overall audience as the rest 
has no clue what is being talked about. 

Furthermore turning this filter on (for many users by accident or out of 
curiosity) will result in users not seeing images in 
some cases, and not remembering that they turned images off using this privacy 
pref. Even if they remember it will be 
even harder to remember for them where they need to go to reverse their setting.

So I think that a) turning images off should *never* be a default setting and b) 
usability has to be significantly beefed 
before this feature can actually be useful for a wider audience.

Comment 24

[Matthew T (active 1999-2002)]

German, who said anything about tracking user behavior? As far as I know, it is 
not possible for image servers to track user behavior (except when they also use 
cookies); but that's not the issue here.

The question `Why should a user not want to see images?' could only ever come 
from someone who has either a very fast Internet connection, a high level of 
patience, a highly developed capacity to mentally filter out visual noise, or a 
combination of those factors. The answer to the question is that many users find 
some images undesirable -- whether they be distracting, or a waste of bandwidth, 
or whatever. Often these images are of a particular size, and come from a 
particular domain which is different from that of the document being viewed; and 
these properties are what allows us to block them.

The suggestions from Mark Whitley and Aydin Edguer are interesting, but they 
mainly involve the interface in the prefs dialog. My immediate concern is more 
for the `block by example' interface, because if you think about it, that is 
where the majority of filtering will actually take place. Hence my dialog design. 
I think it's important to have a dialog for blocking images, rather than (as 
Morse suggests) immediately blocking all images from the same second-level 
domain, because it provides an extra level of warning about what the user is 
doing (equivalent to, but not as annoying as, an `are you sure you want to do 
this?' dialog). For something like this which could cause confusion if it was 
done by accident, we *want* to make it a little more difficult than just a single 
click on a context menu item. (would be like putting the ejector handle right 
next to the throttle.)

Having said that, German's point that images should be easier to unblock is a 
valid one. Therefore, I suggest that where the context menu for an unblocked 
image has `Block Image ...', the context menu for the placeholder for a blocked 
image should have `Unblock Image ...'. And the dialog brought up by the menu item 
should be able to unblock images, just as it can block them.

This means that my earlier suggested design needs to be tweaked, thus:
+------------------------------------------------------------+
|[] Block Images ::::::::::::::::::::::::::::::::::::::::::::|
+------------------------------------------------------------+
| ( ) Sto_p blocking images like this one                    |
| ( ) Block images the same _size as this one (149 x 32)     |
| ( ) Block images from the same _domain as this one         |
| (*) Block images which are _both the same size and from    |
|     the same domain as this one                            |
| ( ) Block images based on their _address ( S_ettings ... ) |
|                                                            |
| _Domain for blocking:                                      |
| (*) x42.ads.admeisters.com                                 |
| ( ) *.ads.admeisters.com                                   |
| ( ) *.admeisters.com                                       |
| ( ) *.com                                                  |
|                                                            |
| ( Help )                  ( Cancel ) (( Change settings )) |
+------------------------------------------------------------+

Notes:
* `Stop blocking images like this one' is only enabled if the current image is
  blocked. Selecting it and then selecting `Change settings' removes all blocking
  rules which are blocking the current image.
* `Block images the same size as this one' is only enabled if the size of the
  relevant image is known -- i.e. if it's in the document source.
* `Block images based on their address' is pre-selected if the current image is
  being blocked due to a more complex rule based on the contents of the URL. If
  such a rule does not exist, selecting this option for the first time creates a
  new blocking rule which blocks all images with exactly the same address as the
  current image. (If the rule needs to be more general than this, it can be
  changed using the `Settings ...' button, or by opening the Preferences dialog
  later.)
* The `Settings ...' button is only enabled if `Block images based on their
  address' is selected. Activating the button opens the Preferences dialog at the
  `Images' category, and puts focus in the first control for the most specific
  rule which is blocking the current image.
* The `Domain for blocking:' controls are only enabled if either `Block images
  from the same domain as this one' or `Block images which are both the same size
  and from the same domain as this one' is selected.

I still think the `Block all images which come from a different server' option is 
unworkable and should go.

Comment 25

[Matthew T (active 1999-2002)]

Corrections:
*     `(would be like putting the ejector handle right next to the throttle.)'
  --> `(Allowing images to be blocked with a single context menu click would be
      the equivalent of putting the ejector handle right next to the throttle.)'

*     `_Domain for blocking:'
  --> `Domain _for blocking:'

Comment 26

[Matthew T (active 1999-2002)]

From Neal McBurnett (by e-mail):
|
| Another issue - beware of redirects.  E.g. the image URL could be listed in the
| web page as http://coolsite.com/xyz.gif, but then be redirected to
| http://doubleclick.com/xyz.gif, so the browser should remember to not follow
| the redirection.

Comment 27

[Hixie (not reading bugmail)]

> the context menu for the placeholder for a blocked image should have `Unblock
> Image ...'

Oops, alt text replacement will cause a problem here. Must consider that...

Comment 28

[Matthew T (active 1999-2002)]

Which, Ian, is one of the reasons for my suggestion in bug 23691 that all 
unloaded images should have placeholders, even those images which have alt text.

Meanwhile ... the top of my suggested dialog is rather wordy and hard to scan. An 
alternative arrangement would be:

(*) Block images which:
    ( ) are the same size as this one (149 x 32)
    ( ) have a similar address to this one      ( Settings ... )
    ( ) come from the same domain as this one
    (*) are both the same size and from the same domain

    Domain for blocking:
    ( ) ...
    ( ) ... [etc]

( ) Stop blocking images like this one

All controls between `Block images which:' and `Stop blocking images like this 
one' would be disabled if `Stop blocking images like this one' was selected.

This would be easier to read and less daunting (fewer options in the same level 
of hierarchy); but it would require (on average) about 0.2 or 0.3 more mouse 
clicks to use, each time it was opened, than my previous design would. I would 
guess the tradeoff would be worth it, though you'd need to try it in a usability 
testing lab to be sure.

Comment 29

[Matthew T (active 1999-2002)]

More food for thought for those who still think blocking all off-server images is 
a good idea:
* About.com <http://about.com/>
* Adobe <http://www.adobe.com/>
* Altavista <http://www.altavista.com/>
* Apple Computer <http://apple.com/>
* Britannica.com <http://britannica.com/>
* CBS <http://cbs.com/>
* CNN <http://cnn.com/>
* LookSmart <http://www.looksmart.com/>
* Lycos <http://www.lycos.com/>
* Motley Fool <http://www.fool.com/>
* Quicken <http://www.quicken.com/>
* Ticketmaster <http://www.ticketmaster.com/>

And, the grand finale:
* Yahoo <http://www.yahoo.com/>

In my opinion, such a high false positive rate, on such popular sites, is 
unacceptable -- even for something which is optional.

Comment 30

[Mark Whitley]

Ouch. That's a lot of false positives. Closer inspection of some of the sites
Matthew mentioned revealed the following:

yahoo.com -> legit blocked images oritinate from: a1.g.a.yimg.com cnn.com ->
legit blocked images oritinate from: a388.g.akamaitech.net apple.com -> legit
blocked images oritinate from: a312.g.akamaitech.net The yahoo.com -> yimg.com
images have only the .com in common, and the cnn.com / apple.com ->
akamaitech.net, don't have any part of their domain name in common. [Best Austin
Powers voice:] Ouch, baby. Very ouch.

From the other posts above (and especially this last from Matthew), I'm more
inclined to think that the best way to accomplish the goal (blocking undesirable
images), is to have a black-hole list in a file that Mozilla looks at to
determine whether to block images. If we wanted to leverage the work that people
have put into junkbuster (http://www.internet.junkbusters.com), the format for
the image block file could be the same as junkbuster blockfiles. That way, Moz
users could use any of the following lists:

http://altavista.digital.com/cgi-bin/query?pg=q&what=web&fmt=.&q=%2Bjunkbuster+%
2Burl%3Ablocklist

Obviously, the longer the blocklist gets, the greater the performance hit. Some
hashing/caching strategy could be employed to recover lost performance. Taking
this idea up to the UI level, the Prefs dialog would then have an entry that
looks like this:

    ( ) Block images that originate from sites in this list:
           [___________________] (enter filename or URL)

Then somebody could enter, say: "http://www.vex.net/~x/data/antro-bust.txt" in
the text box.

...

On a slightly different note, another feature I have considered submitting was
along the lines of "page filters". The idea here is that you could have a plug-
in sort of architecture that sits between the socket reading and the rendering /
page display. Right here you could plug in N number of page filters that may /
may not alter a page based on its content. For example: you could  have a page
filter that reads the <HEAD> section of pages and if it matches the string
"FrontPage" it filters the page through the demoroniser before sending it on to
Gecko.

The "page filter" plug-in architecture could be generic enough to allow for
image blocking as well; you would have a plug in that reads the <IMG> tags,
looks at the value of the SRC= attribte and checks it against a blockfile list,
a regex, or whatever.

Anywho, hope these ideas help get people thinking.

Comment 31

[Nathan Kirkham]

A non technical view ...

Another problem with this feature is that blocking sites is undesirable from the 
web site owners point of view, they need it to support the running of the page.  
You could end up with a 'arms race' where mozilla attempts to out-wit adverts, 
with web site owners out-witting the mozilla code.  A loop which I doubt mozilla 
could win.
Even if it could be won, if I can not show my advertisments on the mozilla 
browser, why bother to allow the Moz browser to show the site at all.  Perhaps I 
would show a page requiring this blocking feature to be disabled before access 
is allowed.
Assuming it doesn't go that far it will not be an encouragment for web site 
owners to ensure their sites work with mozilla if their revenue stream is being 
removed.

Comment 32

[Matthew T (active 1999-2002)]

Mark: The junkbuster-like list would be a good idea, but that should really be 
filed in a separate bug.

Nathan: Sure, you can develop a Web site which absolutely insists on images being 
shown, if you like. Just don't expect it to become popular. And don't expect 
disabled people to be able to use it. And don't expect commuters to be able to 
use it. And don't expect to win any govt Web design contracts while it's in your 
resume. Etc, etc, etc. With regard to your specific example, that of 
advertisements, most users would be far happier with (and far more responsive to) 
well-written text advertisements than banner ads.

Ok, the final cut (I think) for the dialog:
+------------------------------------------------------------+
|[] Block Image :::::::::::::::::::::::::::::::::::::::::::::|
+------------------------------------------------------------+
| (*) Do_n't block images like this one                      |
| ( ) Block this image using advanced _rules  ( Rul_es ... ) |
| ( ) _Block images which                                    |
|     (*) are the same _size as this one (149 x 32)          |
|     ( ) are from the same _domain as this one              |
|     ( ) are both the same size _and from the same domain   |
|                                                            |
|     Domain for blocking:                                   |
|     (*) (_1) x42.ads.admeisters.com                        |
|     ( ) (_2) *.ads.admeisters.com                          |
|     ( ) (_3) *.admeisters.com                              |
|     ( ) (_4) *.com                                         |
|                                                            |
| [?]                                  ( Cancel ) ((  Ok  )) |
+------------------------------------------------------------+

Notes from my previous design still apply, with these additions/corrections:
* `Don't block images like this one' should always be enabled, contrary to what I
  said earlier.
* When opened, the dialog should reflect the current settings for the image it
  was opened from.
* Keyboard mnemonics have been chosen to be localization-friendly, so don't mess
  with them unless you know what you're doing.

Ok Morse, over to you ...

Comment 33

[[e-mail]]

I've just got bitten by this pref because it conflicts with <BASE HREF=...>.

Comment 34

[Daniel Veditz [:dveditz]]

Changing fictional "M30" to reality

Comment 35

[Matthew T (active 1999-2002)]

*** Bug 33724 has been marked as a duplicate of this bug. ***

Comment 36

[Dagfinn I. Mannsåker]

Adding self to CC out of curiosity/interest

Comment 37

[Blake Ross]

Morse, do you have any plans to implement this?  Can you point me to where the 
current image blocking is handled?

Comment 38

[Stephen P. Morse]

Image blocking starts in if.cpp and then passes control to nsCookie.cpp where 
the actual decision of whether or not to block is made.

Comment 39

[sairuh (rarely reading bugmail)]

*** Bug 63816 has been marked as a duplicate of this bug. ***

Comment 40

[Stephen P. Morse]

.

Comment 41

[Rob Foster]

What if I want to filter by filename? Or Path? What if we combined reg
expressions with a interface that's easy? You'd have to dumb down the regex
somewhat but...

[pulldownMenuA]  [pulldownMenuB] [Textfield]


pulldownMenuA would have such choices as Server, path, filename, link etc while
pulldownMenuB would have is, isnot, matches, contains etc. Clicking on a "Add"
button would ad that expresion to a listbox.

The problem I have with some of the proposals here is they don't allow very much
flexability, and the best way to ensure that users understand the feature and
use it right is by making it broad and FORCING them to set it in a custom
fashion. That way they think though what their doing. Additionally I'd like to
see a "Advanced" button with true regex support. Perhaps a hybrid of this and
what Mark Whitley proposed?         

Comment 42

[Matthew T (active 1999-2002)]

That's what the `Rules ...' button is for.

Comment 43

[dave]

Hi
Here's my comment as a Mozilla user. I think all these ideas about allowing
regexs, listing allowed domains, targeting image sizes, etc, etc is way to
complicated for Joe Random user. Mozilla is supposed to be a browser and you
should stick to that goal. If users want sophisticated filtering they can get
Webwasher /  junkbuster / whatever.

My recommendtion would  be to stick with 3 options (No images, originating
domain only, all images) and put a warning that choosing the middle option may
break some sites.

my 0.02euros

dave

Comment 44

[Dan Tobias]

As I've commented in other bugs, it might be a nice idea to have a configuration
switch between "Newbie Mode" and "Power User Mode", with the newbie mode
installed by default, wherein the power user mode can be filled with complex and
powerful features that are likely to be confusing, intimidating, and/or
dangerous to novice users.  That way Mozilla can serve both audiences.

Comment 45

[A. Craig West]

My personal take on this problem is to have the current three options, but have
some mechanism for whitelisting sites that would normally be blocked. In
general, I want to block foreign images, except for a few. In my case, it is
acceptable for me to have to jump through some hoops to add a few needed sites
to a white-list, and block all other foreign sites. For example, I could turn on
all-sites option and the ask-me option (temporarily), browse to the site that I
am having problems with, and say yes to the images that I actually want to load.
Then, I switch the settings to block-foreign, and don't-ask, and I am set. This
doesn't work at the moment, however.

Comment 46

[Brian Carpenter [:geeknik]]

This isn't much of a comment, but how about taking a look at how AdShield
(www.adshield.org) works for, *gasp*, IE.

--Suppresses the download and display of ad images and ad pages and the 
launching of ad browser windows. 
--Seamless integration with the browser provides a point and click interface 
for identifying the source of advertising and blocking it. 
--New drag and drop interface makes it even easier to identify and block ads. 
--Dynamically removes and restores images and pages as they are identified 
without refreshing the browser. 

It allows you to block .doubleclick. which blocks everything with doubleclick 
in it, or a directory like /ads/ so that any URL with /ads/ in it, is blocked 
from displaying an image, or full URLs such as 
http://images.slashdot.org/banners/ so that only that URL is blocked from 
downloading images.  The only downside to this system is that if you want to 
visit www.doubleclick.com, you have to remove it from your block list.  But who 
wants to visit that site anyways?

My 2 cents.

Comment 47

[jerry asher]

Another big producer of ads appears to be something called RealMedia that
usually is hosted on the originating server.  Yes, I would like to see a more
generalized pattern matching facility too.  

Comment 48

[Tim]

Bug 78104 covers regular-expression based blocking of images.  As it stands
right now, catching redirects would probably require some redesign of the
content-policy system, since it's currently only called from content before
loading and before processing elements.  For redirects to be caught, networking
would have to be brought into the loop, as well (indirectly or directly).

As a side note, if anyone reading this is busy implementing it behind the
scenes, note that many have expressed desires in other bugs for similar
permissions to apply to arbitrary content types (personally, I'd like to be able
to block all transcluded elements--scripts, embedded media, inline-framed pages,
etc.).

Also note that the current design of the image permission system deals only with
hosts, not entire URLs.  Bug 78104 shows the minor changes needed to allow it to
act on (nearly) complete URLs.

Related bugs include bug 86194, bug 91783, and bug 91785.

Comment 49

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 50

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 51

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 52

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 53

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 54

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 55

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 57

[Charles Evans]

addon refcontrol 
Works with Firefox 1.5 - 11.*, SeaMonkey 2.0 - 2.0.* 
https://addons.mozilla.org/en-US/firefox/addon/refcontrol/?src=ss
solves this completely!

Comment 58

[Charles Evans]

(In reply to Charles Evans from comment #57)
sorry for the bugspam, wrong add-on.

addon requestpolicy
Works with Firefox 4.0 - 13.0a1, SeaMonkey 2.1 - 2.10a1 
https://addons.mozilla.org/en-US/firefox/addon/requestpolicy/?src=ss

solves this completely!

Comment 59

[Charles Evans]

can anyone summarize what is wanted beyond the features of requestpolicy and:
Adblock Plus  -  filter subscriptions in dozens of languages which automatically configure it 
    for purposes ranging from removing online advertising to blocking all known malware 
    domains. Adblock Plus also allows you to customize your filters with the assistance of a 
    variety of useful features, including a context option for images, a block tab for Flash 
    and Java objects, and a list of blockable items to remove scripts and stylesheets.
    Works with Firefox 3.6.13 - 14.0a1, Mobile 4.0 - 14.0a1, SeaMonkey 2.1 - 2.11a1,
      https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/?src=ss
and:
Element Hiding Helper is a companion extension for Adblock Plus meant to make creating 
       element hiding rules easier. Works with Firefox 8.0 - 14.0a1, SeaMonkey 2.5 - 2.11a1
           https://addons.mozilla.org/en-US/firefox/addon/elemhidehelper/?src=ss
?
(I doubt if these will do the image size rules,
 but I don't recall needing that. Maybe a rule to collapse blocks of a given size and xpath 
 would be useful?  )

Comment 60

[Phoenix]

Current Data Manager allow to block/accept images on per site/per domain basis, is this bug still actual?

Comment 61

[Phoenix]

Resolved per whiteboard

Comment 62

[Jason Smith]

what about the antivirus ? http://nortonphonesupport.com