MMM, a Web browser with applets in Caml Special Light

MMM, a Web browser with applets in Caml Special Light

[Francois Rouaix]

It is my pleasure to announce a new release of the MMM Web browser 
(0.30alpha1).

Main changes since v0.26:
* translated to Caml Special Light
* support for applets in Caml Special Light
  Applets are CSL bytecode files, stored on a web server, retrieved by
  the browser and dynamically linked into the browser.
  Applets bring a new dimension to the Web: documents can now be made
  active.

The 0.30 version of MMM is currently in alpha test.

For more informations:
http://pauillac.inria.fr/~rouaix/mmm/
ftp://ftp.inria.fr/INRIA/Projects/cristal/Francois.Rouaix/mmm

---
J'ai le plaisir de vous annoncer une nouvelle version du navigateur
Web MMM (0.30alpha1).

Principaux changements depuis la version 0.26:
* portage sous Caml Special Light
* introduction des applets en Caml Special Light
 Les applets sont des modules compiles, stockes sur un serveur Web,
 telecharges par le navigateur et linkes dynamiquement dans le navigateur.

Pour plus d'informations:
http://pauillac.inria.fr/~rouaix/mmm/
ftp://ftp.inria.fr/INRIA/Projects/cristal/Francois.Rouaix/mmm

--
Francois.Rouaix@inria.fr                   Projet Cristal - INRIA Rocquencourt

Re: MMM, a Web browser with applets in Caml Special Light

[Christophe Raffalli]

* support for applets in Caml Special Light
  Applets are CSL bytecode files, stored on a web server, retrieved by
  the browser and dynamically linked into the browser.
  Applets bring a new dimension to the Web: documents can now be made
  active.

Have you think about security ? Basically an applets should
not be able to write or delete any files, so not all the caml-light library
should be accessible.

----
Christophe Raffalli
Dept. of Computer Sciences
Chalmers University of Technology

URL: http://www.logique.jussieu.fr/www.raffalli

Re: MMM, a Web browser with applets in Caml Special Light

[Francois Rouaix]

> Have you think about security ? Basically an applets should
> not be able to write or delete any files, so not all the caml-light library
> should be accessible.

Yes, naturally. Security is *the* important issue with applets !
Basically (to make a long story short), security relies on the type and 
module system.
Basic facts about Caml applets security are discussed in
<URL:http://pauillac.inria.fr/~rouaix/mmm/applets.html>
Check also the paper submitted to publication
<URL:http://pauillac.inria.fr/~rouaix/mmm/papers/mmm-ps.gz>

I'm currently writing the reference documentation for applets, so keep an eye
on the MMM home page.

Finally, please note that I'm not making any claim about security yet.
Although I've been working on identifying and blocking security holes for
several weeks, I may have forgotten something.
I NEED FEEDBACK ON THIS TOPIC. If you are interested in Caml applets, please
contact me. It might be worth setting a up a separate mailing list.

--
Francois.Rouaix@inria.fr                   Projet Cristal - INRIA Rocquencourt
WWW Home Page: http://pauillac.inria.fr/~rouaix/

Re: MMM, a Web browser with applets in Caml Special Light

[Stefan Monnier]

Francois Rouaix <Francois.Rouaix@inria.fr> wrote:
> Yes, naturally. Security is *the* important issue with applets !
> Basically (to make a long story short), security relies on the type and 
> module system.
[...]
> Finally, please note that I'm not making any claim about security yet.
> Although I've been working on identifying and blocking security holes for
> several weeks, I may have forgotten something.

and in http://pauillac.inria.fr/~rouaix/mmm/applets.html, he wrote:
>    Bytecode integrity
>      All of the above mechanisms rely on bytecode integrity : all checks are
>      done at (dynamic) link-time. The checks therefore assume that the
>      bytecode is the intact output of an unmodified CSL compiler. The solution
>      we choose is to provide support for PGP-authentication. In paranoid mode,
>      each loading of foreign bytecode is subject to confirmation by the
>      user. When the bytecode has been PGP-signed, the user is shown the PGP
>      diagnostic on the file.

Confirmation by the user sounds stupid to me. How is he supposed to know
that the bytecode is correct ? I see a few alternatives:
- somehow check the bytecodes (Java does it, but I have no idea if it's
  doable with CSL's bytecodes)
- transmit source rather than byte codes (since source code can be checked
  easily)
- use authentication: the bytecode has to be signed by some trusted entity.
  It would for instance be possible to provide a mail server that receives
  CSL source, compiles it, and signs it with its private key: checking the
  signature against the widely available publickey would prove that it is
  really the output of an unmodified CSL compiler. This would probably require
  the use of PGP3's API since forking a PGP for each execution sounds
  awfully expensive to me (the advantage of having precompiled bytecode
  would be less obvious)

>    Denial of service
>      MMM does not offer protection against this type of attack. A trivial
>      example is a non-terminating applet : since CSL does not provide threads,
>      the browser will get stuck in the execution of the applet, and the only
>      remedy is to kill the browser.

I can deal with this. Providing threads would be a good idea anyway in CSL, tho.
But it should be possible to restrict the CPU and memory usage (and probably
other aspects like network, file system, processes, etc...) of a thread.


	Stefan

Re: MMM, a Web browser with applets in Caml Special Light

[Francois Rouaix]

> Confirmation by the user sounds stupid to me. How is he supposed to know
> that the bytecode is correct ? I see a few alternatives:
> - somehow check the bytecodes (Java does it, but I have no idea if it's
>   doable with CSL's bytecodes)

Open problem. The idea here is "Keep It Simple and Stupid". CSL removes all
type information from the bytecode (except link information).
I'm not going to put it back to do type checking on the 
bytecode (assuming it is feasible at all).

> - transmit source rather than byte codes (since source code can be checked
>   easily)

Easily, easily. I would not bet on it. Besides, it would mean embedding the CSL
compiler inside the browser. Moreover, the point of distributing bytecode is
precisely not to transmit the source.

> - use authentication: the bytecode has to be signed by some trusted entity.
>   It would for instance be possible to provide a mail server that receives
>   CSL source, compiles it, and signs it with its private key: checking the
>   signature against the widely available publickey would prove that it is
>   really the output of an unmodified CSL compiler. This would probably require
>   the use of PGP3's API since forking a PGP for each execution sounds
>   awfully expensive to me (the advantage of having precompiled bytecode
>   would be less obvious)

I have the impression that I wrote about this all over the place in the
various MMM documents related to security, in particular:
<URL:http://pauillac.inria.fr/~rouaix/mmm/papers/mmm.ps.gz>
<URL:http://pauillac.inria.fr/~rouaix/mmm/manual/node4.html>

Please note that <http://pauillac.inria.fr/~rouaix/mmm/applets.html> is only
a very short introduction.

*Indeed*, I am advocating the use of trusted compilers.

Concerning the PGP3 API (for which I haven't seen public announces yet,
though I may not be watching the proper groups):
There is no need to authenticate the bytecode at each compilation during
the development. The applet author can trust his own bytecodes.
If it turns out to be a performance problem for a trusted compiler, then
yes, of course, the PGP3 API will be used.
For the browser itself, we need to fork PGP only once for each bytecode
received, so I don't think it is too much of an overhead.
There will be a legal problem if I attempt to distribute browser binaries
which include PGP code.


> I can deal with this. Providing threads would be a good idea anyway in CSL, tho.

Don't hold you breath, but threads are the latest goodie available for CSL,
and the very next thing to be integrated in MMM.

> But it should be possible to restrict the CPU and memory usage (and probably
> other aspects like network, file system, processes, etc...) of a thread.

Yes, I had the same idea. If you have more precise views on how this should be
made, feel free to share.

--
Francois.Rouaix@inria.fr                   Projet Cristal - INRIA Rocquencourt
WWW Home Page: http://pauillac.inria.fr/~rouaix/

MMM, a Web browser with applets in Caml Special Light

[Francois Rouaix]

It is my pleasure to announce a new release of the MMM Web browser 
(0.30alpha2).

MMM is a free WWW browser written in Caml Special Light, using Tcl/Tk for
the user interface.

This is mostly a bug fix release, although some new features have been added
(display of HTML parsing errors, transparent gifs, a file selection dialog
box by Jun Furuse, and pseudo-CGI support).

The main characterics of MMM as a Web browser are:
  * supports HTML2.0 level 2 (including forms)
  * multi-window, asynchronous
  * applets in Caml Special Light
  Applets are CSL bytecode files, stored on a web server, retrieved by
  the browser and dynamically linked into the browser.
  Applets bring a new dimension to the Web: documents can now be made
  active.

For more informations: <URL:http://pauillac.inria.fr/~rouaix/mmm/>
The distribution is at
<URL:ftp://ftp.inria.fr/INRIA/Projects/cristal/Francois.Rouaix/mmm>
Binaries for sparc (SunOS 4.1.x), alpha (DEC OSF) and i486 (linux a.out)
are available, as well as complete source distribution.

---
J'ai le plaisir de vous annoncer une nouvelle version du navigateur
Web MMM (0.30alpha2).

MMM est un navigateur WWW gratuit, ecrit en Caml Special Light, utilisant
Tcl/Tk pour l'interface homme machine.

Cette distribution repare les bugs connus de la version precedente, et
introduit quelques nouvelles possibilites (affichage des erreurs d'analyse
HTML, GIFs transparents, boite de selection de fichiers par Jun Furuse, et
pseudo-CGI locaux).

Les principales caracteristiques du browser sont:
  * traite HTML2.0 level2 (y compris les formulaires)
  * multi-fenetre, asynchrone
  * applets en Caml Special Light
 Les applets sont des modules compiles, stockes sur un serveur Web,
 telecharges par le navigateur et linkes dynamiquement dans le navigateur.
 Les applets ajoutent une nouvelle dimension au Web : les documents peuvent
 maintenant etre actifs.

Pour plus d'informations:
<URL:http://pauillac.inria.fr/~rouaix/mmm/>
La distribution est a
<URL:ftp://ftp.inria.fr/INRIA/Projects/cristal/Francois.Rouaix/mmm>
Des binaires pour sparc (SunOS 4.1.x), alpha (DEC OSF) et i486 (linux a.out)
sont disponibles, ainsi que les sources complets.

--
Francois.Rouaix@inria.fr                   Projet Cristal - INRIA Rocquencourt