World: r3wp

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.

why not a sandbox for anonymous, Brian? as long as its is the only 
place, lock down no read or write outside it. Widgets, flash, google 
earth etc all allow state & cache in sandbox

apple and konfabulator widgets would not be as numerous if signing 
was required for scripts

Henrik, if someone wants to run an anonymous browser script in /View 
they are welcome to try, but the browser integration won't be there 
so the script may not work.

something else entirely: should there be a more REBOLish way to access 
the browser DOM tree?

(I think it would be very cool to have a DOM tree browser written 
in REBOL)

Anonymous scripts should be able to read through the browser cache, 
at least for files from their own site, but should assume that those 
files won't necessarily persist beyond the browsing session. You 
don't want to give them a sandbox that doesn't have its space limited 
by the browser's existing facilities, for security and privacy reasons. 
You definitely don't want anonymous scripts to store more than cookies 
on your systems.


The guideline you should set for default behavior of anonymous scripts 
is to limit it to the activities that would be OK for deliberately 
malicious code to do. Assume that all anonymous code is out to get 
you until proven otherwise. This is a browser plugin you know - it 
will be used in banner ads.

Konfabulator widgets are more comparable to regular reblets running 
in View. Just because they are implemented in XML/CSS, doesn't mean 
they are held to the same behavioral standards as web pages.

Yes, a DOM tree browser would be very cool.

and "sell" it to the AJAX developer community :-)

I'm OK with a virtual sandbox that gets deleted on browser shutdown. 
We don't want REBOL to be used as a vehicle for persistent, hidden 
tracking data to be put on users' computers. I want a browser plugin, 
but I want one that even the paranoid would be OK with installing.

As long as the virtual sandbox can't be used to generate data files 
that can fill the hard drive (or even be written to it), it should 
be fine.

BTW, someone needs to consider the new plugin activation that Microsoft 
added to get around that BS patent, and what effect it will have 
on the IE browser plugin.

Hello Josh! I have one request. Try to run this:

under IE:
http://www.rebol.cz/~cyphre/plugin-ie.html

under Mozilla/FF etc.:
http://www.rebol.cz/~cyphre/plugin-moz.html


Drag the green box using mouse and try to move it quickly over the 
screen. You can see the time lag when the green box is updating the 
position.

Now try this from normal Rebol/View console:
do http://www.rebol.cz/~cyphre/plugin-moz-test.r


You can see there is no lag and the green box is updated very quickly.

Do yo have any idea what could cause this difference?

my specualtions: 

1. Are you always blitting the whole screen in the plugin versions? 
This could cause the slowdown as there should be updated only the 
part with green box on the screen.

2. Could be the slowdown cause by different(higher)  amount of mouse 
events which are pumped from browser to the plugin?