mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Nov 2007
Posts: 3
S
soczol Offline OP
Self-satisified door
OP Offline
Self-satisified door
S
Joined: Nov 2007
Posts: 3
I found that the following piece of code will skip the 'Initialization warning' dialog.

Simply put the following code in a .mrc file and try to /load -rs it.

Expected behavior: Warning
Actual behavior: Script is executed immediately

Code:
 
#groupbug off
on *:start:
#groupbug end

on *:start:{ 
   echo 4 -a If the bug is succesful, this script ran without any warning..
}


Tested on mIRC 6.31 and mIRC 6.21

Last edited by soczol; 06/11/07 08:30 PM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I wouldn't call this a bug. It's not the only way to skip the initialization warning, there are plenty of others. The initialization warning should not be your only defense in using scripts. Users have to execute some kind of discretion about what scripts they do or don't load, either by looking at the scripts beforehand if they're capable, or only downloading from trustable sources (script sites with mandatory review processes, etc) if they aren't.

As far as your specific code goes, there's no way to tell whether your grouped on start event is legitimate or not-- the syntax you posted above *does* have legitimate uses and therefore it itself cannot inherently be a bug. For instance, a scripter may decide to use groups rather than if statements to check for "first start" status, saving a variable:

Code:
#first_start off
on *:start:do_normal_initialization
#first_start end

on *:start: {
  echo -a This is the first time starting mIRC with this script loaded, blah blah blah. 
  .enable first_start
  do_first_time_initialization
}


Of course, they could have reversed the group (start with on state, disable group) which would trigger the initialization warning, but there's no reason to force such a style on a programmer, when a user could just do:

Code:
on *:APPACTIVE:do_something


And pretty much guarantee that it will execute at some point in time (even though it's technically not on *initialization*). There are many other events a scripter could hook into that are essentially guaranteed to trigger, meaning initialization warning or not, the check is bypassable.

We could go back and forth forever on all the ways to get around mIRC's sanity checks, like disallowing recursion calls or calling modal dialogs from events-- the lesson here is that there is really no way to truly police a script when you give it full execution control at *any* point in time.

All that said though-- bug or not, mIRC should check for all on start events in a script and not just stop at the first.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Nov 2006
Posts: 1,559
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
Agreed.
Knowing this, does this not render the warning quite unreliable, and couldn't one say it gives users a "misleading feeling of security?" (I think that's something to reconsider)

For example, I can image:
- A general popup which informs the user "on load" about the possible risks of remote files
- A checkbox (options) that let "advanced users" skip this popup... unchecked by default of course smile

Last edited by Horstl; 06/11/07 10:26 PM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Horstl:

This feature exists, and you can turn off the initialization warning through the script editor already.

The OP was referring to a way to bypass the initialization warning even when on.. he wasn't suggesting such a warning be added (since it already exists).

Or maybe I misunderstood your post


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Nov 2006
Posts: 1,559
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
My point was:
As there are numberous ways to bypass the initialization warning, why not warn in general?

It was just a suggestion - I think a general warning might be a more suitable approach (opposite views welcome!), as I cannot imagine a sufficient method to detect all (or most) of the ways in which a code could contain malicious or even "pseudo init" commands.

Warning is important in itself, especially with regard to new users who are often quite unconcerned about the possible dangers.
And we should never forget that these forums are some kind of ivory tower; only a fractional amount of mIRCs users is able to read and evaulate such code...

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Sure. I was going to suggest that, but I personally don't have any stake in it--

You could argue that mIRC should drop the initialization warning for on LOAD/START events only, but rather for *any* triggered event originating from that script (assuming it was the first one). It's the only way to reliably warn about a script doing something on its own after being loaded. That has problems though, namely because that means any event could generate the modal warning dialog box which violates general UI principles about randomly popping up dialog boxes. Otherwise you could just put a general warning whenever /load is called (forget event triggering altogether) but you risk habituation, another *BAD* (worse, in fact) UI mistake. In that case, people would just start to ignore the message-- it would be like crying wolf.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Nov 2007
Posts: 3
S
soczol Offline OP
Self-satisified door
OP Offline
Self-satisified door
S
Joined: Nov 2007
Posts: 3
Woah a lot of replies already.

Well basically I was trying to circumvent the warning dialog, as I think it is rather annoying and i don't think it will prevent anyone from clicking 'Yes' anyways. We wanted to create an auto-update functionality of our script, but mIRC kept asking if it was okay to initialize the file - over and over.

I'm calling it a bug because it does not show the same behavior in different situations. Making the protection kind of useless. This does not mean that I think this protection should be there tho.

I think checking for 'just' on load/start is pretty useless: it's giving you a false sense of 'security'. Users will think "ah, mIRC didn't warn me this time, so it's probably good to go". But what if when someone that wanted to do harm, leaves out the 'on start' event but triggers 'evil' code on an 'on input' event (or whatever)? Isn't that as bad?

My point is that such a dialog is quite useless when it's implemented this weird. Do I want the current dialog for all /load events? Heck no, that's even more annoying and will for sure have people *always* click Yes instead of really reading the warning.

The best solution for this; I wouldn't know. In a way it would be 'bad' to turn off the protection - as some users might actually read the warning. Maybe some standard dialog with a checkbox "Don't warn me again" - for all scripts - would be the way to go. I think that way you'll 'teach' the users to not execute random scripts from people they don't trust, without making the message overly annoying. The option to turn them off is already created, just hidden away in the script editor.

Last edited by soczol; 07/11/07 08:29 AM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks this has been fixed for the next version.


Link Copied to Clipboard