<div dir="ltr"><div><div><div><div>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. <br><br>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.<br><br></div>Relevant links: <a href="http://www.combex.com/index.html">http://www.combex.com/index.html</a><br> <a href="http://www.erights.org/#quickstart">http://www.erights.org/#quickstart</a><br>
<a href="http://www.eros-os.org/essays/capintro.html">http://www.eros-os.org/essays/capintro.html</a> (a primer if you're not familiar with the capabilities concept)<br><br></div>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. <br><br></div>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)<br><br></div>Based on my own readings, it looks like the above desired security model is made possible by using capabilities.</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Feb 3, 2014 at 5:04 PM, Neil Van Dyke <span dir="ltr"><<a href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm just putting this idea out there, to see whether anyone is seriously interested...<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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).<br>
<br>
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.)<br>
<br>
Let me know if you'd like to talk about this.<br>
<br>
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.<br>
<br>
Neil V.<br>
<br>
____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/<u></u>users</a><br>
</blockquote></div><br></div>