Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: SB1.5 has a serious functional flaw, imho.

  1. #1
    Member
    Join Date
    Jan 2006
    Posts
    76

    Lightbulb SB1.5 has a serious functional flaw, imho.

    As we all know users have to click on the "immunize button" to interface with the specific "immunization" function of SB in all version going back to v1.2 when immunization was first available.

    What I have found when installing SB1.5 is that whenever the user presses the "immunize" button then SB1.5 "immunizes" all items available.

    SB1.3 did not do this what it would do is open the screen to interface with the various options to "immunize" but would not just go ahead and "immunize" unless the user clicked on the button at the top of the "immunize" screen to "immunize".

    Why is SB1.5 problematic the way it functions regarding opening the "immunize screen" and going ahead and "immunizing" all items?

    Because the user may not want all items "immunized".

    In SB1.3 when you enter the "immunize" interface screen the only thing that happens is that SB1.3 will check if there are items available that are not being protected and let the user know if this is the case. It is up to the user to then click on the "immunize" button to "immunized" unprotected items.

    I would have expected SB1.5 to either NOT "immunize" everything upon entering the "immunize" screen or at least leave alone "profiles" that are "unchecked" (not selected by check mark).

    In other words I would have assumed that if "profiles" are NOT CHECKED then they would be LEFT ALONE. But instead I found that all items are "immunized" and if the user did not want all items "immunized" then the user had to undo after "checking" (selecting the "profiles") to "UNDO" "immunization" since all is immunized even if "profiles" are unchecked. First I don't understand why "immunization" is done when simply entering the screen for "immunization" functions, but even more puzzling is why aren't UNCHECKED "profiles" left alone and not "immunized" after all they are "unchecked", right?

    This is very time consuming, especially for a dial-up with several of the "profiles" having over 8K sized items in the specific "profiles".

    In my case I had to have all of my Firefox "profiles" "unprotected" in order to solve "unresponsive Script" problems with SB1.5 before I was finally able to eventually then set all to "protect". It was very annoying every time I used the "immunize" screen to have to continually wait for all to be "protected" and then to then select "profiles" to set to "unprotected" and wait all over once again for that to be done.

    Bottom line: SB needs to LEAVE ALONE ALL PROFILES THAT ARE NOT SELECTED (NOT CHECKED) and preferably not "immunize" AT ANY TIME (before entering the "immunize" screen) but to only do so when the user clicks the "immunize" button WITHIN the "immunize" screen. The "immunize" button WITHIN the "immunize" screen should be what takes care of ALL immunization.
    Last edited by caterwaul; 2008-06-18 at 20:08.

  2. #2
    Member of Team Spybot PepiMK's Avatar
    Join Date
    Oct 2005
    Location
    Planet Earth
    Posts
    3,571

    Default

    Are you using 1.5 or 1.5.2?

    Thanks for a very detailed report, even though I can't reproduce it

    1.5 is checking all items when you enter the immunization screen, to be able to present you the numbers.

    Checking is imho essential for the users choice on what to do there, displaying nothing until the user has pressed Check (now named Check again) would be quite uncomfortable imho.

    But in the end, Spybot-S&D does exactly what you requested: it does immunize only when you press on Immunize, I just tested that with 1.5, 1.5.2 and 1.6 beta.

    To be honest, I'm quite confused where the source of confusion here could be, I don't think I have misunderstood you, and neither that a usage error could lead to the behaviour you seem to describe
    Just remember, love is life, and hate is living death.
    Treat your life for what it's worth, and live for every breath
    (Black Sabbath: A National Acrobat)

  3. #3
    Member
    Join Date
    Jan 2006
    Posts
    76

    Default

    That was fast...

    I am using (or was) SB1.5.2 (sorry for not clarifying). I say "was" because I went back to my SB1.3 that works since I was always getting "Fatal Exception (05)", blue screen errors using SB1.5.2 and as I posted in another thread: http://forums.spybot.info/showthread.php?t=29644 I was able to narrow the crash down to it being related in some way to SB1.5.2 because 1) I never have had this problem for years with SB1.2 and SB1.3 and 2) If I "Exit" Teatimer so that is no longer running and not in systray then my computer will not crash at all. I tested the running SB1.5.2 6x's with crashes and 4x's without running with no crashes.

    But I digress... sorry again...

    Back to this topic

    What I found (unless I have completely lost my mind which is possible) I had selected all Firefox profiles to be "unprotected" using the "undo". I was having other issues that precluded my doing this (posted in another thread as well).

    When I would go back into the "immunize" interface screen from the SB1.5.2 "main screen" what would happen for me is that all items would be "immunized" at that time.

    I then thought... how am I going to get around this...

    So I again "unprotected" all of the Firefox "profiles" and then decided to "uncheck" all Firefox "profiles" and leave all other "profiles" for IE "checked".

    My thinking here was that if I wanted to go back into the "immunize" interface screen from the SB1.5.2 "main screen" then SB1.5.2 would only immunize the "profiles" that were "checked" and leave alone the "profiles" that were "unchecked". But to my dismay I found that ALL "profiles" were once again "immunized" regardless of what is "checked" or "unchecked".

    Are you saying that "unchecked" "profiles" in the "immunized" interface screen should be left alone as they were? Because that is what I would have expected would be the case.

  4. #4
    Member of Team Spybot PepiMK's Avatar
    Join Date
    Oct 2005
    Location
    Planet Earth
    Posts
    3,571

    Default

    Hmmmmm...

    To be fast again :D just a very quick question: was Firefox still open while doing that?
    If you do any immunization action on Firefox while Firefox is still open, Firefox might undo it (in both directions, undoing immunization if you're applying it, "redoing" it when you're undoing it) because it discards changes in the file and overwrites it again with the version from its memory.
    In that case (Firefox still running), the next check after an undo might again reveal full immunization because Firefox was updating the file.
    Just remember, love is life, and hate is living death.
    Treat your life for what it's worth, and live for every breath
    (Black Sabbath: A National Acrobat)

  5. #5
    Member
    Join Date
    Jan 2006
    Posts
    76

    Question

    Quote Originally Posted by PepiMK View Post
    Hmmmmm...

    To be fast again :D just a very quick question: was Firefox still open while doing that?
    If you do any immunization action on Firefox while Firefox is still open, Firefox might undo it (in both directions, undoing immunization if you're applying it, "redoing" it when you're undoing it) because it discards changes in the file and overwrites it again with the version from its memory.
    In that case (Firefox still running), the next check after an undo might again reveal full immunization because Firefox was updating the file.
    Well you've got me confused as far as your explanation... but to answer your question yes I did have the Firefox Browser open...

    In most cases one will usually have a browser open actually.

    So does this mean you cannot have the browser open that you may have "unprotected" "profiles" for that specific browser?

    I'm not sure why having Firefox "still running" would or should cause "unprotected" "profiles" to become "immunized" again when those "profiles" have been "unchecked".

    It would seem to me that "unchecked" "profiles" should be left alone under any circumstances and should never become "protected" when they were initially "unprotected" and have not been "checked" (selected) for any action so to speak.

    I understand that SB1.3 is a simpler interface but that is what SB1.3 does (or maybe I should say does not do)... in that nothing will be immunized in SB1.3 when you press on the "immunize" button on the SB1.3 "main interface". That is what I would say the "immunize" button is for in the specific "immunize" screen interface - to then "immunize" if the user so chooses.

    In other words the "immunize" button to enter the "immunize" screen FROM the "main" SB1.5.2 program should ONLY open up the "immunize" screen with all the functions then available for the user to do what ever the user might want to do rather than actually "immunizing" when opening up the "immunize" interface screen that offer the user all of the "immunization" options within that specific screen.

    In SB1.3 no "immunization" is done at all before entering the "immunization" screen, only a check to see if there are items available that are not "immunized" and a message supplied to the user regarding this fact.

    I hope I'm making myself clear... imho, no action of any kind should be done at all as far as any kind of changing of "immunization" until the user is actually IN THE "IMMUNIZATION" interface screen itself at which time the user can THEN "immunize" if the user so desires to do so.

  6. #6
    Member
    Join Date
    Jan 2006
    Posts
    76

    Default

    ^ addendum to above post (couldn't edit my post for some reason even though I was logged in)

    .... the way SB1.5.2 is NOW (besides taking up so much more time) the user cannot simply go in and CHECK what the user has CURRENTLY SET as far as WHAT ARE "protected" or "unprotected" "profiles" (since the user will get "immunized" at the time the user opens the immunization interface window ("immunization status window" so to speak).
    Last edited by caterwaul; 2008-06-18 at 22:18.

  7. #7
    Junior Member
    Join Date
    Jun 2008
    Location
    Rio de Janeiro (WiFi account)
    Posts
    27

    Default

    Just checked, Pepi is right, after clicking on the immunize button in 1.5.2.2 (in default mode) it does a check to see what items aren't immunized. undid my immunization (with FF open) and went back in, checked and 11 things -were- immunized, in the FF: Images, Installations and Popups profiles.

    Not sure if most people would have the browser open at the same time as running the immunization, but (whoever has the same problem) could try closing the browser then checking the immunize screen .

    - Chris

  8. #8
    Member
    Join Date
    Jan 2006
    Posts
    76

    Lightbulb

    ^ I would personally call that a "bug". ... clearly the leaving Firefox (FF) "open" causing this is an unintended consequence.

    I personally can't check if it makes a difference as far as FF "open" or "closed" since I went back to my SB1.3 that works for me.

    In my view just clicking the button to get into the interface screen to view the "immunization" page and to optionally apply changes SHOULD NOT "IMMUNIZE" just opening the screen.

    There is a button in the "immunize" screen to do that.... I'm a long retired programmer myself and would leave making any changes by the user to only functions within the screen with the "immunize" information and options.

    I clearly do not have a problem with SB1.5.2 checking if items are not included in the profiles and then recommend an update to do add the missing items but why "immunize" just because the user wants to open the page for "immunization" status and functions?
    Last edited by caterwaul; 2008-06-19 at 18:23.

  9. #9
    Junior Member
    Join Date
    Jun 2008
    Location
    Rio de Janeiro (WiFi account)
    Posts
    27

    Default

    Mmmm not sure if it's classifiable as a bug, most installers tell you to close all other programs running, so maybe that could be put in, as if not it's likely to cause problems.

    Well, I have to agree with Pepi, just clicking to open the immunize screen -doesn't- immunize, just checks numbers. (although as pointed out in another thread [i'm really ANGRY about SB, something like that] the hosts file, at least, is immunized on program start..)
    Again, what's written above, just opening the tab is like clicking the "check [again]" button, the user -does- have to click the immunize button to immunize (unless an immunized item is open, in which case things are likely to go a little haywire)

    - Chris

    Easy reference: Suggestion! - put a notification in to close all other programs before immunizing (and maybe also before running a scan?)

  10. #10
    Member
    Join Date
    Jan 2006
    Posts
    76

    Default

    Quote Originally Posted by ChrisWarFi View Post
    Mmmm not sure if it's classifiable as a bug, most installers tell you to close all other programs running, so maybe that could be put in, as if not it's likely to cause problems.

    Well, I have to agree with Pepi, just clicking to open the immunize screen -doesn't- immunize, just checks numbers. (although as pointed out in another thread [i'm really ANGRY about SB, something like that] the hosts file, at least, is immunized on program start..)
    Again, what's written above, just opening the tab is like clicking the "check [again]" button, the user -does- have to click the immunize button to immunize (unless an immunized item is open, in which case things are likely to go a little haywire)

    - Chris

    Easy reference: Suggestion! - put a notification in to close all other programs before immunizing (and maybe also before running a scan?)
    Well I'll stand by by view... We are not talking about "installing" a program (which is when you will see this recommendation you refer to as far as not running other programs)... Instead we are talking about a database "update" which is what "immunization" is....

    The user should certainly should not have to worry about applications running when "updating" a database in another application that has already been "installed", and especially a web browser which would be the most likely application a user would have open.

    As far as when the user "opens the immunize screen" from my experience it does more than "just check the numbers"... "just checking the numbers" is exactly what I would expect and want the screen to do and nothing more... this is the issue at hand that it does MORE than "check the numbers" and the consideration here is that this maybe caused by having the FF browser "open".

    Again I contend this should not be the case and "opening the immunize screen" should not change any immunization "settings" like for example some "profiles" set as "unprotected" no matter whether a browser of any kind is open or any other application for that matter. If a "profile" is set as "unprotected" and if this "profile" is not selected (no check mark "tick" applied) then SB should not add any items to be protected to that "profile" under any circumstances when just opening the "immunize screen". As I've said this is what the "immunize button" or the "undo" button for that matter in the "immunize screen" SHOULD be for based on which "profiles" have been selected to be changed.

    So from a programmers standpoint (which I have been for years) I would consider this a "bug"... sorry... In software there are always conditions that cause "unintended consequences" sometimes these "consequences" are not problematic and in some cases might even add to the program in which case we programmers would commonly joke that the "unintended consequence" amounts to an added functionality.... but in the case when an "unintended consequence" causes "settings to change" that would not be anticipated or desirable like in this case there is no other way around it than to classify the "unintended consequence" as ultimately a "bug", imho.

    Don't get me wrong... I think SB is a great application and I totally applaud and can't say enough good things regarding those who are responsible for SB and the people that support this application which is clearly without a doubt a very helpful and noble service to the internet community.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •