[racket] racket project idea: viable html5 web browser

Unfortunately I don't think I have enough time to be a serious contributing
developer here, but the goals of this project brought to mind another
project I had studied some time ago with similar goals of creating a secure
browser based on a capability-based security model.

The project team used a language - E - implemented on JVM, though I see
they also have a Common Lisp implementation. The capability-based E
language was used to create a browser as part of the DarpaBrowser
initiative a while ago. They also expanded on their browser work to create
a secure desktop environment.

Relevant links: http://www.combex.com/index.html
                      http://www.erights.org/#quickstart
                      http://www.eros-os.org/essays/capintro.html (a primer
if you're not familiar with the capabilities concept)

I think given what they've done so far, this could be a good model for a
Racket-based secure browser. I'm thinking why not implement an E version
(or something more lispy but inspired by E) as a #lang and using that to
implement all of or just the core functionality for the new browser.

Just adding a few of my cents about what I've seen out there in the wild.
Internet security is so hard, I think the only realistic route to getting
it right is to have some sort of unified security model that can be applied
to the whole browser while remaining simple and powerful enough to be able
to reason about the system security properties(and checked by an automated
proof tool)

Based on my own readings, it looks like the above desired security model is
made possible by using capabilities.


On Mon, Feb 3, 2014 at 5:04 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:

> I'm just putting this idea out there, to see whether anyone is seriously
> interested...
>
> I'd like to see a few attempts to make a *viable* secure HTML5 Web
> browser, using Racket or Haskell.  HTML5 with JS, CSS layout, local
> storage, but no sound or video for now.  Fully GNU-style Free Software, and
> not biased by any commercial conflicts of interest.  Internally secure and
> stable in ways that current browsers clearly are not.
>
> If you need to ask why, look at the constant stream of Web browser
> security exploits, the *multi-gigabyte* source code bases of C and C++
> code, how Firefox's ongoing dependence on recent system library versions
> makes it hard for stable GNU/Linux distros to maintain a browser with
> security updates, etc.  Modern browser implementations have become
> monstrosities beyond what is necessary for the Web standards they have to
> support.  (Also, a viable Web browser is the current big implementation
> barrier to a general-purpose desktop/handheld OS that has the entire
> userspace implemented in Racket or Haskell, straight atop the Linux kernel.
>  But for now, think of it as a standalone app.)
>
> Myself, I'm *not* looking for a "hey, we can kinda make a toy browser in
> Racket good enough to get a paper out of it", nor "hey, a few people
> attempted Web browsers of some kind, I don't know how far they got, maybe
> we could start with one of those", nor "it can start out as a student
> exercise but take over the world 10 years later like Linux did."  Rather, I
> am looking for something that is done from the start to be viable in the
> near term as a primary desktop and handheld Web browser (excepting
> sound&video for now).
>
> If a couple people are seriously up to sacrificing their evenings and
> weekends on this for a year, then I can help with architecture and some key
> components, but I don't have time for attempts that aren't credible.  If we
> could get to the point that we've demonstrated brilliance and solid
> progress, and have a credible 6-month plan for completion of a viable
> browser, then there is an angle I could try to get funding, to pay the
> contributors to keep going at that point.  (I wouldn't try to get funding
> from the start, because the project wouldn't be taken seriously until we
> have something impressive to show, and the timeline is too long and
> unpredictable at the start.)
>
> Let me know if you'd like to talk about this.
>
> Separately, everyone should be encouraged to write a toy Web browser.
>  It's one of those toy programs that everyone should write, as a fun
> learning exercise.  (Previously, such programs have been text editor, CD
> player, Scheme interpreter, compiler, kernel, X window manager, etc.).  But
> this toy is separate from above, where I'm talking about something that is
> not a toy.
>
> Neil V.
>
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140216/cc34c286/attachment.html>