World: r3wp

Let it prompt the user for files to work on, using the system file 
dialog even, and then allow the plugin to work on only the files 
that the user specifies. That should be a good balance.

We don't want a banner ad to be able to participate in a DDOS attack 
do we?

rebol services can be evil too, sending it your data, just like direct 
tcp usage.  it should be dialoged too.

Only when that service is running on a different server than the 
web server the script was served from. A user's data can be sent 
over the URL that requested the script, or an AJAX connection. A 
certain amount of network access is assumed.

That is the default security restriction of existing browser VMs.

ok, well... I've got to go, ciao brian, thanks for the chat.  :-)

Personally, I feel that the plugin will never gain general acceptance 
unless it is, to use Graham's phrase, "neutered" to the extent that 
it has no local files access and can make no system calls. It should 
be constrained within the browser's environment just like JavaScript 
and Java Applets.

The places a browser puts persistent data, and manages that data, 
are cookies and the temporary file cache. There are already security 
restrictions and management tools for those places. That existing 
persistent storage should be sufficient for REBOL scripts loaded 
by the regular plugin. Any other storage should be on the server, 
with the same server access restrictions as JavaScript. Anything 
more should be restricted to trusted sites.

If you need to access other servers, put a proxy on the one you are 
allowed to access.

In some instances you want to use the browser as a delivery mechanism 
for an application.

there should be an optional way to allow library acces, local file 
access etc .

say I have a farm of  pcs running some seti like application and 
rebol using the browser plugin with lns to send the results back 
to a server.

You can do a lot in those restrictions - look at Google. Beyond that, 
that's what the SDK would be for - not because of the source obscuring 
as much as so that the developer of scripts that can access your 
system could be tracked through your license.

I can't ...

You can't afford the SDK?

I have the sdk/command.

I want to use the browser to deliver full applications.

Say I have thin clients only?

ie. browser based clients.

with only a little flash ram for storage.

If the browser plugin is doing the distributed computing work, the 
result sets could be sent to the server under the restrictions I 
propose.

but if another library were doing the work?

What we may need is a way to partially encap scripts:

- Encrypt them using the SDK licensee's key in a way that can be 
decrypted by the plugin and traced to the licensee.

- Decrypt them with RT's plugin rather than bundling them with native 
code.

- Prompt when loading them the first time, perhaps with company info 
like IE does with ActiveX controls.
- Give encapped scripts a sandbox directory like rebsite scripts.

- Let these scripts do what they must, knowing that if they are malicious 
you know who to sue.

Anonymous scripts shouldn't be able to do any more to your system 
than JavaScript in the browser can.

Browser plugin updates could do the equivalent of certificate revocation 
for malicious licensees too.

I agree with Brian here. Opening doors should be done carefully.

I'm just worried about the "evil" network access that Rebol can do 
in the background, which you can't see in the browser, but need sniffers 
to see. A method for showing network access needs to be really solid.

Henrik ..every application that you install has potentially the ability 
to do network access.

I have no idea what my anti-virus products do.

but they constantly access the net, presumably looking for updates.

I don't think Rebol should be thought of any worse than a program 
written in C.

how do java applets do it?

No idea.

Basically, Java Applets and JavaScript have no access to local files.

Java Applets can be digitally signed and you can grant "trusted applets" 
local access.


I'm not sure how much this is used and whether people really grant 
trusted access.

it's used here a lot for online banking to fetch a locally stored 
key on disk

So Henrik, do you trust your bank to have access to your local files?

most banks here use java for logging onto the bank

I guess I do. It's cheaper than having to drive 7 km to pay some 
bills. :-)

there is another issue which is to the advantage of the applet: if 
it was not known as trustworthy, no one would use it.

peter, there is in fact one bank which issues color coded papercards 
instead of codes. it's also the only bank which is almost completely 
cross platform, since they don't use java.

That's true.

if there is a breach in bank security it's all over the news immediately

but.. we're not all banks

Personally, I'd be very cautious to allow any third-party to have 
"trusted access" to my machine.


I'm the sort of person who turns off any type of automated updating.

the problem is that turning such things off, automatically makes 
educating users on how to use a specific service, much more expensive

a paradox is also that many of these services only work in IE, a 
notoriously insecure browser :-)

I put a few of the usual suspects up.. 
http://www.rebolforces.com/plugin/rotate.htm
http://www.rebolforces.com/plugin/reblox.htm
http://www.rebolforces.com/plugin/psquares.htm

Java applets and JavaScript scripts are usually only allowed to access 
their own server over the network. I think you can make that same 
restriction to REBOL using the secure native.

I note that if I browse from one page to the next  (using links at 
bottom of each page) , the subsequent pages won't load ..