Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[David Marceau <davidmarceau@sympatico.ca>]

Darren New wrote:
> 
> David Marceau wrote:
> > >         Would you write a Java Virtual Machine implementation in Ada ?
> > In my opinion it is a waste of time because assuming you have access to
> > the source, you could recompile on any platform quite easily.
> > The recompiled ada would be much faster than a JVM running java byte
> > code.  JAVA and jvm is hype IMHO.
> 
> Errr, except for the web sites that have Java on them, yes? I mean, how are
> you going to run a java applet off a web site if you don't have a JVM in
> your browser?
That's my point.  I would prefer not to push java byte code across the
net.
I would prefer pushing flash file format which may have some script 
dependencies that ressemble java (i.e actionscript) however there is
nothing stopping another flash player 
from having another script language(i.e. ada itself).

> 
> > >         How about FTP/Telnet/secure sockets, etc ?
> > Sockets. Don't have to Adasockets
> > Secure sockets. Don't have to Adasockets
> > Http downloads/uploads binary files. Don't have to AWS.
> > FTP seems to be redundant now. No.
> 
> Um, ... no, it's not.
I'm human :)

> 
> > Telnet yes.  Great for debugging.
> > gdb yes.
> > ssh/ssl.   Yes and by far the most important for security reasons.
> 
> You missed smtp and nntp.
I'm human :)
> 
> > > What method would an Ada browser use to handle the requirement to
> > > dynamically support plug-in modules and to execute the code within
> > > that plug-in ? What would be the advantages of that method ?
> > Dynamic run-time plug-ins are a security issue.
> 
> That's the point. The question is how Ada would make run-time plug-ins
> safer, and the answer is that it wouldn't.
I will attempt to clarify why I believe ada is safer for creating
dynamic run-time plugins.

Firstly there are two types of dynamic run-time plug-ins:
1)in-process(dll COM objects as Microsoft calls them)
	As you know they may be gui or non-gui plugins.
	If one instantiates an untrusted third party in-process plug-in, 
	we can expose the original executing process to unwanting hacking 
	since they share the same machine and user privileges as the original
executing process.
2)out-of-process(EXE COM objects as Microsoft calls them)  plug-ins.
	As you know they may be gui or non-gui plug-ins.
	If one instantiates an untrusted third party out-of-process plug-in,
	the original executing process' memory remains less vulnerable to
outside attacks for two reasons.
	The out-of-process plug-in doesn't necessarily have to run on the same
machine as the original executing process.
	The out-of-process plug-in doesn't necessarily have to run with the
same user privileges.

Secondly, if you examine the AWS approach, you will note I am talking
out-of-process plugins.
I am explicitly declaring the AWS approach as a sound approach for the
above reason of separate machine and separate user privileges.
> That's the point. The question is how Ada would make run-time plug-ins
> safer, and the answer is that it wouldn't.
Ada by design makes safer executables than c/c++/java.  Thus is will
make safer out-of-process plugins gui and non-gui ones.
In a web browser(ada compiled or not) you don't necessarily have to
design it to invoke its plugins with the same user privileges.
That's what would make an ada-based browser with ada-based plug-in safer
to run and use.
If you don't agree with me then please clarify this or perhaps I will
consider you as a comp.lang.ada flaming MicroSerf.

Again feel free to check out a clear example with excellent
documentation
AWS plug-in architecture AWS http://libre.act-europe.fr/aws/ 

Sant� bonheur,
David Marceau
He who lies on the ground shall never fall off. Sun Tzu