AltME groups: search

Should we inform the user is a new update is avalaible?

I think this should be configurable for compatible updates. I guess 
some people might become nervous, if the plugin connects to the rebol.com 
site on every invocation. Even it is only looking for updates, well, 
you'll never know ...

On incompatible updates: The user should get a message along the 
lines: "You have installed the Rebol 1.3.4 plugin, this website needs 
the 3.0 plugin" of course only, if that is true.

I would ask for "download and install" for user convenience. Ver< 
few people would want to download and check the binary before installing 
it. Maybe you _could_ add a checkbox to "only download".

Well, I hate popups, but I hate not getting inmportant info even 
more ... so, I start downloadinf a webpage, while this page is loading, 
I open another tab, and work on this. Now I return to my first page 
later, and I find an embedded message "We're sorry, you first need 
to download the new plugin version" would make me go crazy :-) So 
I would like a popup in this case. 

Well, when there is a new security update, for maximum security, 
the plugin should stop to work until the user has answered, wether 
he wants to update, or go with the old plugin.

this must be a setting, even if it should be in the user's interest 
for it to be automatic.  simply because it raises trust.

Or, is this a chicken and egg situation?

So can we store a flag somewhere in the system? 
	automatic-security-updates = true / false;

I agree with Maxim as well, there needs to be UI somewhere to stop 
automatic downloads.


With that said, is it possible to clean this whole thing up and reduce 
it to one place where you either have what you need or you don't.


Using Adobe Acrobat as an example, they have one plug-in interface.

When you download stuff, it asks you if you want any of the other 
modules Adobe has for you.  In fact a close friend of mine created 
one of those modules (Atmosphere), which is funny that Adobe's interface 
even asks if you want this, since almost no one know what Atmosphere 
is.


So a single consistent dialogue should pop up with something like 
this:

You have:

Rebol command 1.3 for OSX
Rebol view 3.0 for OSX

New modules that are available:    

[_] Rebol view 3.0 for OSX
[_] VID2 interface Alpha for OSX


[X] Always ask before downloading

[Skip] [Download all now]

1) UI - we are not Flash player, we will likely produce real-life 
apps. So - do we give up right mouse click for configuration options? 
What if you will have your own one in your app? OTOH imo there NEEDS 
to be some UI for setting some parameters! Not everything which comes 
to my mind can be hidden from user. The ones which come to my mind 
- do you want to check for updates? Once a month, week, daily, Automatic 
downloade newer version? Ask, download. Use newest version if app 
does not specify its requirement? (maybe not needed, just an example 
of what could be configurable). Proxy settings .... List available 
version, provide uninstall button, etc.

to add to UI topic - should we add default border to the area plug-in 
is supposed to be? Should we add kind of app-bar, where configuration 
could be accessed? (could cause problems with app-area calculation). 
Or maybe to make it sliding, e.g. when you stay for more than few 
secs with a mouse over the top 5% of the plug-in app area? (could 
become annoying) - just throwing ideas around ...

Pekr - "1) UI - we are not Flash player, we will likely produce real-life 
apps. So - do we give up right mouse click for configuration options?"


I have no idea what you just said here.  Flash is used to make billions 
of dollars worth of complete stand alone product, as well as complete 
websites and small stand alone application that are delivered over 
the web.  


And they can completely control the right mouse button's access to 
a menu.


So, actually, we are JUST like a flash player.  In fact "flash player" 
is a misnomer, since it moved way past "playing" and into complete 
UI years ago.  Rebol and Flash really could not be any more similar.

pekr, I sort of agree with you, but it's impossible to ignore how 
widespread flash is, not for apps, but for animations, stylish pages 
and now video with youtube and video.google.com. I actually think 
the easiest way to watch video is through flash.


The point is though not really what flash does, it's how it gets 
spread. I think REBOL/Plugin should emulate that behavior as close 
as humanly possible. people who have installed flash, would know 
how to install REBOL/plugin (visit a specific site, wait for download, 
click 1-2 buttons, done). That initial "installation experience" 
is incredibly important for the widespread use of REBOL/plugin. If 
people can't use it within the first 1-2 minutes, they'll forget 
about it and move on.

a problem I've noticed about flash is that performance is very uneven 
under different OS'es. Macromedia...oops Adobe :-) might not prioritize 
the OSX version as highly as the Windows version. Flash for OSX is 
absurdly slow compared to other graphics engines for OSX. It alienates 
the OSX users because of those issues. REBOL/plugin may not necessarily 
suffer such crossplatform issues.

would we allow to invoke any configuration at all? what's to configure? 
SMTP settings? Possibly sound. this makes me think of another thing: 
would we want to be able to send mail through the plugin? it would 
be very easy to create a spam bot this way.

Henrik, with my suggested default network restrictions, that kind 
of security problem just won't happen without bringing up a security 
requestor that the user must agree to first.

Q: go, find whatever website flash plug-in part of website, press 
right mouse - you will see menu for controlling flash script itself 
... that is what I am talking about -

A: That is a choice of the developers.  The fact that people leave 
it as "default"


Q: Reichart - and you imo overestimate Flash's importance - they 
can be milti-whatever company, yet I would have to see some noticed 
real-life app someone uses in corporate sphere :-)


A: "I" over estimate Flash?  Uh, er….you mean like how Yahoo over 
estimated Flickr (front end is Flash), and bought them?  


Or, while you might not like it, if you are looking at an animated 
ad on the web, there is a good chance it is Flash.  That would be 
a 500 billion dollar industry that is using Flash as their delivery 
mechanism.  That is the app, animated content with games and click 
through.


And if you use T-Mobile, then you are using Flash.  Yup, it "is" 
the interface for their cellphone content provider.



Pekr, I'm not a fan of Flash, or Macromedia…I'm simply stating that 
Rebol should consider Flash's model as a pathway to a clean install 
and plug-in interface.

A smart plan is simply take the plug-in that is the most pervasive 
(I'm voting Flash for this) and copy their interface.  That simple.

I have seen a dozen applications used by companies.  The Neilsen 
Media company (famous for their Neilson Report of TV) uses Flash 
for all their applications.  


They could have used Rebol, but Flash is actually better for what 
they are doing.  If Rebol had more front end, or could play back 
SWF files thorugh AGG, then we might have something.


Rebol on the other hand is better for the heavy lifting, parsing 
websites, etc.

So, let's write up an overview of what is needed "exactly" to have 
a clean interface for a plug-in.  this needs to be done for 4 browsers 
(IMO): IE, FF, Safari, Opera (in that order).

See…this is where we need a wiki…like a Qwiki.

how about a simple flag, like a checkforupdates="true" attribute 
or something.  Every other operation, including the sort of actions 
that are necessary to install update is handled through normal security 
requestors.  ... yeah, like Brian said :)

Reichart - it is exactly as Henrik said - I just meant "real life 
apps", while you mentioned mostly media stuff, which is imo not Rebol's 
target and imo never will be, unless we would get some rebol authoring 
IDE, which I don't see coming in a year or two ahead ....

so all the point was that Flash does not necessarily mean Rebol is 
in the same league. But it was my non-knowledge - I did not know 
they can change menu, thanks for enlightenment, I thought the menu 
is the same because it (the plug-in)  is only a player .... I would 
vote for context menu, but in rebol, what is menu, right? We don't 
use native OS widgets, so just how to do it ....

Just a quick interjection, but I agree on the installation/interface 
being exactly the same as Flash.   The flash installation is mindless 
(see http://kealist.blogspot.com/) and the plugin should be identical 
to this.   I would have done the same for FF, but I can't get it 
to uninstall.

I think the inner border idea is a good one Oldes. That will give 
a standard look to rebol plugin instances. I imagine the border can 
have some controls to hide itself, go full-screen etc.

Cyphre, I'm taking a look at that mouse event bug now....should get 
an update to you soon.

Re. Mozilla page refresh bug: This is a mysterious one. I'm going 
to have to dig down into the REBOL C code to figure out what is going 
on here. I'll get an update to you all soon on that as well.

I'm not sure that such information is possible through the DOM (which 
is where it would come from). wouldn't that be a security hole?

Versioning: I dont see the problem, but i may understand com wrong. 
AFAIK a single file can implement multiple interfaces. So you dont 
have multiple files when the new version implements the interfaces 
for the old rebols.

Volker, to clarify, the problem is not with COM versioning, but rather: 
when to download a new REBOL DLL binary

regarding proxy settings: please post that on the 1.3.3 checklist 
if you want me to take a look at that. if you could provide a sample 
configuration script for testing, that would be great

if anyone knows of such a feature in the Mozilla API, please let 
me know

From an architecture perspective, an application should be able to 
handle as many events as the OS throws at it. Especially for graphics-intensive 
applications: those extra mouse events make a huge difference.

Pekr, regarding proxy settings: is there a problem with proxy settings 
via the registry?

Pekr: actually, I'm sure there is, that's why you are asking. Can 
you explain the problem in a little more detail? You need that auto-config 
script interpreted? Maybe it would be easier to configure REBOL to 
rad the auto-configure script than to try to get IE to parse it and 
get the details via an API. Thoughts?

Question: Did someone say there was a wrapper for Mozilla plugins 
to run on IE? If so, can you post the URL please?

(I found a wrapper for ActiveX controls to run on Mozilla, but not 
the other way around)

JoshM - yes, I need the script to be interpreted by browser imo .... 
I will post you a source-code privately, as there are live IPs and 
I am lazy to change :-)

JoshM: please go to plugin-1 group, scroll up a bit to find my bold 
messages, and read on a bit, there are some findings. To post some 
notes - probably the most significant link is - 

http://www.mozilla.org/projects/plugins/


The plugin extension adobe, mozilla, apple, opera, macromedia and 
sun agreed upon is npruntime

How to host NS plug-ins in IE:

http://www.mozilla.org/projects/plugins/plugin-host-control.html

Networking: as far as the browser can do the same, i would use browsers 
io. Or is it that much slower than rebols handler? Advantages are: 
proxy, cache. Maybe there are some extensions people like, about 
adds or blacklist or whatever? if such things exists they would be 
shared too. Its security , and a computer which knows my "no"s looks 
smarter.

Proxy settings: I think the simplest thing to do here is to modify 
whatever REBOL code is detecting the proxy settings to import the 
automatic proxy configuration script. REBOL is far more suited to 
parsing text files and interpreting information than C code. As a 
side note, we're not importing any settings via the plugin itself, 
we're just letting REBOL do whatever it does normally.

Mozilla: I think the problem with hosting the Mozilla control in 
IE with a wrapper is two-fold:

 (1) one more wrapper layer slows things down (a problem for high-performance 
 apps, e.g. graphics-intensive)

 (2) according to that page, there's no scripting support. that's 
 a major bummer because we need at least do-browser, not to mention 
 the possibility of DOM access.

Mozilla scripting: As a side note, right now we're implementing scripting 
via xpcon. I didn't know about this new npruntime model, so we may 
switch to that for the next version of the plugin.

Mozilla: This opens up a good discussion. What I really like about 
npruntime is the native access to the DOM. On IE, COM gives us that 
too. The problem/question is -- maybe you guys have ideas -- how 
to expose those C++ reference counted objects to REBOL clients?

Josh, thanks for explanation about the delayed events. What a pity 
you cannot improve this also in Rebol2.x version as this problem 
sheds bad light upon Rebol/View apps (which uses drag'n'drop and 
simmilar features).

Yes....we're looking into that. I'm sure there's a way.

There's always a way :)

Josh: so you basically need to replace WndProc handler with a plugin 
specific one right?

Well....the problem is that the plugin has to handle its own window 
events because of the COM architecture. And REBOL has to handle its 
own events for other reasons. Soo.....maybe instead of an invisible 
proxy window, we can make REBOL's window a real window that sits 
on top of the plugin window, then it would get its events directly.

Yes...now the question is, does deactivate mean switching outside 
of the browser? or does deactivate meaning switching outside the 
plugin, i.e. to a HTML text box on the page?

we'll want to make that a test case when we implement this.

Also, we have included information about the alpha version of REBOL/Plugin 
for Mozilla-based browsers. As we have mentioned before, this is 
a very early-stage release that contains numerous problems. Please 
do not use it on production machines.

It's been a long day. :)

networking: i would onlyuse browser forthe same things. if i do a 
"read http://*"in rebol, that is connect/read/disconnect too? If 
something need performance i would use own implementations. Although, 
IIRC when i check cgi-headers, i see usually "keep-alive" from the 
browser. But no expert there.

cyphre, I already wrote my own event filtering, but had a bit of 
hope that it would be possible to do internally for R3. I just personally 
think it's a bit too high level a place to solve the problem.

wrt own window on top to do the window messages, etc -- I'm all for 
slamming itself on top of the browser, and not going through it to 
embed view.   or make it a "windowed" control, which is how IE does 
SELECT elements.  The complexity there is having it crop to be part 
of the page.  I think wndows media control is like that, where you 
can pick a windowed version, which performs better (probably from 
similar things that you are running into.  MSAgent runs in the browser, 
and is allowed ro roam anywhere on the screen in an irregularly shaped 
winoow.  It also starts a server process which handles all calls 
to the interactions with applications like IE and Office that take 
advantage of that aspect.  It's all asynchronous/multithreaded, and 
shuts down automatically when there are no more client controls to 
serve.


The DOM provides screen position information, but the downside is 
that with embedded controls like Adobe SVG viewer and Flash is that 
they will respond correctly to transparency (showing html page background 
through transparent parts of control  -- never got REBOL plugin to 
do that, which has something to do with wmode="transparent"  or something 
similar

Extracting the download into the plugins folder creates a sub-folder 
called rebol-moza1 containing the files.

Tried copying the files out of there back inot the plugins folder 
and  closing & opening firefox, but still no joy :-(

pekr, maybe it's related to how there can be only one instance of 
the plugin running at a time. maybe when reloading, the first instance 
is never shut down

A whole load of plugins but nothing for Rebol

...a thousand thoughts rolling around at once....

If there was a way to make the plugin load up an out-of-process EXE 
rather than an in-process DLL, and if we could load up a new REBOL 
EXE for each new instance of the plugin.....we might be able to solve 
a whole lot of problems at once......for example, multiple instances....

wouldn't that be a security hole?

Or take security/licensing......we could have the plugin DLL automatically 
download the correct version EXE (View/ViewPro/Command/etc.) based 
on the version the script requires (so the initial download could 
be quite small, with a "download as needed" architecture)

No.....not a security hole. Acrobat works that way.

but why exactly is once instance at a time a problem? why is this 
limitation there?

If you let the EXE manage its own window in the plugin client area, 
it's not a problem.

Henrik: I can't go into specifics of the REBOL DLL, but essentially, 
its a threading issue. Each new instance of the plugin DLL loads 
in a seperate thread, and REBOL is not multi-threaded yet. Carl may 
be able to provide more specifics as to the limitations within REBOL.

So, with a DLL architecture, you have to load only one instance of 
the REBOL DLL, and then modify the DLL to support multi-threading. 
But with a multiple EXE architecture, it is essentially like REBOL 
is now.....one EXE per instance.

For me the plugin download on the page Josh sent a link for. However, 
when I try to run the examples, none of them will work. This is on 
IE.

I just get an outline of a box.

do you see a red X?

Louis: try a restart of your computer. that may free up any IE resources 
that are in use.

No red x, but a window pops up which says: Show on face in closed 
window.

That window pops up even before I click on a link to a demo, but 
again when I click on a demo.

I am glad to see this working. I have a use for the plugin.

REBOL I believe has a great future.

Dunno if my last post last night made it.  as soon as I sent it, 
the world went down and i was unable to reconnect.  I think there 
is a misunderstanding about what a windowed control is, and that 
is throwing people off.  In the post I mentioned how MSAgent works, 
where you have a central server app that communicates with all the 
instances of the control, and I think something like that would be 
perfect for REBOL.  If there was a way to create an instance dynamically 
( using new ActiveXObject, for instance), then for those plugin scripts 
not needing the View UI, that would be a nice option, because that 
would allow using it from a WSF, as well.  On a side note, when trying 
to use the plugin in an HTA it's crash city.

ScottT, thanks. need do a lot of thinking here.

no problem.  I'm no good at REBOL, but I probably know IE a little 
TOO well.  I was able to create the OBJECT tag dynamically with no 
ill effects, though.  One thing I couldn't get working is transparency, 
though.  Don't strain yourself.  I'm sure it's a mess to get anything 
working.  I'll be in and out but reading religiously.

Got the Plugin working with Firefox ... thanks for the help ... will 
try and code a couple of demos tommorow.

not too familar with proxy settings except through the auto-config 
script, which is just a javascript   here's a link: http://www.microsoft.com/technet/prodtechnol/ie/reskit/6/part6/c26ie6rk.mspx?mfr=true
 


But just because it's javascript doesn't happen to mean it's available 
through do-browser, I don't believe.

Pekr, I can't go into details here. Sorry. Just know that currently 
it really is a thread problem.

so it's not in the source for the view installer, and not in the 
normal mezz code. has to be a different component.

Threads: Rebol puts important stuff in globals. That is similar to 
putting things in the globl context: with a single thread it is ok 
to change a var. With multiple threads andno coordination, itleads 
to chaos.. Think two threads use the  same interpreter-pc.

ok, ok, I just do not understand, why browser should use several 
different threads? Couldn't it be simply that they multiplex between 
various stuff? In such case  - nothing would be conflicting? (beware 
- just a speculation of non-experienced low-level "coder" :-)

Regarding multiple threads/instances: we're looking into a solution 
that may solve this problem.

Hi all. Hope you had a good weekend.

I am working on a design doc for making the default security settings 
for the plugin more restrictive.

I know we talked about it a while ago, but those discussions are 
long gone from REBOL and from the web......I apologize, I should 
have archived them. Can you repost your thoughts on the default security 
model, in *concise* posts please? thank you!

BTW, you talked about rebol as external process,sharing window. Its 
not plugin, but could that work between rebol-apps? view-desktop 
could profit a lot.

Extra Security, some thoughts:
- 'secure for ips, eg: secure [net ask tcp://rebol.com allow]
- don't share sandbox-folders between hosts.
- if possible memory-restriction, hd, cpu?
- clipboard-restriction somehow?

- check for memory-access, specially disable struct! . IMO real hackers 
will figure out how to inject code by poke. 

- reblets can store executable code by naming the file *.exe. Does 
not run immediate, but script can open folder in explorer by browse, 
and one wrong click runs it. (or is windows smarter now? Maybe you 
could add an own extension always, and maybe store everything as 
64#{} ?

- Make sure untrusted reblets don't run invisible, can snoop clipboard, 
or at least users online-times. I guess creatives can find other 
uses.

- Maybe some kind of log about starts/stops, with urls? To have a 
little chance of tracking. Some kind of global console.
- Running out of thoughts for now.

- protect access to real file-pathes. kind of chroot. getting 'what-dir 
can be a good hint for attacks i guess. At least mozilla puts a random 
part in profile-folders.

A couple of quick thoughts:

[*] Don't allow reading/writing outside of a local sandbox......That 
includes not allowing access to URLs elsewhere on the web.  permitting 
wider local access and permitting wider web access should be separate 
security settings
[*] Disallow send by default

that is a very good idea volker!

this should actually be added as a standard REBOL feature IMHO!

BTW how about changing the exe to a thin wrapper around the dll? 
Would be a single download for both. (could be offered in both ways, 
completely one exe, or wrapper + plugin + dll).

Volker. Jaime.  Clipboard access should probably raise a security 
request, like it does in (secured) browsers.   Maybe it should also 
be part of 'secure  ...

Maybe a native 'field, which is not accessible from the script until 
"enter", and allowing pasting there? Rebol3, how much protection 
can modules give?

Yes. You should try disabling third party cookies in your browsers 
and see how much stuff is leaked to  through that., easy enough to 
steal from a form a user just filled out ;-)

Looks like Volker covered the security issues I'd note.  About Rebol 
as a COM server process--I would think that would be the way to go. 
 Pretty sure that is how Acrobat runs, too.  Basically, the first 
time you run into a PDF on the web Acrobat32 starts, and handles 
all instances.

To disallow send properly means a mini firewall.  If you disallow 
SEND, script implements its own function. If you remove smtp scheme, 
script implements its own smtp scheme. Therefore, you have to get 
it at the root, which is to block outgoing tcp on port 25.

hmm, blocking port 25? What if I am a hacker and I run smtp on purpose 
on different port? ;-)

Oldes, it should be a different word yes. every plugin does not send 
mail directly, they prepare the mail. it is what user expects.

With exe people run rebol intentionally (although /desktop goes in 
the other direction). With plugin user goes to a web-page and webdesigner 
turns that into a rebol-page without notice.