On Mon, 02 May 2016, Leo Gaspard <leo_AT_gaspard.io> wrote:
> 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).
There's another way: push for a simpler (= saner, more secure) web.
The fact that Mozilla, an organisation responsible in big part for many
of the modern insanities of www, has at one point realised, "wow, this
shit sucks horribly, we need to take a step back and rewrite from
scratch", gives a little shadow of hope.
I say, go back to the basics, and push web developers to write apps that
scale down gracefully. I'm saddened that my career path has led me
towards contributing to the mess, but still whenever I have the
opportunity, I include a fallback and test e.g. with elinks, dillo [1].
Your bank's website doesn't work in Dillo? Write them a letter, call
them. Or vote with your feet.
[1]:
https://github.com/rollcat/mpw
> 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.
Compiler-level seatbelts are too good not to have! That's how I'd see
THE candidate to replace C: safe by default, full control only when you
need it. Add: actually simple (looking at you, Go, Rust), and we'd
finally have a worthy contender.
However for those occasions when you *think* you know what you're doing,
but still get it wrong, you also need an OS-level sandbox. The module
that talks to the network should have no possibility to access the
filesystem or the display; and no amount of "unsafe { ... }" should ever
be able to bypass this. For this to work, you also need a decent,
modular architecture and correct privilege separation.
K.
Received on Mon May 02 2016 - 18:08:11 CEST