World: r3wp

We don't want the default plugin to be able to put even a single 
byte outside of the browser's purview without prompting the user 
first. Users have enough security problems to deal with without wondering 
if their banner ads are putting files on their hard drive. As it 
is I know many users who use AdBlock as a security measure - they 
don't care whether they see ads, but many of those ads contain nasty 
code and spyware installers.

OTOH, you don't want to neuter the plugin so that it's useless

No offence to you Graham - you are (apparently) one of the good guys. 
But what you are describing is exactly the kind of behavior that 
we should restrict to encapped scripts that should require an additional 
installation notice, maybe even seperate plugins. Either that or 
through the encapping process  have RT act like a certificate authority, 
allowing us to take an encrypted script and have RT tell us who licensed 
theparticular SDK that encrypted it.  That way we can have the authorities 
(or lawyers) track down an evil developer.

Let's see what a "neutered" plugin can do:
- REBOL/Services
- All of REBOL's GUI and graphics stuff.
- Access browser data (that is site-specific)
You can do a lot with that. Look at Flash.

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