Hello people!

I've done some research about scripting in MP2.00 and I've come to a conclusion. I thought it would be nice if my forum's users knew it before everybody else (400,000 users worldwide...thanks again!).

First, I planned to create my own scripting language... problem is that it would have taken a lot of time, you would have to learn it, it wouldn't be very powerful, etc... then, I found something great that I'm finally gonna use. I'll spare you the technical details but the result is this: MP2.00 will be scriptable with VBScript, the latest version available! this means that if you already know this language, you'll be able to develop in MP2.00 very quickly. If you don't, learning it is very easy and you can use your knowledge later on your web page, Office softwares, ....

Basically, MP2.00 will define events, like "MessengerStarted", "ChatStarted", "ChatEnded", "TextReceived", "TextIsBeingEntered", etc... you'll be able to attach your script to any of these events... to communicate with MP2.00, I'll define several objects, like "MainMessengerWnd", "ChatWnd", "MessengerProperties", containing methods and properties. You'll even have a "CustomProperty" object that you'll be able to use to store your own parameters and options. All these tools will allow you to do advanced stuff like creating your own dialog boxes, adding stuff in the menus, sending whatever text you want to the user, etc...

The point is that to proove the efficiency of the MP2.00 scripting feature, stuff like logging or quick text will be entirely scripted! it will give you good examples to start, you'll be able to change what you want in the built-in functions and it will allow me to test my own features.

Maybe it's too soon to talk about it but hey, what the hell, I'm felling well today ... when MP2.00 Beta will be public, I'll organize a contest... your goal will be to create a great script with a great feature... the best scripts will be distributed with the final version of MP2.00! well, that's all for now, see ya!

Patchou

Wow, that sounds powerful!

Note to self: must learn this "VBScript" thing...

Same:

Mental Note: Learn VBScript

LOL... well, you can start as low as VBScript For Dummies, it's a good book. I'll also provide some useful links on Microsoft web site in the near future.

Anyway, if you're not stupid, and you're not right? , you can learn VBScript basics in an evening. Also, maybe I'll create a new forum to discuss vbscript but it's a little bit out of topic. Here is an example to encourage you... if you want to display a hello message, here is the line in vbscript to do it:

MsgBox "Hello!"

(MsgBox stands for MessageBox) ... well, I'm sure you'll have fun

Patchou.

quote:

---

Originally posted by Patchou
Anyway, if you're not stupid, and you're not right?

---

quote:

---

MsgBox "Hello!"

---

i can do perl so maybe i could strech to VBScript lol

Just think... when "MP2.00" is released, we'll all be exchanging our VBScripts on the forum...

* WDZ is gonna try to learn VBScript tonight...

allready doing it

Well now I have something that makes me want to learn a language 

I'm sure it can't be too hard, did soem basic C++ shit, foudn it easy but couldn't be bothered 


And to the "your not stupid thing", wait till ChroMo posts, then you'll re-consider 

rotf

Learn VB Script?
Hmmm.. Learning never ends.... that sure a fact. Have to fresh up things. Lemme get ready to start again

quote:

---

Originally posted by Muss
Well now I have something that makes me want to learn a language 

---

quote:

---

And to the "your not stupid thing", wait till ChroMo posts, then you'll re-consider   

---

Will it be pure VB Script or just Windows Scripting Host compatible (i.e. are you going to write your own compiler/runtime, or just use the one Microsoft give out with IE?). If it was Windows Scripting host then people could use JScript (a far superior language in my opinion ) or Perl, or Python, or Ruby, or anything else that has Windows Scripting bindings, and without much work for you, certainly no extra work per extra langauge.

So who did bring scripting the very first to Patchou's ears and eyes... yes... your very own Jae

Okokokok, won't say that again (but it's true tough )

VBscript sounds very nice and powerfull... and it 'll save you lot's of time, which is great too.


* Menthix starts google and begins searching for VBscript tutorials

Yep, Jae is right.

Ginge... it's a pleasure to talk to someone that knows that kind of thing... well, as you guessed it will be Windows Scripting Host compatible... I didn't thought that there were much differences with the "normal" VBScript. Can you tell me more about it?

For the other languages... well, I know about it and I also know that there is no extra work needed by me. However...  VBScript is easy to use and I can understand it... I'm not very used to read some Perl languages and I want to keep control of things... another problem also is that if I support multiple languages, people are going to wonder why the script do not work at their home, it will be because theur version of *any language* is too old or does not exist on their computer etc....

What I'm willing to do is support VBScript and JScript.l.. what do you think? in fact, that would be very nice if you could tell me what you think is better is JScript compared to VBScript.

Thanks, like they say at Fox44, "together, we can make a difference"
Patchou

Man, its all going on here... and if only I didnt have that 50 page assignment to do.

Uhmm... I can learn php so why not VBscript.

JScript is more powerful aswell i think but include Perl because i know that alreadyt

Windows Scripting Host (or maybe its called ActiveX scripting and is just used by the WSH, not too sure on that point) is just using the MS scripting engine, you give it the script, some bindings (COM objects) and a language ID (VBScript, JScript, ...) and then you set it off. If you were going to use the normal VBScript engine (and not write your own) then the difference should be about as profound as giving a language ID when you run the script.

VBScript and JScript are both installed by default (the only ones that are), so are a good choice to support. I think PerlScript and others should be an option for those who want that kind of thing, just make sure you don't advertise it too heavily and don't bundle any non JS/VB scripts.

I prefer JScript over VBScript because JScript has far better array/dictionary support integrated directly in, it is cross platform and a standard (EMCAScript) - you can use it in Netscape/Opera, the string manipulation methods are better, it shares all the keywords/semantics with C++ (useful for you). Also classes, memory allocation and dynamic functions were added in far earlier versions, and not all of them are present yet present in VBScript. However, they are both just as powerful, its merely my preference.

Ok then, I'll support both... but no Perl or other, sorry.. at leat, for VBScript and JScript I can control it and install the latest version directly so I'm sure that every script work perfectly.

Having just looked at one of my old VB programs that offers scripting using the Microsoft Scripting thingy, it is as simple as setting object.Language = "VBScript" or similar, being that this is so couldn't you just have the first line of every script file as the script language? (Possibly sensible defaults for .vbs and .js files)

That way people could write their own add-on's in Perl, which has specific text processing advantages, and would be ideal for writing Bot's to do clever auto-responding. If you only distribute JS/VB scripts then people will be sure that all the bundled scripts work, and you can leave it to those that want to give out Perl scripts to supply links to Perl scripting engine etc.

Forum note: Where have forum email notifications gone!!

JScript isn't the same as JavaScript, is it? Is the syntax of JScript similar to VBScript?

quote:

---

Originally posted by Johnny_Mac
Uhmm... I can learn php so why not VBscript.

---

quote:

---

Originally posted by ginge
Forum note: Where have forum email notifications gone!!

---

That's always the same problem you know.... flexibility against reliability. For now, I think I'll restrict it to the two VBScript and JScript languages. The main reason being that when people are going to start distributing their scripts, I want to ensure that any script potentialy work everywhere. Else, a lot of people will be confused bewcause they won't even know what Perl is... well, I may change my mind.... we shall see

WDZ: do not worry, I'll give plenty of samples along with my MP2. As I said, I plan to recode most of my software using the scripts. However, I'm not a VBS or JS expert myself so don't hesitate to report me strange things that you might see in the scripts I distribute. The beta period will be for that.

Well, I'm leaving for home soon. This we is a programming we. My girl friend has already been notified so MP2 is on track, for real!

JScript is JavaScript (or MS's version, with the occasional extra feature), nothing too different - most people use the terms interchangeably, and can't tell the difference between them.

VBScript is not in any way like JScript in syntax terms (compare C++/Java with Visual Basic, it's pretty much the same gap), but they are the same semantically (meaning wise), so once you know one the second shouldn't be too hard to pick up, and its quite easy to port between them (very easy if its VBScript -> JScript).

If its going to be limited to VBScript and JScript then you'll need to pick a version, there are some qwerks with some versions that destroy reverse compatibility (IE 5 has a bug in JScript that 'undefined' is undefined, but not in IE 4 or 5.5 or 6), and newer features in VBScript (Eval, Class) are only in newer versions.

PERL i need it              

quote:

---

Originally posted by reisyboy
PERL i need it                

---

I know some of it from learning Visual Baisc but i dont like ti i like Perl\Cgi

Then don't learn VBS, learn JScript - it looks more like Perl (it has the whole {} thing going on), has regular expressions (not as good as Perl, but useable), and doesn't have annonymous variables passed around the place (you must hate that with Perl - I do). VBS is however easier to learn as a first language, but both of them are much easier than Perl.

But i already knwo perl ok well i will watch JScript aswell

So you can learn VBScript Rboy.. Its damn easy... I've already started.. but damn the work have no time at home.

Donno about Jscript though.. Might be similar.

I am learning JScript seems alot better than  VBscript just need pathou to add perl to nice n easy

haaaaaaaaaaa... why so many people are talking about Perl? I never understood this language lol j/k

I agree, even the people who wrote it have given up and started again for version 6!

Perl is more powerfull than JScript and VBScript in my opinion thats why i it

They are all Turing Complete, so none is more powerful than any of the others, and you could write a Perl interpretter in JScript and then use that.

In fact I think it may be possible to spawn your own scripting engine from within a script, so you could still write in Perl and just have a small JavaScript wrapper (although Patchou can stop this if he wants)

ginge, you're absolutly right... I just hope that you'll be willing to put your knowledge in contribution for Messenger Plus! scripts when the Alpha version comes out... of course, this is if you're willing to accept being a beta tester

quote:

---

Originally posted by Patchou
haaaaaaaaaaa... why so many people are talking about Perl? I never understood this language lol j/k

---

1. I know you've been concerned on the security. I'd like to add: Scripts to be run on event should always be set manually.

2. Before releasing, try to write a worm with the MsgPlus Scripting platform. I hope nobody can.

3. Is there any way to interface Perl and C/C++ with VBScript/JScript/WSH? Is there a common layer for the three? DDE, maybe?

COM I suppose... I'm sure there mut be a way in Perl to use COM.

COM works fine with Perl (PerlScript), but WSH is just COM + a scripting engine bundled in a nice package, so may be more convenient.

2) I will try , it depends what you class as "security risk".

hm...maybe you could set up a place where pple can actively upload and download these mods...well most likely has been suggested...im just too lazy to read all the posts... hehe

I know VB, and I know VBS as it appears in web pages and ASP (from the tune of the programmers in here I can expect a big *gasp* in disgust) but how does VBS come to be used in msgPlus?  Is there a web page running in the background or something?

quote:

---

Originally posted by fluffy_lobster
I know VB, and I know VBS as it appears in web pages and ASP (from the tune of the programmers in here I can expect a big *gasp* in disgust) but how does VBS come to be used in msgPlus?  Is there a web page running in the background or something?

---

No, it uses the Windows Scripting Host or something like that...

VBScript has a pretty extensive API (i think its an API anyways) that allows you to execute code through the machine.. its apparently easy to integrate into software. never tried it myself though...

VBScript is te best!!!

COZ:
i know te language;
kinda.

its rly EASY to learn

rly gd software is made wth it!!!!

:vb:

would der be sum kinda tutorial?!

coz mp2, if EVER FINNISHED!!!

would look wierd to me coz its just a loda ritin and a onscreen pic of te form!!!

so ide wanna no te meanings n wat te things mean!!!


VB  RULES!!!

Patchou actually said he isn't making scripting a priority for this release, so it might not have it. There is a really easy to use API for windows scripting host, pretty much as simple as "script.Execute()", I used it for my emacs-a-like editor thingy.

yea, i think once everyone has MP2, it'll be so great that noone will want to change it anyways.

Donno if Pathcou added scripting to this ... *Thinks should not ask this .. Will wait for MP2 beta

doing a whole site on ASP at the moment, VbScript is actually a component in ASP, so i'm wrapped
(it's different to the VBScript Patchou's on about, but same concept)

No its not different at all, VBScript in IIS (or ASP as the extension to the web pages is) uses WSH (Windows Scripting Host), which is exactly the same one Patchou would use. Because IIS uses WSH you can actually use any WSH language in .asp pages - I always use JScript for example.

Hey, I'm kinda new here, but I wanted to ask ya something   You said that Messenger Plus! will be scriptable with VBScript. Now I know a little Visual Basic, so will I have a leg up with the scripting?  I hope so heh cause i really enjoyed VB.  Thanks.

Btw, keep up the great work.  I only use Messenger with MSGPlus

good for you, future version will be scriptable but not this one

quote:

---

Originally posted by RealmMaster
Now I know a little Visual Basic, so will I have a leg up with the scripting?  I hope so heh cause i really enjoyed VB.  Thanks.

---

quote:

---

Originally posted by Patchou
MP2.00 will be scriptable with VBScript, the latest version available!

---

I think Patchou said MP2 will support VBScript and JScript...

you're right Quark, however, there wont be scripting support in MP2.00. I just do not have enough time for it. But be sure I didn't forget about it. It will be there in a subsequent release.

When will MP2.1 be released?

MP2.1? I think it's a little early to be thinking about that... MP2.0 hasn't even been released yet.

Yeah it's a bit soon, boss-protection should be made to work first.

quote:

---

Originally posted by Patchou
you're right Quark, however, there wont be scripting support in MP2.00.

---

quote:

---

Originally posted by Morpheus
March or April 2003 sounds reasonable.

---

JScript or VBScript would be the ovbious choice because of the easy API integration... a new language or integration with Javascript or similar would take significant work without too much advantage.

Sounds very great, but would it be possible for psycho programmers to write MSN worms and spread it through MSN Network using this feature of MSN Plus?

P.S. If you already know VB then VBScript would be very easy to learn. If you don't, well then you should try to learn it LOL

quote:

---

Originally posted by Alpha Binary
Sounds very great, but would it be possible for psycho programmers to write MSN worms and spread it through MSN Network using this feature of MSN Plus?

---

quote:

---

Can I just check something here. The JScript that will eventually be used for MP2 scripting is the same as is used on web pages, right?

---

Note to self must learn VBscript 
15sec latter on internet learning VBscript Find a show watch it and i think to my self is this really VBscript. this is wat the show, shows in words.


Dad Yells Get off the internet u never do anything useful on it.
I yell back and say I'm learn.
Dad run to me kills me, me dead hand hits the send bottem someone reads this calls the. so on so on

I say to my self wat rubish was that.
I dont think u'll understand proplely u c i am bad at english

i dont get it isnt mp/mp1, mp2, mp3, all name of audio file the (dot).whatever thing, shuch as .exe wat are all of u talking about

quote:

---

Originally posted by RealmMaster
Hey, I'm kinda new here, but I wanted to ask ya something   You said that Messenger Plus! will be scriptable with VBScript. Now I know a little Visual Basic, so will I have a leg up with the scripting?  I hope so heh cause i really enjoyed VB.  Thanks.

Btw, keep up the great work.  I only use Messenger with MSGPlus

---

Sorry, I had to do this.

But you're right though.

Back to the worm stuff; i believe you cannot send a worm to someone without having to send it as a file; which should be accepted by the other user.
Thus it would be his/her own mistake downloading & executing the worm.

Just downloaded MP2

Great work

Any idea when scripting will be included... Been getting very excited about this!

Keep up the good work,


James

Wouldn't be unsecure.  Then i mean, anyone could just script something and it can do something to MP2 and maybe Messenger?

For those of you who can't wait to the end of my message, the conclusion is: "Making the scripting security to depend only on the file transfer accept/decline is still very risky."

Consider the following: Think of MSN (or Windows) Messenger as scriptable, speaking of what Patchou and other software writers do to extend Messenger's capabilities. Having said this, now think of all the worms that use Messenger as a spreading platform. People without the knowledge we have regarding Messenger accepts files and execute them without thinking twice. Please keep this in mind while reading my message.

Also, remember all the problems that scriptable mIRC clients imply, and also what happened when Office (Word, Excel...) applications started accepting programmable macros. Let's not make the same mistake.

Now, let's get back to MP2. Imagine an event like "OnAfterFileTransfer" which executes the file. If I write a small trojan .EXE which installs an MP2 script which secretly works in that event, executing any received file, I will no longer be able to receive files safely without executing them. Subsequent incoming files could be other worms which, would autoexecute themselves, which would turn this into a disease.

If the scripting includes an "OnStartup" event and allows the scripts to modify Messenger Plus! configuration, it is very easy to hide a worm and execute it each time Messenger (or MsgPlus) runs, reenabling worms frequently.

The last example almost speaks for itself: an "OnBeforeFileTransfer" which has been hooked to auto-receive files. Imagine it working together with the scenario I wrote for the hypotetical OnAfterFileTransfer.

This are the three most critical points I'm worried about. There are several other possible exploit points out there in any scripting environment. I would not like to see a worm named "worm.E@mmp2" (referring to Messenger Plus) or something like that.

Blaming a user who (typically) doesn't know or care about worms for accepting a file and executing it, will only be the defense against the already created disease. My different initial proposals to avoid these potential situations are:

1. Pesimistic: Not to have these kind of events planned.
2. Optimistic: To ignore this issues.
3. A somewhat better option -- When calling OnBeforeFileTransfer and OnAfterFileTransfer, not to pass the received file name. Also, to have a special special .INI file in the Plus directory, or a RegistryKey for MP2 which, before any script processing, controls wether scripting (or part of it) should be enabled or disabled, so you can recover your Messenger sessions quickly in case of an infection.

Does anybody know if, using the proposed platform by Patchou, srcipts would be able to become resident after Messenger and Messenger Plus shuts down? I'm asuming they aren't able to.

Octavio.

This would still be something that virus scanners would pick up on pretty quickly I think. There are warnings everywhere saying not to accept files from people you don't know and to virus scan every file you receive anyway. If your virus checking client has an auto-protect function then it will automatically scan the file before it is allowed to be called by MP2 so it makes scenarios such as you suggested possible but still something that can pass the blame back to the user who accepted the file transfer (unless another script accepts it automatically, but that would still involve accepting a file transfer at some point), and also could blame the user for not having virus-scanning software installed.

I don't like viruses. I don't like worms. (sounds like a poem)
They are like twisters, worse than a storm. (huh? j/k)

Moria, your approach is to correct the created problem.

My approach is to prevent the problem from being created.

Both have advantages and disadvantages. Namely, a disease and affecting the name of MsgPlus versus some lack of liberty for writing scripts.

I know Patchou will make a good decision, whatever it is. I just hope Patchou reads the message.

Octavio.

Hey guys, I'm new here...

In what version will this be inserted? Is it going to be in the next version? Or do we have to wait a little bit longer?

Greetz
JustMe

I dont think anyone knows yet - Patchou has just said 'later'.

(Yes - I exist, slightly )

quote:

---

Originally posted by MoRiA
I dont think anyone knows yet - Patchou has just said 'later'.

(Yes - I exist, slightly )

---

errr... I didn't have time to read this whole post since the last time I read it so Ill be blunt...

What happend to the scripting? Is it still in or is it gone?

Thanks!

quote:

---

Originally posted by sock


Sorry, I had to do this.

---

quote:

---

Originally posted by alvarezp
I don't like viruses. I don't like worms. (sounds like a poem)
They are like twisters, worse than a storm. (huh? j/k)

Moria, your approach is to correct the created problem.

My approach is to prevent the problem from being created.

Both have advantages and disadvantages. Namely, a disease and affecting the name of MsgPlus versus some lack of liberty for writing scripts.

I know Patchou will make a good decision, whatever it is. I just hope Patchou reads the message.

Octavio.

---

quote:

---

Originally posted by Dogga

quote:

---

Originally posted by alvarezp
I don't like viruses. I don't like worms. (sounds like a poem)
They are like twisters, worse than a storm. (huh? j/k)

Moria, your approach is to correct the created problem.

My approach is to prevent the problem from being created.

Both have advantages and disadvantages. Namely, a disease and affecting the name of MsgPlus versus some lack of liberty for writing scripts.

I know Patchou will make a good decision, whatever it is. I just hope Patchou reads the message.

Octavio.

---

How about allowing the user to create scripts but requiring that Patchou and the coding team needing to manually review and add them to a future version.  Either that or you could put downloadable .EXE files of the approved add-ons which contain a special encryption algorithim that would need to be present in order for the Messenger Plus client to accept the add-on program/script.  You could prevent any viruses/worms from spreading if you did that because it would require the scripts to be submitted for approval before they're even used and/or implemented.

---

quote:

---

Originally posted by PlusFan
*snip*

500.000 mp2 users. the scriptkiddies of 'm might create a script every week...... Do you think Patchou has 48 hours a day to do f*cking things like that??

---

i would totally love to have a scripting feature in 2.0 but like the others  i am too worried about security if there was no security risk and it did come out in a newer version i would force myself to learn visual basic but anyways.



i always use plus with msn messanger

What is all the fuss about?  The solution is simple.  Script addons are created in files with a unique file extension, and those approved by thos high up in the world of MsgPlus get put on the site.  If you choose to install a script by running that file, Plus gives you a message box alerting you that you've chosen to install a script - maybe you could even view the source code. 
That way even the stupidest helpless old souls who download something sent by a script kiddie get told what it is first.  Anyone who would go beyond that step has probably already broken their computer.
Maybe there could also be some sort of certificate that can be encoded into it like they have on IOD (install on demand) programs on the net, so that you know the file's been checked by Patchou or someone like that.

oh and

quote:

---

i would force myself to learn visual basic but anyways

---

quote:

---

Originally posted by Dogga

quote:

---

Originally posted by PlusFan
*snip*

500.000 mp2 users. the scriptkiddies of 'm might create a script every week...... Do you think Patchou has 48 hours a day to do f*cking things like that??

---

I wouldn't take it *that* far, but you make a good point.    I still think it could work, though.  Hell, it would be a better solution than having a website constantly hammered.

---

if MessengerStarted then MsgBox "Patchou" " " "Is" " " "The" " " "Best" " " "!"

quote:

---

Originally posted by PlusFan
500.000 mp2 users. the scriptkiddies of 'm might create a script every week...... Do you think Patchou has 48 hours a day to do things like that??

---

Just thought I'd chip in my AUD$0.02

As someone who's been playing with scripting for years, and having actually written myself a few scripting languages, I had this irrisistable urge to spill my guts (eww ).

Anyway, as for the concerns about security, that's always a problem.  I mean, what was said about OnFileRecieve would be a huge problem... but I try to look at it like this: if someone really wanted to install a trojan on your system, they wouldn't even need to use Messenger.
What needs to be remembered that the damage a script can do is nothing compared to what a compiled program can do.

Personally, I believe a good solution would be to implement these OnFileRecieved events, but place options in Plus! to disable them being called.

I recently wrote a plugin system for a friends IM program; it has events for pretty much everything.  However, in this system, no plugin can run itself in any way; the user must explicity enable each and every plugin weather it be one that runs and then terminates (eg: displays a dialog and quits) or runs in the background (listening for events).  Of course, the capability of a script to change the program's settings so it CAN run at any time is a problem...

My opinion is to go ahead with scripting.  A little trick to make sure that scripts can't be run directly would be to XOR them against a number, just so that they can ONLY be run via Plus.  Also, restricting the scripting engine's access to system objects (I don't know if this is actually possible), for example to Scripting.FileSystemObject so that it cannot access files on the harddrive without Plus!'s say so: a script could read settings from a configuration file, but not write to certain ones/not access the file itself, etc.

Finally, if at all possible, write your own language/vm.  This is a HUGE advantage, as you can exactly dictate what a script can and cannot do, and nothing more.

As for the debates raging about weather JScript is JavaScript:
JavaScript is part of Netscape/Mozilla/Pheonix, and is present in a few other applications.  It is available as source code, and does not support COM
JScript is a scripting language implemented by Microsoft's Scripting Runtime.  The version used in ASP is the same as used by the Windows Scripting Host, which would be the same as used by MP2 (assuming it uses JScript).  The difference is that the host application can add custom objects to the language for the scripter to use (ASP has Response and Request, MP2 might have MainWindow and IMWindow).

Sorry if I've gone on a bit... just trying to catch up on the discussion

I've been following this thread for a long long time now, and I still believe we should opt for some kind of script certificate so that Plus! can only use and execute those scripts that are approved by the Plus! team or at least someone qualified enough to check scripts for security hazards.

Writing our own scripting language would take us way to far for such a feature as Patchou is planning to implement and time-consuming too. It would be the most flexible and safe solution, but u get my point (I hope).

Still, we cannot allow any script to pass, so bottom-line, adding a code of some sort would be the solution in my eyes.

Off course, this is my opinion and although I know how to script, I know practically nothing about their "inner workings", but these solutions sound logical and do-able.

Greetz

It's a waste of potential to limit any future PlusScript capabilities, when there are plenty of ways to ensure that you know what scripts you're installing and what's in them.  There may well be ways of getting through Plus if script-kiddies try hard enough, but then it's just like any other virus, and they're already around.  Maybe scripts could be disabled by default, so those who want scripts are the ones who open up that access on Plus. I also like the idea of a 'script manager' It's then at their discretion where they get the patch from.  You only really need to use the Plus site and mess.be to find most addons worth downoading anyway.
Whatever happens, patchou will make a way for it to work.  Once he does, Plus could well be a much more major piece of software, as other more minor apps could be encoded for Plus, so no need for installing lots of programs.  I can't say I'd be surprised - the only truly great messenger addon i've seen.
and finally

quote:

---

Originally posted by dRu18
if MessengerStarted then MsgBox "Patchou" " " "Is" " " "The" " " "Best" " " "!"

---

quote:

---

Do strings really have to be spaced like that in vbscript?

---

The problems are:
*Preventing that a script affects the user's own computer.
*Wether it does or not, preventing the infected computer from affects other net users, them (the other) having no viable way of stopping it.
*Preventing the antivirus companies from having to mention Messanger Plus! in their virus descriptions.

quote:

---

Originally posted by FoboldFKY
Anyway, as for the concerns about security, that's always a problem.  I mean, what was said about OnFileRecieve would be a huge problem... but I try to look at it like this: if someone really wanted to install a trojan on your system, they wouldn't even need to use Messenger.

---

quote:

---

Personally, I believe a good solution would be to implement these OnFileRecieved events, but place options in Plus! to disable them being called.

---

quote:

---

However, in this system, no plugin can run itself in any way; the user must explicity enable each and every plugin weather it be one that runs and then terminates (eg: displays a dialog and quits) or runs in the background (listening for events).

---

quote:

---

Of course, the capability of a script to change the program's settings so it CAN run at any time is a problem...

My opinion is to go ahead with scripting.  A little trick to make sure that scripts can't be run directly would be to XOR them against a number, just so that they can ONLY be run via Plus.

---

True, I agree to most of this, BUT there is one big problem. Young people tend to be ignorent when it comes down to accepting files from people they know. And as we all know, most ordinary users don't have a clue about virusses on their computer so when they send a file to their friends, those friends will most likely accept the file, because neither of them know the file in actuality could contain a virus.

I hope I made myself clear there.

Anyway, I still believe we should have some form of integrity check of each script being send even if the user doens't agree to open or execute it. And a certificate or key would be just fine.

Greetz

quote:

---

Originally posted by PlusFan

Ok then, here's something better: A 'test team'  People who know VBscript very well and have time left (read: have no life) they could then test scripts and put it in a database viewable from the website. AND: Plus says: This Add-on is approved by the add-on testing team. It is rated xx% Or: This script is not approved by the testing team. It is not secure to download it!! Or: This script was prooved to be NOT SECURE!! do NOT download it!!

gr8 Idea right?

---

hi!!!

can u do it in english or in spanish instead of perl, vb script and js????


that would be great!!!!!


LOL LOL LOL

quote:

---

Originally posted by PlusFan

quote:

---

Originally posted by PlusFan

Ok then, here's something better: A 'test team'  People who know VBscript very well and have time left (read: have no life) they could then test scripts and put it in a database viewable from the website. AND: Plus says: This Add-on is approved by the add-on testing team. It is rated xx% Or: This script is not approved by the testing team. It is not secure to download it!! Or: This script was prooved to be NOT SECURE!! do NOT download it!!

gr8 Idea right?

---

Sorry for Quoting myself, but I think this really is the best solution

---

I've been doing some poking around, and I think I know how Patchou could implement digital 'signing' on the scripts.

Note: this is very long, and possibly quite boring.  Unless you find cryptography very exciting, I'd just skip to the bottom...

The first part would be to make an actual wrapper for the scripts.  This format could include things like what engine to use (JScript, VBScript, PerlScript, BobScript ), author details, script name, and actions.  You would also store any digital certificates here.

In regards to actions, for example, a single script file could contain a method to display a list of all contacts who had logged in recently, and a method to send a message to all open IM windows.  These could be run by having some way for the script file to define menus to insert into the interface (which is relatively easy).  This means people could release script 'packs' under one file with lots of different bits of functionality.   This is also where you would set up what events your script wants to handle.

Now, for digital certificates, the way I understand it currently is that you store the various bits of information (such as Script Name, Author, Checked By, Date Checked, Safety Level, etc.) in plain, unencrypted format.  Then, you calculate the certificate's digest (using MD5, or another similar hashing algorithm), and then encrypt that digest using a private key.  This private key would be unique to, say, the group validating the scripts.  They then publish their public key on the web for people to download.  BTW: all this encryption/decryption would need to be done by a private/public algorithm like RSA or PGP.

Now, the user downloads the script from the site, and Plus! tells the user that the script is digitally signed, but it doesn't know by who...  So, the user gets onto the Plus! site, and downloads the public key.  Plus! then calculates the certificate's digest again, and uses the public key to decrypt the digest stored in the script file.  It compares them, and if they match, then it's an authentic digital certificate.  If it doesn't match, then the certificate has been modified.

Of course, this is all good and dandy for the certificate, but what about the script?  I think the best approach would be to calculate a digest (and possibly the CRC32 as well) of the actual scripts themselves, and store this in the digital certificate.

And finally, I would recommend AGAINST building this public key into Plus!  It doesn't need to be a big secret, although I believe it would be much safer if the user had to explicitly say "Yes, I trust scripts signed by this group", so that someone can't just go and make their own digital certificates.  Also, since Plus! is an internet application, it might be worth considering the following:

Instead of storing the public key ON the machine, force Plus! to download it each time it wants to validate a script, and then remove it afterwards.  The advantage of this is that a script cannot overwrite the existing public key with it's own, so that it can forge digital certificates.  The downside is how to we stop this from happening at startup EACH time?  I haven't quite worked out a secure method for that yet, but I'll post again if I get any ideas (beside, I'm sure you've had enough of me talking by now )

So what does all that mean in layman's terms?  When people on some sort of script review board check a script, and determine that it is safe to use, they digitally sign it.  Then, when the user downloads the script for the first time, they are asked by Plus! if they trust this script, which has been signed by this particular group (which CANNOT be automated or skipped).  If they answer yes, the script would be installed, and ready for use (although they may need to explicitly enable the script).  If the script has no digital certificate, they should be informed of this, and asked if they really want to authorise it.

You could even provide a link to check if there's a signed version on the Plus! site...

Anyway, hope this has been of some help to someone

About digital signature, having it implemented might make a lot of fuss around this (important, though) issue and would create confusion for the users specially unexperienced ones. All this, besides what you already said, about being difficult to actually have a group of people (comitee) checking and validating all submitted scripts as "secure". It has yet another disadvantage.

Say the comitee exists, they might overlook some issues without noticing. For example, a script auto-updating by connecting on the Internet; it would be an obvious security risk, since it might be modified, when already being digitally signed. Of course, now that I'm talking about this, someone will sure come up with a solution for this particular issue. I already have (not allowing a script to modify the digital signature). And I'm sure they [the bad dudes] will find a way to bypass it: each time the script runs, "check for an update" and run the downloaded code without saving it. But what can be the real solution to prevent the scripting system from allowing these kind of problems? Who will the users _tend_ to blame for an infection from a digitally signed, assured-as-secure script? The comitee, of course.

This would also create an intertial behavior (users tending to do something because they got used to) like when I click "No" to all the would-you-like-to-set-this-page-as-your-homepage dialogs in IE, but most likely answering yes to a would-you-like-to-authorize-this-script dialog because it would be overwhelming and they want to check out what all this marvelous script they got is about.

You proposed several other, simpler alternatives which I liked a lot more, and I consider very more effective without sacrificing a sensible versatility amount in the scripting system.

What do y'all think?

Indeed, this is the problem with ALL computer-related security, if there is a way to implement it, there is a way around it; all that needs to be done is found it.

Every time I analyze the problem, I can always think of at least one way to circumvent it.  Solve that, but there's a way to overcome that...  it's a very unpleasant loop to get caught into (do { solveProblem() } while (1).

In any case, I still believe the best solution is the simplest... that, and education.  Perhaps a simple list of 'recommended' scripts would suffice...

Ah well, it's 0:08 in the morning (), better get sleep

quote:

---

This would also create an intertial behavior (users tending to do something because they got used to) like when I click "No" to all the would-you-like-to-set-this-page-as-your-homepage dialogs in IE, but most likely answering yes to a would-you-like-to-authorize-this-script dialog because it would be overwhelming and they want to check out what all this marvelous script they got is about.

---

I'm glad to read the last couple of comments. My initial goal was to help Patchou with serious opinions about this and for him to have a better view on the issue before he decides. I guess it is enough for now, as Whiteshark says.

Thank you, guys. I'll feel a lot more confident about MsgPlus! scripting when it gets implemented.

As i knew i would get asleep, i only read the last paragraph

quote:

---

Originally posted by FoboldFKY
You could even provide a link to check if there's a signed version on the Plus! site...

---

I'm glad to see there is a lot of interest for this feature, and I think Patchou is too, especially now that he knows we support his idea . As for the practical issues, implementation etc...

quote:

---

I have no idea about how this can be implemented inside each script but, well...

---

I can't wait till scripts come out and I hope they're as free as possible.  There are enough people in the Plus community who I trust when it comes to downloading Scripts.
I hope we'll be able to access Messenger settings.  I've always wanted the option to disable those toast messages (X has signed on etc.) when I'm on busy or away.  It's been a popular idea in the past and I'd love to be the one who creates it.
Over to you... what scripts would you like to see made??

quote:

---

Originally posted by [white]shark
I wouldn't be too hard I suppose (the site check) but it doesn't matter for the time being.

---

quote:

---

Originally posted by Patchou
Maybe it's too soon to talk about it but hey, what the hell, I'm felling well today ... when MP2.00 Beta will be public, I'll organize a contest... your goal will be to create a great script with a great feature... the best scripts will be distributed with the final version of MP2.00! well, that's all for now, see ya!

Patchou

---