
GET /browser.exe - mikexstudios
http://blog.ezyang.com/2012/10/get-browser-exe/
======
laughinghan
Something I don't see anyone else saying: the World Wide Web's primary
"language", HTML, being so incredibly un-powerful and reliant on browsers for
new features, is an _intentional, FOUNDATIONAL design principle_ , called the
Principle of Least Power: <http://www.w3.org/DesignIssues/Principles.html>

I'm not saying I completely agree with it, but the rationale behind the
principle, and its incredible success, are compelling arguments against what
the article proposes, that are not addressed whatsoever.

Also, a nitpick I don't see anyone else making: the author doesn't seem to
know the difference between the Internet and the World Wide Web, which is
acceptable for a mediocre Web developer, but pretty embarrassing for someone
proposing a foundational change to the Web (one that, contrary to the
provocative "new Internet" gospel in the first paragraph, doesn't affect the
Internet Protocol Suite whatsoever).

(And of course, as pointed out by a plethora of other comments, the proposed
foundational change is essentially the Java VM.)

~~~
Locke1689
Edward Yang is very much aware of the difference between www and TCP/IP.

<http://ezyang.com/ezyang-resume.pdf>

Looking at your GitHub your resume is nowhere near as illustrious. Maybe we
can go back to the old days where we were just polite and gave our colleagues
the benefit of the doubt instead of assuming that lazy terminology is a signal
for incompetence?

~~~
cynicalkane
The requirement that one have an "illustrious" GitHub account is one of the
more surreal ad hominems I've seen.

~~~
Locke1689
Did you not read the section of my comment asking for an assumption of
competence? In no way am I arguing that he is incompetent based on his GitHub
-- just the opposite.

~~~
Muzza
cynicalkane didn't say that you said that _ezyang_ was incompetent.

> Looking at your GitHub your resume is nowhere near as illustrious.

~~~
Locke1689
I really don't think my point was that complicated. The OP latched on to a
minor word choice in order to make a judgment about the poster's competence.
If we picked an equally arbitrary measure, like github excellence, the OP
would not fair so well either. However, it is quite obvious that both metrics
are fairly poor. Instead of making snap judgments of people, maybe we could
just give them the benefit of the doubt?

~~~
Muzza
Your point is not complicated, but on the other hand you didn't actually make
it until now. You relied on me understanding that you consider you consider
judgement-by-Github to be equivalent to judgement-by-terminology. But
honestly: how was I to know that "hey yer Github sucks" was actually an
exemplification of what the _next sentence_ in your post said not to do, and
not just an ordinary internet insult?

Nota bene: I actually agree with you.

------
sp332
I like this idea! It reminds me of this page
<http://mozilla.github.com/pdf.js/web/viewer.html> which loads a JS-based PDF
reader and then uses it to render a PDF in your browser. It could be expanded
to do a lot more than static documents - in fact it seems to echo the ideas
that Alan Kay has been working on for decades.
[http://www.drdobbs.com/architecture-and-design/interview-
wit...](http://www.drdobbs.com/architecture-and-design/interview-with-alan-
kay/240003442?pgno=2) "Binstock: Still, you can't argue with the Web's
success.

Kay: I think you can... go to the article on Logo, can you write and execute
Logo programs? Are there examples? No. The Wikipedia people didn't even
imagine that, in spite of the fact that they're on a computer.... Go to a
blog, go to any Wiki, and find one that's WYSIWYG like Microsoft Word is. Word
was done in 1974. HyperCard was 1989. Find me Web pages that are even as good
as HyperCard. The Web was done after that, but it was done by people who had
no imagination. They were just trying to satisfy an immediate need.... what
you definitely don't want in a Web browser is any features.

Binstock: "Any features?"

Kay: Yeah. You want to get those from the objects. You want it to be a mini-
operating system, and the people who did the browser mistook it as an
application. They flunked Operating Systems 101.... I mean, look at it: The
job of an operating system is to run arbitrary code safely. It's not there to
tell you what kind of code you can run."

~~~
evv
Aha! That last quote puts it best. The OS should be a browser.

The core point here is that the OS should be able to run foreign applications
without an 'install' process, just like I don't need to install a webpage to
use it. I assume the OP is not suggesting that we strip all of the useful APIs
from the web as we know it.

------
gambler
No links, no bookmarks, no standard UI conventions and components, no history,
no back and forward buttons that work consistently, no mental model of how it
all clicks together (page model), no accessibility, no search, no semantic
content, no pesky users controlling stuff. Sounds awesome, sign me up.

Sarcasm aside, we're moving in that direction already.

~~~
a1k0n
But this wouldn't even have, like, font rendering. Input methods. The amount
of stuff every single site would have to implement just to show something on
the screen is staggering, unless the API in question is no longer small and
simple and provably safe.

~~~
ezyang
You don't need to reimplement it, you just use whatever library you were using
before (but linked with the browser). The point is that the stack doesn't
change, just who provides it.

------
makmanalp
I think the internet is just trying to find the right abstraction level. And
with html5/css3/js/webgl and the newest generation of standards, we almost
found it.

We did used to download random binaries from the internet and run them. It
took too much effort to get up and running and there were compatibility issues
between systems, not to mention dependencies (java / c++ runtimes etc.), dll
hell, having to support myriad different OSes and OS versions. When it broke,
it broke badly and usually you had 0 chances of debugging, save sending a core
dump back over the internet, if the user let you.

Meanwhile, standards came and improved, and finally we realized that we
already had a UI toolkit that ran reasonably across all platforms, didn't
require any dependency installations, ran "programs" instantly without any
download and installation procedure. This alone is as large a marketing win as
it is a tech win. Remind you of something? It's the web we know and love
today. And you get logs when it breaks. And you can watch your users using it,
page by page and get stats. And the limited nature of the abstraction layer
means that if it breaks, it doesn't fail as catastrophically, there is less
chance of a big fat ugly core dump message, there is more of a chance you
almost instantly know. And the hard abstraction layer means that there is a
clearer understanding of security implications. Web apps, generally speaking,
can't access my files. Can Java applets or ActiveX components? A bit more
hazy. Can executables? Yeah. Can this proposed system? Maybe?

The modern web (browser and standards together) _is_ a universal VM and an SDK
rolled into one. It's the only one we have that works reasonably well enough
and strikes a decent balance between capability and ease of development.

The point of this person's system, which is the proposed freedom from browser
restrictions and incompatibilities, is a complete fallacy. Is Microsoft going
to recreate this new system for every system under the sun? No. People (and
companies like Apple, Google) will have to create their own, and thus
incompatibilities will prevail. Open standards are good. Established open
standards are better.

Many people tried to create alternatives, and failed miserably. It works.
Don't fuck with it.

~~~
unoti
> Many people tried to create alternatives, and failed miserably. It works.
> Don't fuck with it.

Although you made some insightful points here, I swear I'm not kidding when I
tell you that I've had people tell me almost the exact same thing about IBM's
3270 terminal protocol.

~~~
makmanalp
Okay, maybe it was some of that slow-brewing anger that made it to the end of
the post. What I don't want fucked with, rather, is a set of very open
standards, with competing implementations that already exist for a myriad of
different platforms. The standards used to come slow but are now evolving
faster than ever, and the implementations update themselves automatically
without user interference.

What is wrong with this picture? Really? Are you willing to trade all this
away, merely to get rid of the vestigial API cruft, which is mostly already
abstracted away by tons of nice tools (coffeescript? bootstrap? etc.)?

I honestly think that it's going to be hard to come up with a better platform
since that's a moving target: The web is evolving all the time and is ahead
the competition in many respects (see my parent post).

I want to cry when people want to toss this all away when we have it so good
right now. I dealt with the web when it was a complete mess. I am thankful for
what it is now and the direction it's rapidly moving in.

------
ezyang
This post received a lot more attention than I thought it would; if I had
known, I might have explained a few things more carefully. If you didn't
immediately dismiss it as stupid and found it at least a little thought-
provoking, I highly recommend checking out the technical report
[http://research.microsoft.com/pubs/173709/submitted-
nsdi13.p...](http://research.microsoft.com/pubs/173709/submitted-nsdi13.pdf)
(PDF), especially Figure 2 (which describes the entirety of the syscall
interface), Section 3 (which describes it) and Section 4 (which talks about
how to reimplement traditional browser user interface paradigms in this new
world.) It's all quite interesting, and at the very least, might say something
about how we should take mobile native apps forward.

~~~
Locke1689
It's very interesting, thank you for posting. One question I have is inspired
by some of the discussion about WebGL. You know as well as anyone that one of
the most obnoxious and pernicious side-effects is non-termination. This is bad
enough in the CPU, but when DoS-like attacks are perpetrated on the GPU
shaders or other I/O ports, we can create unfortunate lockups and non-
responsiveness. Have you heard of any academic work on this issue?

~~~
bzbarsky
As I understand, there is work on the hardware end going on to allow things
like running untrusted GL on only part of the graphics card's processing
units, as well as possible preemption of code on GPUs, precisely to deal with
these problems...

Sadly, I have no links, only hearsay.

------
othermaciej
Seems like a bad idea to me. How will my browser do things such as autofill
usernames and passwords, allow links to be opened in new tabs, block third-
parties from tracking me with cookies, or allow me to globally change my font
preferences if each web page actually uses a different "browser" that it
downloaded, and whose only connection to the outside is IP and a framebuffer?
Or how would a browser be able to give me crisper text on a Retina display
with no change to web pages, or provide hardware-accelerated threaded
scrolling, or let me play video with hardware-accelerated decoding?

(These are a few of the things that, as a browser engineer, I expect could not
be done in this model.)

Also as a Mac user, I expect this would result in many forms in web pages
giving me controls that look and act like Windows.

Against these likely disadvantages, the advantages seem slim. We already have
good ways to distribute sandboxed native apps. The Web doesn't need to become
one of them.

~~~
derleth
> How will my browser do things such as autofill usernames and passwords,
> allow links to be opened in new tabs, block third-parties from tracking me
> with cookies, or allow me to globally change my font preferences if each web
> page actually uses a different "browser" that it downloaded

"The only thing here that isn't a threat to our business model and/or Design
Vision is password autofill. We'll get right on solving that." -- The MBA
Voice in my head

------
javajosh
No, no no, a thousand times no. The problem with this scheme is that we lose
all that juicy parse-ability and addressability that make the internet so
useful and powerful.

Let's face it: the open web is a terrible environment to program in. It is
messy and arcane and difficult. But some of this difficulty is _not_ acidental
complexity. Some of it is the price we pay for writing apps who's outputs and
interfaces are themselves addressable, mutable, and usable.

If apps were to become big opaque blobs of binaries again, yes, they would be
easier to program. But is that good for us, or good for the world? What is the
long-term cost of making the web?

The promise of real, globally shared coding environments is only just starting
to get some legs with tools like jsfiddle revolutionizing the way we solve
programming problems together. I _can't_ really share Java code of any
complexity with people and be assured that they will be run in a suitable
context. The path to creating an environment, compiling and executing Java is
intense, and jsFiddle literally _eliminates all of that work for the people I
want to see my code_. Learning the quirks of the open web is a small price to
pay for that super-power.

And let me also say that there is still plenty of accidental complexity to
eliminate! In particular, servers have been doing far too much for far too
long, and once they start doing what they are good at and _only_ what they are
good at (which is partitioning the sum total of your information into discrete
URL-addressable resources) we will all breath a huge sigh of relieve, and
focus on the real problem. (Which is, of course, the monstrosity that is CSS).

------
iSnow
So instead of writing Javascript, we would build our own browsers to download
alongside the HTML? Or failing that would have to offer some prepackaged
browser.

And every device, from a smartphone to a 30" screen running on an octo-Xenon
would have to be able to execute the same native code.

And each vendor of a browser kit would try to establish their own web
standards to go with their home-grown engine.

I am pretty sure this is not the future of the web, and this seems like a
great thing.

And it's not like this is a completely novel idea. None of the proprietary
sandboxed browing environments of the past (Flash, Silverlight...) made
anything really easier. They sometimes enabled us to do things that were
impossible with HTML+JS, but they were all both a pain in the lower back for
developers and users and had glaring security holes.

~~~
lmm
Did silverlight have a history of security holes? It certainly looked like a
joy for developers, at least compared to javascript.

------
theevocater
So the internet should just be a simplified app store and hypervisor/VM?

I like the text based internet! The fact that I can go to a website, right
click and view source is the greatest part of the internet!

~~~
derleth
> The fact that I can go to a website, right click and view source

"What, and steal mah codez?! Damn you to hell!"

MBAs don't use precisely those words, but the spirit is the same.

------
zzzeek
This is called "sandboxing" and contrary to being a "radical departure from
the original Internet", the Java VM has been doing this in the applet engine
since the mid-90's. It's a complicated platform to work with, though some
applications do rely upon it, and it's the source of the most high profile
security holes found in the Java platform overall
(<https://www.google.com/search?q=java+sandbox+vulnerabilities>).

~~~
ezyang
The Java sandbox was actually really close to something that worked well. If
you look at the Java virtual machine, it's actually quite simple, and very
easy to ensure that nothing "bad" happens. Where Java lost the battle was in
the provisioning of APIs which, you know, actually let developers do things
like draw windows or load trusted code dynamically: here, it suddenly became
necessary to trust huge swaths of code to do the right thing, and the Java
sandbox got fucked. If you look at all of the sandbox vulnerabilities, they
are never "Oh, the JVM was implemented incorrectly" and always "Oh, some API
wasn't implemented properly." That's the key observation.

~~~
zzzeek
and browser.exe would make none of these mistakes because..... ?

~~~
ezyang
Because it's untrusted: it runs in the sandbox.

~~~
snatch_backside
That seems like a pretty elegant solution.

~~~
moe
Sandboxes all the way down. Cf. Chrome.

------
acuozzo
"Sorry, this website requires MMX. Go buy a new computer, kid."

This is the danger of writing a blog post before reading up on computer
history.

------
tedchs
Congratulations to the author on trying to re-invent either Java Applets or
ActiveX.

~~~
Smudge
Or, for practical purposes, Flash.

------
takeda64
I'm sorry, but the suggestion is plain retarded. The author probably is too
young and/or clueless to understand what kind of hell Internet was 15 years
ago.

If he wants to experience how it feels, he should just start build Flash based
websites.

~~~
maxdeliso
agreed. I was surprised at the number of responses to the contrary. this
'idea' is nothing new, nothing innovative, and has been proven to be a
terrible approach by history time and time again.

------
randallu
Isn't this already invented and called an iPad or Android? (Or more seriously,
this is called NaCL).

But you want to have OpenGL (with shader compiler security bugs you could
drive a truck through!). You want to read from cameras and disks, and post
notifications and go fullscreen and read/write audio samples and do all the
other unsafe things that browsers are currently implementing.

The syscall interface that's explored in the paper doesn't do any of those
things; software rendering only, etc.

The challenge in this work is exposing the advanced high-end functionality
(GL, media, window system, etc) in a way that's secure and can't be abused.
The challenge _isn't_ in defining a syscall interface that lets you run all-
software apps (NaCL has solved that problem, but so did the JVM and qemu...).
I feel like this paper completely ignores the real issues, and focuses on
problems that have been solved well enough or are already understood...

~~~
ezyang
Eratosthenes is basically NaCL taken to the logical extreme. NaCL itself
doesn't go far enough, because it still exposes the traditional browser APIs,
when really they should also be run in NaCL. They are fundamentally the same
approach, but applied with different amounts.

------
idle_processor
More room for vulnerabilities, less consistent user experience, and all the
other annoyances Flash and Java applets bring to the table. Sounds great.

------
mikeash
He says that a minimal environment is required:

"...all you need is a native execution environment, a minimal interface for
persistent state, an interface for external network communication and an
interface for drawing pixels on the screen..."

Compared to a modern browser, you've lost the ability to upload and download
files, the ability to open URLs in other apps (OAuth, anyone?), the ability to
play sound, the ability to use hardware acceleration for video or 3D
graphics....

He goes on to say: "This is an interface that is small enough that we would
have a hope of making sure that it is bug free." I'm guessing that once you
add all the extra stuff you need to reach feature-parity with current
browsers, you're going to reach bug-parity with them too.

~~~
lmm
Many people already suggest running your browser under a separate user account
or inside a virtual machine for security; this would effectively be a way to
automate that.

~~~
mikeash
Sure, but you might as well just automate it by shipping browsers that run
their code inside the proper sandbox, rather than reinventing the browser.

------
nico
I like the idea. I think something similar is already in place: there are JS
libraries (eg. jquery) which are required for a website to be rendered. If the
library is loaded from a central place (eg. google.com, or the creator of the
library), then it can be cached and it doesn't have to be downloaded every
time. In the same way, there could be different downloadable browsers, and you
could require one for your website.

As a developer, it would be amazing if I could make every user run the browser
I used to develop and test my website.

------
coliveira
Isn't this what Java was about? You were supposed to write code that would run
on any platform, and that code would download data from the web and display in
any way it wanted. The fact that it didn't work just shows that it is much
easier to create UIs that use a common set of standards, instead of creating
your own ad-hoc UI for every new web site.

~~~
ezyang
The difference is that Java doesn't let you use WebKit directly, whereas
native code lets you use both, if you so please.

------
michael_miller
The biggest problem with this is that it eliminates OS-specific facilities,
such as the clipboard, OS-style text selection, right click menus, window
styling, etc. Yes, these features could be reimplemented, but they are _very_
hard to get right, and near impossible if you are trying to match OS behavior
on many platforms.

This suggestion is fundamentally no different than exposing a <canvas> element
to a page, and saying "OK, implement your own rendering engine and draw
whatever you want in this box." Let's say you wanted to implement a modern
browser engine in the canvas, like WebKit. Well, you'd need a huge number of
OS specific hooks to get things like the ones I listed above. Do you expose
those via an OS API? Well, you just opened a huge number of vectors for an
attack. Do you replicate these hooks in your own code? Well, you just created
a crappy UX since you're never going to match the OS behavior 100%.

~~~
ezyang
The difference is that in canvas, you have to reimplement a rendering engine;
in native code, you just run WebKit. This is key!

Cross-website communication is certainly tricky, check out section 4 of the
technical report.

~~~
maxerickson
The comparison to the browser based web seems like a bad way to sell the idea.
Not managing a huge stack is a pretty nice feature, and the comparison invites
people to imagine managing the whole stack.

Why not just call it a sandboxed environment and delivery mechanism for
untrusted native code?

Then a browser implementation demonstrates how great the security model is and
how rich/capable the environment is.

------
sklivvz1971
Nothing to see here. Noob who hasn't really felt the pain of Flash or
Shockwave, reinvents it. Seems like HN is more and more full of people that
don't really have a clue... :-/

------
acuozzo
Web-apps (and the WWW browsers making them possible) were supposed to be the
solution to the portability problem. They're not and layering more crap on top
of them is not the solution either.

Leaving other (e.g., security) issues aside, this plan would make things far
worse. Would new processors be second-class citizens? Would WWW browsers have
to (incompatibly) transform themselves into emulators/VMs for the different
kinds of "native code" found on the Wild Wild Web?

Most importantly: Would this be the first step toward a closed/proprietary
WWW? "View Source" is still useful in this regard, despite the amount of
useless JavaScript obfuscation we're seeing today.

~~~
ezyang
New processors are already at a huge disadvantage; one problem is that it
takes a huge amount of engineering effort to match the performance of existing
processors, even if you do a lot better, another problem is, well, you
actually have to convince people to buy your shit when no one is actually
cross-compiling to it yet. It's not that big of a difference.

You're misunderstanding: the browsers _are_ the native code living on the WWW.

A platform like this would enable people to create proprietary websites, much
the same way people can implement systems like Steam as native applications.

~~~
bzbarsky
A question always worth asking: Had this system been implemented in 1995,
would we have ARM-based devices today? Why or why not?

Note that ARM never attempted to compete with x86 on performance, and indeed
still can't. That doesn't mean that it wasn't useful for other purposes.

So yes, new processors are at a huge disadvantage unless they bring something
to the table that none of the existing ones have. But the question is whether
you want to prevent a processor that _does_ bring something new from being
usable by making it impossible to use the web on it.

------
paulirish
It's disappointing that Microsoft Research is spending resources trying to
solve a problem that Microsoft's Internet Explorer is creating: a frustrating
cross-browser development process due to longstanding legacy clients.

------
wamatt
The point of our current ecosystem is that you can write a moderately portable
app, (HTML, CSS, JS) and it is able to run on an x86 OSX browser, or an ARM-
based Android phone etc

Either you going to write native machine code, in which case you lose
portability, or you going to be writing intermediary byte code. That approach
has been done before and failed as a ubiquitous open web standard eg the JVM
and the .net CLR.

Today's situation is messy, but it works. Every once in a while there is a
crazy idea that is actually pretty decent,... _'downloading /browser.exe'_ is
not one of them.

~~~
ezyang
x86 versus ARM is not a big deal at all; all you need to do is have cross-
compiling setup, which for any VM you care about is already well supported.
(Note that we are not recommending you start coding your web pages in
assembly; your stack should largely look the same in the old world order as it
does in the new world order.)

------
dredmorbius
What could possibly go wrong?

~~~
bitwize
I'm imagining Steve Summit -- the comp.lang.c FAQ maintainer, my former boss
and a security stickler -- saying this and loling.

------
cpeterso
I worked on Microsoft's Windows 2000 team back in the late 1990s. There was an
experimental project to sandbox native code using just NT's ACLs. Fortunately,
I don't think anything became of the project because it sounds like an
infinite game of Whac-a-Mole.

------
drumdance
Back in the day, this was the original promise of Java. Content would be
rendered inside of applets. ISTR a startup called Texture that tried to do
this. They provided pixel-level design tools, the result would compile to a
.java file

------
sadga
So, Native Client?

------
maxdeliso
>Howell knows how to do this

well why doesn't he explain how we safely present a system API to arbitrary
code?

the whole point of the browser is to provide a method for cross platform ui,
abstracting the display of an application from the underlying OS. if you were
to want to support more than one operating system you'd have to recompile your
binaries against all the system APIs that you wanted to support, sysV, winnt,
darwin, etc...

and if you were to present an abstraction which would transparently handle the
system API difference then you're looking at a JVM, which has been painfully
demonstrated to be extremely hard to prevent escalations for, time and time
again.

------
Aissen
This is crazy. So crazy and ambitious. Running a full software stack on a very
limited syscall set? You're basically re-defining an OS abstraction, much more
so than Firefox OS or Chrome OS. It's the logical continuation of android and
ios, at the browser level. So now your browser/OS is only comprised of $(curl
| exec -) ?

But there are so many problems to solve. Skimming through the paper shows OP
has thought of more problems than me, but there are so many more to solve(yet
unforeseen) before this could become even a bit usable. But if you succeed,
Microsoft should be worried (and kill your project).

------
mSoft
Hmmm, an article that seems to pine for the days of true client/server
applications...

Wait, what's this? <http://research.microsoft.com/en-us/people/howell/>

> microsoft.com

...oh.

~~~
cyrus_
> research.microsoft.com

MSR is a different beast from Microsoft itself.

~~~
camus
that's why there is microsoft in the domain name ?

------
foxylad
Yes, this might make securing your device easier. But more and more, what I
value is on the network - not my local hard drive. Be it a local network git
repository, my ISP's email system or my cloud based apps (including my bank's
internet portal).

So this hypothetical browser.exe with "only" network connectivity still needs
just good a security model as today's browser. And how do know the new
browser.exe I downloaded today doesn't have a poisoned security model that
allows it to sniff and send my internet banking credentials to the bad guys?

------
agumonkey
I think Alan Kay made a comment of the same kind about the current web.
Compared to an old tradition to embed an 'interpreter' ahead of any data.

------
klrr
So, does the web developer have to develop a browser for each platform then?
Do each web dev have to write their own image library etc.? Intresting idea,
but there have to be more effective ways of solving this problem.

------
ilaksh
.EXEs are for Windows.

How exactly is this supposed to work for clients on different platforms, like
32bit Windows, 64 bit OSX, linux, ARM, etc. etc.?? You

------
bdunbar
I can see this fixing some problems I've noticed with browser-based apps in
the enterprise.

It could also be the next IE6, lying in wait for an unwary developer.

------
camus
Dream on , there is and forever will be only one way , the js/html way.
Because it is a priviledge to execute one's code on a client machine , not a
right. And i want to know what code you are executing. So the future is
transparent programming. If you want more capabilites ask browser vendors more
APIs. Doesnt make html/js a great solution , both are just horrible and broken
, but that's what we have to work with.

~~~
eurleif
> And i want to know what code you are executing.

Have you ever actually tried to read JS code that's been through a minifier,
or worse, the Closure Compiler? It's not impossible, but neither is reading
disassembled machine code. Either way, you don't have anything close to the
original source code.

