World: r3wp

Probably the correct result.

So, when to see some of the demo contest as pages?

is there a new way to embed the plugin? http://www.rebol.net/plugin/demos/index.html
doesn't work

http://www.rebol.net/plugin/moz-1/cyphre-demo.html

does my chat client work under firefox now?

No time to test myself.

till later on today

graham, it seems you need to use a different method to embed under 
mozilla than under IE

doesn't work on firefox here

Oh :(

Cyphre demo, I just get a white screen. Test.html worked though

hit back button and forward and then  cyprhes worked. guess it was 
still downloading something.

Sound working too. :-)

Like graham, I need SSL as well, can't use many of the mash up sources, 
or do any google adwords api tools without SSL

Same here.  Qtask will require it.

The new plugin works fine with Opera too (v. 9 beta) ;-)

Now I recall one my old rant... would be very nice if  there's a 
way to call rebol func from javascript.  Something like: 

<input type="button" value="Send" onclick="rebPlugin.evaluate('send');"> 

So we can build an html interface and use plugin & rebol instead 
of  XMLHttpRequest and Javascript

this plugin is a great news, btw. Thanks :-)

Bugs found in Firefox with Cyphre demo: 

- starts with no sound (the music started when I opened a parallel 
session with Opera, in Opera the sound is ok)

- seems there are some problems with AGG: no rotating Carl Head, 
some flash with gears, no "rebol rulez" in the sky... (Opera is ok)

- when I close firefox the music continue for 4/5 seconds (until 
the buffer is empty ?). In Opera too.

- sometimes the plugin disappear if I refresh the page. I have to 
close the browser. In Opera too.


WIn2000, nVidia GeForce4 MX 440, Firefox 1.5.0.3, Opera 9.0 beta 
build 8393

test.html worked for me without restarting Firefox 1.5.0.2

(I did first look at about:plugins before loading test.html, though.)

cyphre-demo also works for me without restarting.

good work

Is this group more for bug fixes to the new plugin, or is it a place 
to make suggestions and discuss security issues?

all of this.

security exploits .. private message josh.

Security Issues:

- We should to be able to restrict with the secure native what files 
and dlls the plugin can access.

- The default security of the RT-provided plugin (not encapped by 
a third-party) should prohibit any access to any local files or libraries 
at all, even in the same directory as the script, and prohibit access 
to third-party network addresses as well. Or at least ask.

- There should be some way to access the site's cookies from the 
plugin, because there shouldn't be any other way to store local data 
on the client computer's hard drive. Anything short of that will 
be a security hole.

- There should be no way to reduce the default security of the plugin 
through the use of plugin params.

- Any attempt to reduce access should prompt the user for permission, 
in terms a non-technical user can understand. This means rewriting 
the security dialogs to be more user-friendly.

- Any relaxation of these default security restrictions should require 
encapping the script.

- A user (or their lawyer) should to be able to (perhaps through 
RT) track down the author of any encapped script.

- An encapped script should count as a seperate plugin as far as 
the user is concerned, at least as far as permission-to-install is 
concerned.


Basically, the default security of the plugin should not allow scripts 
to do anything you wouldn't want your worst enemy to do on your computer. 
People will try to use this plugin for advertisements, for webbugs, 
for spyware, for every nasty thing that you aren't evil enough to 
think of. Avoiding that kind of thing should be the focus of the 
default security settings. Anything less will make the plugin unsafe 
to install.

Might I add that a requestor should appear for EACH port access needed 
and the remote url MUST be clearly identified, each time.

Yes, and design the security dialog so that longer URLs are able 
to be fully shown,either by wrapping or scrolling.

we should also be allowed, as a user, to filter out ip adresses and 
urls which we never want to accept.

the same for local disk access.  for example, we might restrict any 
file i/o to ONE sandbox.  anything trying to access or write out 
of user-specified paths, would either get a dialog, or be refused.

Some extended plugin configuration API that can be accessed through 
browser extensions?

Hmm.  I want to access libraries, and run scripts ( batch files ) 
which I create dynamically

or maybe from within the browser, window like quicktime does it, 
with a right click within the plugin box.

No, the sandbox won't work for the default browser plugin. Think 
of what a malicious script could do with a sandbox - it could write 
data files that could fill your hard drive, keep tracking data that 
the user wouldn't know to delete, etc.

graham, this is why, I think this should be configurable, you could 
allow the plugin to only load and save from specific dirs.

hum, disk space is a concern.  maybe the plugin could simply enforce 
the use of one single write space and protect individual sessions 
from accessing other sessions.

this could easily be handled like a cache and user could impose size 
limits on individual and collective size of all sessions.

maybe using the checksum of a script as the base dir, which is hard-coded 
as the root path of your script.

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.