Re: [dev] "Note On Webkit Versions"

From: Leo Gaspard <leo_AT_gaspard.io>
Date: Mon, 2 May 2016 16:01:10 +0200

On 04/30/2016 03:04 PM, rain1_AT_openmailbox.org wrote:
> On 2016-04-30 11:47, Kajetan Jasztal wrote:
>> how about servo[1]? aims for memory security and fast parallel rendering
>>
>> [1] https://servo.org/
>
> There is a lot of hype about rust being 'memory safe' but where is the
> proof?

AFAICT, Patina [1] is a formalization of rust being memory safe, if
there is no "unsafe" parts.

> [...]

To get closer to the original topic, I think rust is among the best
choices for a webkit replacement. A webkit replacement *will* be huge,
bloated and sucky. It's pretty sad, but most of us need a way to access
sucky websites that won't work without javascript enabled (bank
websites, I'm looking at you).

Now, why would rust be a good language for this? The mere fact that it's
memory safe by default means a whole class of vulnerabilities just
vanish. And one of the largest surface of interaction of your computer
with the outer world being through the browser, it's usually a good idea
to keep it as safe as possible.

A webkit replacement written in C would need to have its entire codebase
audited for memory flaws. One in rust needs to be audited only in unsafe
blocks. For servo, that means a decrease of 99% of the work to be done,
if I understand correctly your sentence.

Sure, rust sucks. rustc can't be compiled without a rust compiler,
trying to go back in time to find one that can leads to an OCaml source,
and trying to go back the OCaml compilers to find the initial one you
fall upon LeLisp. So there is most likely no way to build a rust
compiler from a c compiler at the moment. This sucks. Rust is slow to
compile. This sucks. Sometimes you know what you are doing, but rust
tells you it is not thread-safe even when you know you have only one
thread. This sucks.

But rust at least gives you a bit of free safety, which is what I crave
most for in a web browser. And in my opinion, rust is one of the less
wrong alternatives to C.


[1] ftp://ftp.cs.washington.edu/tr/2015/03/UW-CSE-15-03-02.pdf


Received on Mon May 02 2016 - 16:01:10 CEST

This archive was generated by hypermail 2.3.0 : Mon May 02 2016 - 16:00:15 CEST