Prev: gnatmake problem
Next: Ada help file indexed by keyword
From: Georg Bauhaus on 25 Apr 2010 06:41
On 4/24/10 2:38 AM, Peter C. Chapin wrote:

> Any browser that could be realistically used would need to support JavaScript.
> While an Ada JavaScript implementation might (or might not) be more secure
> than a C implementation, it seems to me that any vulnerability related to the
> JavaScript language itself would still be a risk.

A major flaw in Javascript is how its type system was built,
I think. (The vulnerabilities being listed in the Top 25
vulnerabilities of 2010.) Being less prejudiced against Ada
(or even Pascal) could have helped with giving Javascript
a robust foundation:

1 - they obviously used (the dark side of) duct tape programming
when wrapping the fundamental types of C, lazily. Perhaps in order
to ship something quickly.
For the C types, chose those available on a given platform...! (IINM)
Looking at the "flexible" phrasing in the Javascript ECMA standard still
makes me sad. BTW, Ruby has the very same problems with its base types.
This problem---it seems to have spread across "scripting"
languages---does not seem to be easy to correct after the fact.

2 - The higher level Javascript stuff looks like it is borrowed
from CLOS.
What does Ada have to offer here? Can it improve a poor man's CLOS
implementation so it becomes better than one built atop a C
implementation?


> In any case, the real benefit of such a project would be more in the
> development of associated libraries and supporting code (imagine processing,
> HTML parsing and rendering, CSS handling, etc, etc)... and in the visibility
> a successful project would give to Ada. I suspect Ada was first standardized
> before many current web developers were born; it might be fun to see what
> sort of reception an Ada web browser project would get in that community.

I think image processing or movie handling could profit. The reason
is that Ada programmers, by stereotype or nature, will think about sizes
and boundary cases. Speed is near C's as is once again demonstrated
by the Mandelbrot entry in the Shootout. However, Ada's run-time
systems are not (yet?) supporting multicores that well. If it
matters.

> Anyway a good first step might be the implementation of an HTML 5 parser in
> Ada.

What is an HTML 5 parser supposed to be?

If it is to parse the SGML text defined by the HTML 5 grammar
then you would, in effect, have to copy browsers' near natural language
processing capabilities, since having only an SGML parser with little
more than moderate error correction capabilities is by far not enough
for HTML.

Some browsers have a parser switch, IIRC. Switch to best effort
mode for the important, but junk, HTML code that is out there,
inevitably, new or old. Or be more optimistic and
make an attempt at treating input text as if is was well formed
XML text.

If it is to be a cooperative component of an HTML 5 system,
it needs to play well with Javascript, CSS, and all sorts of
media and HTML 5 type storage capabilities. (Load data from
local storage, have Javascript add some remote XML, merge that,
apply CSS, etc...)
From: Peter C. Chapin on 25 Apr 2010 12:24
Gautier write-only wrote:


> Maybe it is a bit naive, but I have the impression that JavaScript's
> vulnerability can be limited to the interaction with the surronding
> operating system: file I/O and code execution (this includes starting
> a plug-in).

I don't know much about JavaScript at the moment, honestly. It sounds like you
are saying that current insecurities in JavaScript are in its interface to
the rest of the world. If so, a more secure implementation of the language
itself might help (depend on what "more secure implementation" really means,
exactly).

> Just kidding. It is a very good idea, especially that the W3C
> specification gives also hints about the parsing.

Another potential benefit is that the W3C is, as I understand it, currently
looking for implementation feedback on the proposed specification. So the
time seems ripe to think about an HTML 5 implementation.

Peter

From: Peter C. Chapin on 25 Apr 2010 12:29
Georg Bauhaus wrote:

> What is an HTML 5 parser supposed to be?
>
> If it is to parse the SGML text defined by the HTML 5 grammar
> then you would, in effect, have to copy browsers' near natural language
> processing capabilities, since having only an SGML parser with little
> more than moderate error correction capabilities is by far not enough
> for HTML.
>
> Some browsers have a parser switch, IIRC. Switch to best effort
> mode for the important, but junk, HTML code that is out there,
> inevitably, new or old. Or be more optimistic and
> make an attempt at treating input text as if is was well formed
> XML text.

HTML 5 is intended to address (fix) the current horrible mess by specifying in
a reasonably precise way exactly how erroneous documents are to be handled.
That is, all HTML 5 implementations should handle bad documents in a similar
manner. Note that HTML 5 is *not* an SGML markup... nor is it intended to be.

A fully functioning web browser in today's world needs to handle "tag soup"
documents. Maybe someday that will no longer be necessary. Still... a clean
room implementation of HTML 5, in Ada, might be a nice contribution to the
cause of creating a better web browser.

I wonder if there are any easily identifyable security critical components
that could benefit from SPARK.

Peter

From: Warren on 26 Apr 2010 11:37
Peter C. Chapin expounded in
news:4bd23c72$0$2399$4d3efbfe(a)news.sover.net:

> Gautier write-only wrote:
>
>> My impression is that a good part of vulnerabilities are indeed
>> within plug-ins, another good part is between the browser and a
>> plug-in (typically, browser X need to be patched but not the others
>> nor the plug-in), and the third part, important as well, is about
>> CSS, JavaScript, image storage or decoding, XML, HTML parsing and
>> other core parts of browsers.
>
> I had actually thought that building a web browser in Ada would be a
> nice project (if only I had more time!). I'm not sure how much of a
> difference in security it would make... probably some.
>
> Any browser that could be realistically used would need to support
> JavaScript. While an Ada JavaScript implementation might (or might
> not) be more secure than a C implementation, it seems to me that any
> vulnerability related to the JavaScript language itself would still be
> a risk.
...
> Peter

To do it "right" would involve rewriting almost everything
above the O/S level, as you implied. Everything including
the image rendering libraries would be necessary.

The trick perhaps, is to convince the Military to do it as
an open sourced project. ;-)

Warren
From: Martin Krischik on 27 Apr 2010 07:41
Am 23.04.2010, 16:37 Uhr, schrieb Georg Bauhaus
<rm.dash-bauhaus(a)futureapps.de>:

> On 23.04.10 15:56, Maciej Sobczak wrote:

> BTW, why do we still subscribe to the notion "integer overflow"
> when the one thing that any sequence of what is commonly known
> as integers cannot possibly do is to overflow? Maybe the
> wording is at the heart of the problem.

Not at all. This is an integer overflow:

int dayOfMonth = 32;

Simplified example of course.

Martin
--
Martin Krischik
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: gnatmake problem
Next: Ada help file indexed by keyword