GET /browser.exe(blog.ezyang.com)
blog.ezyang.com
GET /browser.exe
http://blog.ezyang.com/2012/10/get-browser-exe/
37 comments
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?
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?
The requirement that one have an "illustrious" GitHub account is one of the more surreal ad hominems I've seen.
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.
cynicalkane didn't say that you said that ezyang was incompetent.
> Looking at your GitHub your resume is nowhere near as illustrious.
> Looking at your GitHub your resume is nowhere near as illustrious.
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?
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.
Nota bene: I actually agree with you.
In hindsight my phrasing came across as very insulting and if I could edit it now, I would. Please note that the intent was merely to snarkily question his domain knowledge regarding Web development, and not to assert he was clearly an incompetent.
I also fully admit that as an undergraduate student, I am nowhere near as impressive as the Stanford PhD student (though you could have chosen a more fair comparison than between a copy-edited resume and a skimming of my "GitHub resume"). I do humbly submit that MathQuill is more substantive than any JavaScript project you or Edward Yang has ever created (or than your or his contributions to any JavaScript project).
I also fully admit that as an undergraduate student, I am nowhere near as impressive as the Stanford PhD student (though you could have chosen a more fair comparison than between a copy-edited resume and a skimming of my "GitHub resume"). I do humbly submit that MathQuill is more substantive than any JavaScript project you or Edward Yang has ever created (or than your or his contributions to any JavaScript project).
However, he only graduated from undergrad this past year—so while he is a Stanford Ph.D. student, he's only been one for about a few weeks.
Lazy terminology is better known as "inaccurate communication" or simply "bad writing." Ironically enough, writing good English (or whatever language one uses) is just as important, if not more so, than writing good code when it comes to building software.
“Words, they mean things!” I’ve historically been pretty bad about using the right words for things, and I’ve had colleagues chew me out repeatedly for it. But in this case, I think the intended meaning is pretty unambiguous.
First off, if you were offended, that bad writing on my part, and I apologize. If I could edit it now, I would.
The meaning was indeed unambiguous, what I intended to say was that your choice of words damaged your credibility a wee bit. Happens to me all the time, I can see now that you just wrote a quick blog post to promote a paper a friend wrote that you found thought-provoking. No judgement.
In replies to other comments, you seem to have quite clearly addressed the concern that the proposal is essentially the Java VM all over again, countering that this proposal has a better ABI that will make all the difference (is my understanding correct?). Nowhere have I seen you address my concern that this, not just violates, but completely and utterly rejects a core design principle of the current Web that is arguably partly responsible for its success (certainly Tim Berners-Lee, the creator and essentially BDFL of the Web, argues for it).
In fact, this concern occurred to you: "I can’t use Adblock or Greasemonkey anymore (that would involve injecting code into arbitrary executables), and it’s much harder for me to take websites and use them in ways their owners didn’t originally expect. (Would search engines exist in the same form in this new world order?)" However, it looks like you didn't really think that thought through, and had never heard of the Principle of Least Power.
Again, I don't claim to fully agree with it. However, I can't deny that the Web is incredibly successful, and if I were to assert the creator of such a successful technology was completely wrong about one of the fundamental design principles that they espouse was critical to their technologies' success, I'd have some damn good arguments why.
A charismatic professor of mine, Scott Shenker, has a quote by Don Norman he likes a lot: "Academics get paid for being clever, not for being right." This, Shenker says, is why a physicist invented the Web, not a computer scientist.
I don't know. But it's hard to argue with success.
The meaning was indeed unambiguous, what I intended to say was that your choice of words damaged your credibility a wee bit. Happens to me all the time, I can see now that you just wrote a quick blog post to promote a paper a friend wrote that you found thought-provoking. No judgement.
In replies to other comments, you seem to have quite clearly addressed the concern that the proposal is essentially the Java VM all over again, countering that this proposal has a better ABI that will make all the difference (is my understanding correct?). Nowhere have I seen you address my concern that this, not just violates, but completely and utterly rejects a core design principle of the current Web that is arguably partly responsible for its success (certainly Tim Berners-Lee, the creator and essentially BDFL of the Web, argues for it).
In fact, this concern occurred to you: "I can’t use Adblock or Greasemonkey anymore (that would involve injecting code into arbitrary executables), and it’s much harder for me to take websites and use them in ways their owners didn’t originally expect. (Would search engines exist in the same form in this new world order?)" However, it looks like you didn't really think that thought through, and had never heard of the Principle of Least Power.
Again, I don't claim to fully agree with it. However, I can't deny that the Web is incredibly successful, and if I were to assert the creator of such a successful technology was completely wrong about one of the fundamental design principles that they espouse was critical to their technologies' success, I'd have some damn good arguments why.
A charismatic professor of mine, Scott Shenker, has a quote by Don Norman he likes a lot: "Academics get paid for being clever, not for being right." This, Shenker says, is why a physicist invented the Web, not a computer scientist.
I don't know. But it's hard to argue with success.
> 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:
People have been fighting against this since the Web first hit the mainstream circa fifteen years ago now. First it was tables and single-pixel transparent GIFs, then it was a whole lot of Flash and Java and a few sites done pretty much entirely as JPEGs, then those people got their hands on CSS and Javascript, which is pretty much where we are now.
That got us quirks mode, tag soup, and "This website is best viewed with". OTOH, the semantic web never caught on, either, and a lot of great proposals surrounding microformats died due to nobody caring about them.
It's almost a law, really: The Web is never, and will never be, precisely what you want it to be. However, it will likely be good enough.
People have been fighting against this since the Web first hit the mainstream circa fifteen years ago now. First it was tables and single-pixel transparent GIFs, then it was a whole lot of Flash and Java and a few sites done pretty much entirely as JPEGs, then those people got their hands on CSS and Javascript, which is pretty much where we are now.
That got us quirks mode, tag soup, and "This website is best viewed with". OTOH, the semantic web never caught on, either, and a lot of great proposals surrounding microformats died due to nobody caring about them.
It's almost a law, really: The Web is never, and will never be, precisely what you want it to be. However, it will likely be good enough.
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... "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."
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."
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.
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.
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.
Sarcasm aside, we're moving in that direction already.
Yes! How I longed for the days where scraping would be impossible, locking us out of many innovative interfaces and mashups (or even just archiving pages, like e.g. Pinboard does). Where Reddit's Enhancement Suite or the many Hacker News bookmarklets and greasemonkey scripts would be impossible. Where I can't just copy a piece of HTML to my clipboard, just dumb images.
I recommend checking out Section 4 of the linked technical report, which discusses how to recover traditional interface elements of the traditional web.
Wow, an entire other myriad of issues I wasn't even thinking about while commenting. Great points! Funnily enough, you can see some of this in mobile apps already, but it's gotten a lot better over the last 5 years. No search really bugs the crap out of me. It's impossible to naturally discover an app through search. Also, It's like mobile apps are all their own individual walled gardens and interplay is impossible. Links anyone? All this was invented years ago and seems like a step back.
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.
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.
The next step in the sequence is to get rid of interactivity. We have then reached television.
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.
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.
> 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.
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.
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.
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.
Sure, the web has given us an awesome UI toolkit. Ship that to your users.
You're conflating a lot of issues in this post, many of which are orthogonal to Howell's idea, which is making it difficult for us to talk about the core technical idea (which is certainly not perfect, but you're focusing on the wrong things.)
You're conflating a lot of issues in this post, many of which are orthogonal to Howell's idea, which is making it difficult for us to talk about the core technical idea (which is certainly not perfect, but you're focusing on the wrong things.)
Yeah, but Howell's ideas are pretty much orthogonal to the web. A program that allows a number of virtual machines to cooperate in providing an interface to the user isn't an uninteresting idea, but it solves almost none of the problems the web solves (things like, standards for transmitting, displaying, and interacting with hypermedia).
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... (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.
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?
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.
Sadly, I have no links, only hearsay.
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.
(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.
> 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
"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
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).
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).
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.
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.
Did silverlight have a history of security holes? It certainly looked like a joy for developers, at least compared to javascript.
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!
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!
> 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.
"What, and steal mah codez?! Damn you to hell!"
MBAs don't use precisely those words, but the spirit is the same.
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).
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.
The other place Java lost the battle was in sticking to a closed, vendor-dictated implementation, that's slowly getting pulled into the massive hole of suck that is Oracle.
and browser.exe would make none of these mistakes because..... ?
Because it's untrusted: it runs in the sandbox.
There seems to be an empirical law: You can't sandbox code securely :)
True, for the same reason that you don't see (m)any programs based on purely functional programming paradigms. Things with no side effects, no vulnerabilities, and no coupling to the outside world tend not to be very useful.
Pure functional programming does not mean there are no effects. The name "pure functional" is a misnomer, in my opinion. It just means "typed effects" -- keeping track of what effects pieces of code have.
"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.
This is the danger of writing a blog post before reading up on computer history.
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.
If he wants to experience how it feels, he should just start build Flash based websites.
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.
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...
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...
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.
More room for vulnerabilities, less consistent user experience, and all the other annoyances Flash and Java applets bring to the table. Sounds great.
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.
"...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.
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.
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.
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.
As a developer, it would be amazing if I could make every user run the browser I used to develop and test my website.
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.
The difference is that Java doesn't let you use WebKit directly, whereas native code lets you use both, if you so please.
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%.
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%.
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.
Cross-website communication is certainly tricky, check out section 4 of the technical report.
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.
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.
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... :-/
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.
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.
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.
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.
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.
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.
> A platform like this would enable people to create proprietary websites, much the same way people can implement systems like Steam as native applications.
... and that is a __BadThing__.
... and that is a __BadThing__.
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.
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.
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.
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.)
What could possibly go wrong?
I'm imagining Steve Summit -- the comp.lang.c FAQ maintainer, my former boss and a security stickler -- saying this and loling.
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.
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
So, Native Client?
>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.
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.
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).
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).
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.
Wait, what's this? http://research.microsoft.com/en-us/people/howell/
> microsoft.com
...oh.
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?
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?
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.
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.
.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
How exactly is this supposed to work for clients on different platforms, like 32bit Windows, 64 bit OSX, linux, ARM, etc. etc.?? You
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.
It could also be the next IE6, lying in wait for an unwary developer.
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.
> 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.
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.
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.)