Re: Interest in Lua Web Plug-in?

["Thomas Harning Jr." <harningt@...>]

I think this would be a great idea.  The company I work for would find
this to be a great extension for what we're working on.  The basic
requirement would have to be for compatibility w/ IE >= 6 (maybe just
7 by the time the plugin would be complete), Firefox >=2, and if at
all possible, Safari.  We'd also need for the ability to load
extensions, which would be described below.......

One thing, however...  I don't think we should make the plugin
super-heavyweight and include all sorts of libraries by default.
The way I see it to make this lightweight, but support extra items:

Create a 'base' plugin that includes Lua and the DOM interaction items
such that you can do <script language="lua"/>
(Maybe the DOM would not be exposed right away... that could be an
external module ...)

This would be a feat in itself and probably need plenty of testing.
It'd also need some serious sandboxing to get rid of access to unsafe
Lua constructs, such as debug, os, io, etc...

If the 3D, sound,etc were automatically included, then the plugin
would be huge and harder to debug.  Not to mention that the plugin
would not likely be used by the company I work for since it would open
up too many potential holes from the get-go.  Modularizing the system
makes it easier to test each individually for security/bugs.

In order to support additional items, like 3D, sound, etc... you'd
want to setup a secure external module system so that you can load
modules that access "unsafe" items, such as io.open, as well as access
to binary libraries.


Since I work for a security-minded company, I'd recommend that the
module system be setup using a signature/cert system, so that a user
could load a page that loads in external modules while knowing who the
stuff came from.

An example scenario:
-- user doesn't have anything installed but a browser right now...
* User accesses web page that has the LWeb plugin...
* User is asked to install the activex/XPI plugin in order to fully
experience the site (or for it to work at all)
   * This ActiveX/XPI plugin is the base lua plugin w/ DOM and the
signature system. and is a signed plugin
* One of the first scripts in the page asks to load an extension module
  * The certificate is downloaded for the extension and checked
against an internal list of OK roots
  * Since no roots will be there by default, the user is asked
whether or not they want to trust the certificate.  (An exception to
this could be that the normal list of plugin root certs, ex:
authenticode, would be considered OK)
  * If the user clicks OK (maybe just trusting the specific plugin)
the actual binary is downloaded, signature checked, and then loaded...
the script will get a success return value
  * If user clicks cancel, the script that asked for the module will
get the lua (nil, error) response and will resume as normal, just w/o
the extension loaded

I'd strongly recommend some sort of License that supports proprietary
extensions to be loaded... otherwise commercial support would be
limited... and basically, my company would be unable to take advantage
of the LWeb browser plugin...

To start off, I think we'd need to at least get a 'hello world' working, ex:
<script language="Lua">
print("Hello");
</script>

Where print would do the actual Lua print.

Next steps:
* Preliminary module loading system while setting up the signature system
* JavaScript interaction (I think this is important to make
transition easier.. + it makes it such that moving to DOM and testing
it more gradual)
* DOM interaction
* Simplistic UI module (ex: FLTK-based) for external GUI
* Enhance that UI such that it could be an 'integrated' page item
(ex: like what flash is)
* Add a sound library
* .........

Another idea (gee, so many) would be to set this up so that scripts
could potentially lock theirselves off from others... ex:
Script A is working w/ a module to securely get info from the customer
Script B is some malicious script somehow on the page and wants to
intercept that information

Script A could do something like:
lockMe(function()
  -- Code safe from external access here
 end)

That 'lockMe' protected function would perhaps run w/ its own fenv
that would somehow let extension modules know that it was protected.
Ex: for the UI system, a script could not get arbitrary access to
items, only through the objects setup would it work. ... Hrm.. maybe a
lockMe is unnecessary.. it'd just be the case that you'd write the
function such that locals were used and you'd protect access to the
information (ex: inside that function you wouldn't return the value,
you'd make use of it and let it die)
<script ...>
LoadModule("FLTK")
local win = fltk.createWindow()
local passBox = fltk.newPasswordBox()
win.addItem(passBox)
-- More code adding button...
-- Inside event for the button
  local pass = passBox.value
  secureMessaging.authenticate(pass)
</script>

Now.. since any script could do create window, create password box,
etc... the FLTK module would need to have some way of letting the user
know where that request came from.  An easy thing would be for signed
modules to set a Lua environment variable w/ their cert that could be
used to add an additional item to the UI to help w/ verification.
Ex:
+============+
| FLTK UI Window|
+============+
| <unsigned> or <signed by: 'clickable item'> |
+==========+

All UI elements could have this and not be permitted to change it.............

I think I'll dump this on the Lua Wiki when I get some more free time.

Please let me know what you think...
--
Thomas Harning Jr.