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.
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.
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.
> A platform like this would enable people to create proprietary websites, much the same way people can implement systems like Steam as native applications.
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.
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.
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.
> 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.
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.
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.)
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).
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.
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.
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.
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... :-/
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%.
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.
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.
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 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.
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
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.
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.)
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.
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.
All those can be downloaded, scanned and read/played at my convenience.
Anything I can read/view in a "browser" connected to the internet can also be downlaoded and read/viewed in a native application, perhaps sandboxed in a virtual machine, and certainly not connected to the internet.
If, after reviewing the materials I've downloaded, I want to make a purchase or do some banking transaction, do I need a "browser"? No. I already know what I want to do. I have the request prepared. I just need a way to send my request and receive a confirmation. I need the transactionn to be secure. Like SSH.
I already do things this way to the extent possible.
Browsers are far too complex and try to do too many things. They are inherently insecure and clumsy. Yet they are essential to use for basic tasks like online banking.
I often wonder why banks don't get together and develop a _simple_, secure, open-source "browser" that does only one thing: process banking transactions. No marketing gimmicks. Business has these sort of no-nonsense standards and tools but not consumers. Instead, we have to use massive, complex, developer show-off software like "Firefox" or "Chrome" for the most simple things. Ugh. What a mess.
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...
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.
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.
90 comments
[ 2.9 ms ] story [ 166 ms ] threadI 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!
"What, and steal mah codez?! Damn you to hell!"
MBAs don't use precisely those words, but the spirit is the same.
Wait, what's this? http://research.microsoft.com/en-us/people/howell/
> microsoft.com
...oh.
MSR is a different beast from Microsoft itself.
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.
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.
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.
... and that is a __BadThing__.
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."
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.
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.
This is the danger of writing a blog post before reading up on computer history.
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.
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.
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.
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.)
Sarcasm aside, we're moving in that direction already.
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%.
Cross-website communication is certainly tricky, check out section 4 of the technical report.
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.
If he wants to experience how it feels, he should just start build Flash based websites.
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.
It could also be the next IE6, lying in wait for an unwary developer.
What am I "browsing"? Text? Images? Audio? Video?
All those can be downloaded, scanned and read/played at my convenience.
Anything I can read/view in a "browser" connected to the internet can also be downlaoded and read/viewed in a native application, perhaps sandboxed in a virtual machine, and certainly not connected to the internet.
If, after reviewing the materials I've downloaded, I want to make a purchase or do some banking transaction, do I need a "browser"? No. I already know what I want to do. I have the request prepared. I just need a way to send my request and receive a confirmation. I need the transactionn to be secure. Like SSH.
I already do things this way to the extent possible.
Browsers are far too complex and try to do too many things. They are inherently insecure and clumsy. Yet they are essential to use for basic tasks like online banking.
I often wonder why banks don't get together and develop a _simple_, secure, open-source "browser" that does only one thing: process banking transactions. No marketing gimmicks. Business has these sort of no-nonsense standards and tools but not consumers. Instead, we have to use massive, complex, developer show-off software like "Firefox" or "Chrome" for the most simple things. Ugh. What a mess.
Sadly, I have no links, only hearsay.
As a developer, it would be amazing if I could make every user run the browser I used to develop and test my website.