World: r3wp

Banner ads are on web pages. You can make banner ads with Flash, 
and that is less dangerous than the current plugin.

files are a risk to privacy if they cant be blocked. that reuse-question 
does this. and they can be prepared to be run, eg called *.exe and 
hoping the user some day clicks on them. so i suggest a wrapper, 
maybe store everything as rebol[]#{stuff} or in a single zip or something.

i thought we talk about local storage. what has that to do with banner-addds?

wouldn't e.g. local storage limited to say 20 MB be sufficient "security"? 
Hmm, should read that Flash security doc first probably :-)

As I've mentioned here before, there many nasty things you can do 
with the present plugin and I don't want to make suggestions on a 
web-public group. Go private if you want some ideas - I trust you 
not to misuse them.

I read the Flash security doc, and it has many good ideas. I'm still 
a little iffy about it providing cookies to anonymous scripts without 
providing a management interface - that's why I still use FlashBlock.

how can cookie harm you?

I mean Flash cookies - browser cookies do have a management interface.

Cookies can be used to track your movements, and can be used as persistent 
distributed storage.

I trust you gurus for proper security concerns, however let's not 
forget us - the end users, where over complication does not work. 
Even Vista is being reduced in such regard - way too many obtrusive 
security requestors to users. In other words, - don't bother end 
user with questions he knows sh*t about their meaning anyway:-)

Imagine if Google used the plugin for their ads - they would be able 
to store their whole database distributed amongst the computers of 
everyone on the internet. Would a security requestor be able to explain 
that to a newbie?

no

The advantage to cryptographic signing isn't just being able to track 
down an author, it also allows certificate revocation. With a free 
registry, revocation wouldn't matter - the bad guys would just register 
again.

askiing user e.g. what you discussed here - "do you want your previous 
cache to be deleted?" would result to "What is cache?" in 99% and 
users would press "Yes" .... or "no" .... :-)

This is why it would be best to use the browser cache for "let me 
store some graphics so I won't have to download them every time" 
situations. Other user settings are small in comparison, and can 
easily be stored in browser cookies or server side. Then, no security 
requestors necessary.

then we need to investigate ways of how to better utilise do-browser 
...

are we able to get to such browser settings in some unified way, 
so the same script works in all browsers?

You could write *-thru functions that used the browser to do the 
reading, with its cache.

read-thru, load-thru, etc., just like View uses for its sandbox.

hmm, that needs to be part of our user code. Not sure Carl will want 
to have two different versions of mezzanines - View, and plug-in 
one ...

There are two dlls here you know, the plugin calls the View dll. 
The browser-specific stuff is in the different plugin dlls.

my understanding is that it is the C code, wrapper for the browser. 
It would have to call View dll with some packed-in rebol code then 
to "preconfigure/patch" some mezzanine code ...

Sure. Not hard at all - I expect it must do something similar to 
mak do-browser available.

You could probably implement port schemes for cookies:// and cache:// 
right now using mezzanine code wrapped around do-browser that would 
do the trick quite nicely. Then, all you would need to do is assign 
cache:// to view-root and the existing functions would work.

Which brings to mind a question: What JavaScript types get converted 
to REBOL types when returned by do-browser?

Doesn't url based security limit the ability to do clientside mashups 
from multiple services?

One of the attractions for having a smart client in the browser means 
I can distribute tasks to it, instead of the server. But I url based 
security is a dampener on that. It's the reason why flash has stumbled, 
as javascript based mashups flourish

That limiting is the idea. Allowing someone to  mashup with some 
code from your bank -accaount is not the best idea. As feature yes, 
but unknown and as default?

Brian, where is the difference between a browser-cache and a selfmade 
one?

And i was discussing plugin2, not the way the sandbox works now.

Allen, do you mean clientside mashups like these?:
- DDOS zombies
- Spam relays
- P2P relays
- Anonymous proxies

So, which of these do you want a webbug written in REBOL or Flash 
to be able to do?

p2p relay

Volker, the advantages to the browser cache are:
- There is already a management interface

- There are security restrictions as to what can be done with the 
content

- You can't count on data in the cache to stay there, it is a cache, 
not storage


We don't want persistent storage that can be used without permission, 
not without being able to track down the one using it. There are 
whole classes of data, the presence of which on your computer can 
get you arrested in the US and other countries, and you can't count 
on the assumption of innocence when the ones who find the data may 
not be technical enough to understand the difference. There are documented 
cases of people getting arrested for having someone else's child 
pornagraphy on their computers, and having their lives ruined as 
a result.

Graham, you want a p2p relay in a webbug?

Allen, Javascript has even more restrictions on its network abilities 
than Flash.

I think you guys ought to trust what BrianH is saying a little more. 
I throw all my support behind what Brian is saying here, and I also 
think there are a lot of things being repeated which have already 
been explained several times. I like the current direction the plugin 
seems to be heading.

Security is cool to have, just please keep in mind one thing - let 
it be Rebol, not anything else. So, if I am able to store my stuff 
with Rebol, I want to be with plug-in, or it is not rebol for me 
anymore. Then I expect *-thru functions at least, to use browser 
cache at least. That thing I may regard as decided, as Anton says, 
we should support Brian with secure way.

Other thing, however, is - how far we go? Thinking in that manner, 
we can easily end up with conclusion, that we should use ONLY browser 
networking capabilities - once again - that is not rebol for anymore. 
On one hand, we would like browsers SSL to be used (imo only because 
rebol itself is badly missing here), on other hand - who wants to 
give-up rebol networking? I can understand it eventually makes sense 
security wise, as who wants your plug-in to open tcp listen port 
on your machine? I see it imediatelly as similar problem to local 
file storage (although eventually catched by firewall)

although some storage for graphics-heavy things would be nice.

If you drop some flash you can have 10mb of storage without permission, 
and 100mb with.

I'm completely supporting Brian here too. REBOL is not popular enough 
to even remotely risking someone writing malware with it. All the 
anti-virus software in the world is just going to block REBOL if 
this happens.

yup....

I'm late to the conersation, but I'm backing Brian too.

The plugin arena is not the desktop arena, and extra special rules 
must apply.

agreed. after all, if they want more, they can download the real 
app. but can have a quick first view by plugin.

Wow, good discussion.

Regarding security: we are on the same page. We haven't finalized 
the final security plan (we're hoping to get a draft plan doc up 
soon)....but a key component of the overall plan is something we're 
calling "Trusted Scripts", which is an infrastructure for signing 
scripts to enable licensing, rsponsibility (who made this script), 
lower security settings (again, for signed scripts only), and /Pro 
features.

Default security model: Yes, this will be tight. Completely agreed 
here.

The cookie/cache idea is interesting. Need to think on that one a 
bit.

Here's a few components of Trusted Scripts (this is only a draft 
-- open for feedback):
	* Default security model is tight -- how tight is TBD.

 * Developers that want to take advantage of Trusted Scripts, i.e. 
 to lower security for a production app, first must buy a license.key 
 from RT.

 * license.key unlocks  "features" and "permissions". Features are 
 things like encryption within the script. Permissions include file 
 sandbox, domain restrictions, dll loading permissions, etc.

 * license.key will contain contact info, so we can track down the 
 author of a malicious signed script if necessary.

Sounds in line with sdk: features for money. and you get some identity-check 
by money, good too. But you need something for the user to know what 
he is going to use. with url that is simple: stuff on this page. 
with signing its quite obfuscated. Shall i allow everything which 
RT gives a thumb up? Or are certicitates hardwired to domains?

Volker, good point. We may also provide a certificate verification 
dialog, i.e. "Joe Shmo from company XYZ produced this verified REBOL 
script. Would you like to allow it to run?" or something to that 
effect....I'm not positive here....just tossing ideas out there.