AltME groups: search

Pekr: Backwards-compatibility w/REBOL, AFAIK, is only broken with 
the first digit changing (i.e. 1.x to 3.x). We'll follow that process 
with the plugin -- automatic updates from 1.2 to 1.3, 1.3 to 1.4, 
etc., but a new manual download for 3.0 (including new HTML, side-by-side 
listing in "Downloaded Program Files", etc.)

I'd think there would be some demand for a mac version. switching 
to mac everywhere here :-)

Note: After some research, Pekr and I discovered that you can place 
a user.r file in the "sandbox" directory (system/options/home) with 
your proxy settings to get around the limitations of set-net-info.

That may be a temporary solution for those of you stuck behind a 
firewall.

Thanks a JoshM for the solution. Although that is not final solution 
(plug-in demos will not work for those who directly click the link 
on website), with some user assistence, doc update, we could get 
it at least working, which is really cool!

As a suggestion for dealing with proxy issues, why not have the plugin 
dll read the browser's proxy settings and then call the View dll 
with some REBOL code that would set its proxy settings accordingly?

I mean, once the security infrastructure is set up properly in a 
future version of the plugin, anonymous scripts shouldn't get a persistent 
sandbox at all, so there would be no place to put a user.r.

Josh's aforementioned secure source code was something I suggested. 
The other part of the suggestion was that every secure script would 
be cryptographically signed by an SDK license key, or some other 
way for RT to trace the author of the script. Only those signed scripts 
would be allowed to store persistent data in a sandbox without the 
attempt to do so prompting the user with a security requestor.

my question was a bit different, though. Let's imagine your proposed 
secure way, so I can use it for some app, to sync some data to user. 
The problem for me is the sandbox placement - in system Temp dir, 
which can be purged via control panel. I am not sure I like it, if 
there is possibility I could loose my synced data. Or am I missing 
something?

Your last reaction to when I brought this up:

OK - one thing is clear now - "What would you let your worst enemy 
do with your computer?" should be a saying for Rebol plug-in .... 
now just how to represent it ...

My suggestion was just for anonymous scripts. Signed scripts could 
get a sandbox, probably somewhere under %appdata%.

I just had to look for the last point in the history where I posted. 
Security seems to be a recurring theme in my posts. :)

btw - what do you mean by "should not get a persistent sandbox at 
all" - do you mean it should not be allowed to write to temp at ll, 
just use memory? Or just by anonymous you mean randomly generated 
"anonymous" directory somewhere in Temp directory?

Isnt' this a bit over the top?  What about cookies ?

No, just use memory. No cookies except browser cookies - there should 
be a way to access them, similar to how do-browser lets you access 
JavaScript. Perhaps a wrapper function around do-browser could work 
for now.

I don't want there to be any need for people to make a REBOL-blocker 
like FlashBlock or NoScript.

There should also be a way to provide access to the browser's objects. 
The browser already caches those, and that cache is managed by code 
that the user is already trusting.

signing needs keys. then we need a free registry if we want all the 
newcomers to have fun.

Actually, there is a lot that you can do even within those restrictions. 
Just look at Flash.

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.

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.

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

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?

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.

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

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

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

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?

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?

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.

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

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.

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.

do they have time and resources to sift through thousands of expertly 
crafted scripts per day? (just being positive about a future scenario 
:-))

We would not be verifying the script itself, we would be verifying 
the publisher. If the publisher signs a malicous script, we have 
detailed contact info to track him down.

Actually, pg-2 is not working in IE either. However, it seems to 
go farther; I see a box where the app should  appear but no app.

We are pleased to announce a new release of REBOL/Plugin. This release 
includes several new features, including:

 * Multiple instance support -- you can now have up to 5 instances 
 within one IE process.

 * Automatic updating -- after this release, backwards-compatible 
 updates will come automatically with user consent (no uninstall required).
	* Smooth install for FireFox and Mozilla.org-based browsers

 *Now compatible with Opera and all Mozilla browsers compatible with 
 npruntime. 
	*do-browser now functions in Mozilla.

Well, so far IE is a no go here. I closed all IE and deleted the 
files. At this point it just goes to the install page and I see the 
"blank" box.

Click here to find out why
 links to a page which says that only IE is supported

Is there a method for IE to allow sftware installs like that of FF?

Is the plugin served from an HTTPS site? It would be nice to avoid 
man-in-the-middle attacks. I'm always a little wary of putting non-SSL 
sites on the trusted sites list.


For that matter, when you have one site serving the html and script, 
and another serving the plugin, which site needs to be trusted, as 
far as the major browsers are concerned? I would think just the plugin 
serving site, but I don't quite remember right now...

Brian. Mashups (as I'm referring to) is the common term for webapps 
that utilise numerous webservices and combined in the browsers. But 
I hope you can come up with a security method that allows us to utilise 
advertising, google adwords-api, flickr, amazon-api, numerous maps, 
calendars. etc ; without having to combine on a single server before 
it goes out to the clients rebol plugin. I can do all this now in 
a browser, but I won't be able to with a rebol-plugin?

How would you check for a mashup?

Instead of somebody making your machine a proxy?

security vs useful ... I know it's a tough call. Just pointing out 
how some of the multi-services from different domains is so common 
now. (just disable 3rd party cookies in your browser to see how many 
warning message you get)

Btw does that mean a page from the web can access my local test-webserver?

there is a lot of usefull without mashup.

simple question. Will a plugin be allowed to read data [get, post, 
or soap] from a website other than the one that the script came from?

read-via-browser might be a better method, seemless do the javascript 
http object without having to expose the javascript required to the 
rebol user, but will it will then pickup the browser security settings 
on such things

Maybe a good compromise. Full speed rebol-network restricted or signed, 
and more relaxed thru javascript, where the user knows allready how 
to deal withit (more or less)

Where ? The Mozzilla section just talks about downloading a zip file 
and & copying to the plugins folder ....

Maybe a cache-problem?

A similar thing happend to me on my Win2k Pro laptop for work, I 
initially installed the plugin in FF, then tried IE.  FF worked like 
a charm, however IE presented the same scenario as listed above for 
FF, dowload words, image is displayed, even saw the test page, but 
a very simple Rebol app worked in FF, but not in IE.

It would be better to have a more obvious test/image to show that 
the installation works than some text with a shifting coloured background

except of "wait time", that waits a few secs instead of fractions.

FF 1.5 WinXP install worked. I already tried yesterday, but it didn't 
work then. 

But the only demo that's working for me ist the one on the auto-install 
page.
Everywhere else I only get a black line.

Had a massive memory-leak somewhere in the browser, while running 
heavy graphics plugin and reloading often. Seems they got stuck on 
quit or something? (as i said, reloaded, called also quita few times)

Looks like the plugin now requires an absolute path to the launchurl 
.. if given a relative url, it attempts to execute off the local 
drive

Yeah Graham, I'm waiting for the same.  I think JoshM just needs 
to have a status report on IE, FF, SA OP.  Actually we need to do 
the same thing for Qtask (so I''m not ragging, just pointing out 
we ALL need to do a better job of keeping everyone updated).

hmm, mozilla plug-in installed (Seamonkey 1.0.1), but instead of 
demos, I can see only a vertical black line ...

Here's a few general notes:

 * You absolutely MUST uninstall the previous release completely (by 
 closing down your browser, maybe restarting, etc.) before attempting 
 to install the new release. Otherwise, you're asking for major trouble.
	* You must change LaunchURL in *both* the EMBED and OBJECT tags.

 * Old demos don't work with the new plugin, and practically no existing 
 site will work with FF. This is because FF requires the EMBED tag.

Continued:

 * Please don't announce this release to the world yet.. As you can 
 tell, we've still got a long ways to go before we are really solid.

 * I'm going to try to go through each of you're trouble cases, just 
 tell me if I miss you....

james_nak: To install manually on FF, download the Opera zip package 
and extract everything to %ProgramFiles%\Mozilla FireFox\plugins. 
You must extract it to the actual plugins dir, not a subdir.

Josh - not sure if it is too early or not, but maybe we should start 
to coordinate a bit - I mean - docs, user demos - remove not functioning. 
We need to be ready, that once we release, we have nice, and mainly 
ONLY functioning demos there. Then someone could write multiple instances 
bouncing ball, probably Cyphre :-)

Volker: do-browser simply executes a line of javascript within the 
context of the HTML page. Whatever security settings apply to javascript 
running within <script> tags in the page apply to do-browser code.

Allen: read-via-browser is a thought, but limits the "magic" of REBOL, 
no? I'm open to thoughts here....the signed scripts only idea is 
interesting to me....

can java-script open the socket? because rebol can by simply open 
tcp://1234 .... will be catched by firewall, if present - but would 
that be regarded a security problem? How far do we go with limiting 
rebol? It would be good to slowly get to rebol's security bigger 
picture, to prevent the final solution being inconsistent ....

Volker: That "wait time" may be due to the new auto-update feature, 
which checks for a new update at RT's servers every day. Do you notice 
a speed improvement on subsequent uses of the plugin within the same 
day?

Volker: Uninstall is easier with IE (although I have noticed a few 
bugs with that), but FF/Mozilla simply doesn't support uninstallation. 
Thay say that plainly on their plugin info web pages.

'wait: its 'wait, the rebol-function, not witing on launch. I have 
a loop
  forever [ wait 0.05 sim-step ]

that works with rebol-exe, but with plugin the wait takes a few seconds 
instead. but its a more complicated script, have not tested this 
 simple example.

uninstall - could there be something to disable plugin? I dont like 
to install it and  have the beta there for thenext few years. although 
thats not your problem, would like to show plugin to non-techs a 
bit evenin its current state. would like to say  "dont worry later, 
just disable" .

about memory-leak, i try  to reproduce that. if  it works, i send 
you an url which downloads a lot :)

Volker: If you uninstall via DPF, that should disable it (although, 
like I said, I have noticed a few bugs lately).

Pekr: We will be releasing a document soon for a feature called "Trusted 
Scripts" that will lock down security and enable licensing and safe 
loosening of the security settings.

Pekr: Yes, TS will include a major lockdown of default security settings, 
b/c we will have a way to loosen them.

Pekr: TS will not include a change to REBOL's security scheme itself....as 
I have said a few times, changes to REBOL itself are out-of-sync 
with the plugin.

and that was my point - that is a pity ... as folks here had good 
ideas in that regards iirc ...

Pekr: We will make a few, minor changes to REBOL to support changing 
security settings with a valid license key, but that's it. We operate 
on a philosophy of "destablize REBOL as little as possible".

BTW, Pekr -- if you or anyone else wants to re-write get-net-info, 
it is a REBOL function and you already haev the source. Feel free 
to code away :). If not, we'll put this on the task list, but no 
promises on when it will get done :)

Graham: Regarding launch URL -- the problem is that we currently 
don't have support for relative or root relative paths in FF. This 
is a bug that we should have fixed for the next release.

Well, that makes the whole plugin a moot point for anything less 
than a vertical market.. which might as well download and install 
an encapped script.

the thing is that it probably takes a bit more man power to support 
more platforms and browsers, won't it?

Having to set the proxy on the control panel may not be enough. There 
are lots of people out there, who don't know what a proxy is.

In my world a browser plugin that only works on windows is worthless. 
And this is the REBOL plugin. Think about that bold statement about 
those 40+ systems REBOL works on. But the plugin is windows only 
???

... and in a company, do you want the admin to walk to all boxes 
just to set up Rebol/plugin?

Maybe a bit of both .. I don't know :-)

I think it's about RT claiming support for many platforms where it 
would only turn out to be a half truth. Windows is already by far 
the best supported REBOL platform. A windows only plugin only skews 
the support even more.

To me Ingo makes sense. HE is around the first time, makes browser 
working, a while later she downloads this pluginin without him aorund. 
says things like control-panel.

Josh M:  my problems may be with the interface between the chair 
and the keyboard... I tried using the existing demo pages not even 
considering the new tags required for the html pages.  I will double 
check everything when I get a chance.  Sorry for possibly causing 
extra work on your part to trouble shoot.

I'm going out of town for a few days, but I will go through your 
feedback when I return....in the meantime, please private msg me 
if I have ignored your question or problem with the latest plugin 
release.

Nothing to be sorry about...it is all about getting feedback, everyone 
here that reports a bug to the rest of u saves us time, and makes 
the product better.

Anyone else having issues with the pg-2 in Win 2000? All I ever get 
is a black bar that looks like a thick cursor ("I" Bar).

In FF, that is. And a blank box (outline of layout container) in 
IE.

Question: If the plugin is running, is it than possible to establish 
from there something like a BEER session without having the firewall 
/proxy problems? IIRC the proxies grant direct TCP/IP access after 
a browser once passed.

FYI: I have been reassigned to work on upcoming Win32 features for 
REBOL 3.0. Your feature requests, bug reports, and general feedback 
is still very important to us, but we won't be releasing a new version 
of the plugin for a while.