World: r3wp

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.

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.