World: r3wp

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 ..

allen, yeah, it's a known bug :-)

brian, the only method to access something locally would be through 
cookies?

Without prompting the user, cookies and JavaScript. Perhaps REBOL 
could prompt for any additional files it needed to access using a 
standard file open dialog (by standard I mean native).

Anything more would require a cryptographically signed script, traceable 
to your SDK license key, and thus to you.

I think that anonymous scripts shouldn't even get a sandbox directory.

and so, what about attempts to run it outside the browser? I'm thinking 
licensed scripts that someone figured out to download separately 
and tries to run it directly in REBOL/View. I'm not sure how much 
of an issue this is, but it's a first step towards reverse engineering.

Anonymous script source should be just as visible as JavaScript source. 
SDK scripts can be encrypted, but traceable. Safety.