8 ms·

GET /browser.exe

139 points by mikexstudios 14y ago

foxylad 14y ago
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?
javajosh 14y ago
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).
theevocater 14y ago
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 14y ago
  > 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.
tedchs 14y ago
Congratulations to the author on trying to re-invent either Java Applets or ActiveX.
- Smudge 14y ago
  Or, for practical purposes, Flash.
dredmorbius 14y ago
What could possibly go wrong?
- bitwize 14y ago
  I'm imagining Steve Summit -- the comp.lang.c FAQ maintainer, my former boss and a security stickler -- saying this and loling.
mSoft 14y ago
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/ http://research.microsoft.com/en-us/people/howell/ > microsoft.com ...oh.
- cyrus_ 14y ago
  > research.microsoft.com MSR is a different beast from Microsoft itself.
  - camus 14y ago
    that's why there is microsoft in the domain name ?
idle_processor 14y ago
More room for vulnerabilities, less consistent user experience, and all the other annoyances Flash and Java applets bring to the table. Sounds great.
acuozzo 14y ago
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 14y ago
  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 14y ago
    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.
  - acuozzo 14y ago
    > 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__.
sp332 14y ago
I like this idea! It reminds me of this page http://mozilla.github.com/pdf.js/web/viewer.html 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-with-alan-kay/240003442?pgno=2 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."
- evv 14y ago
  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.
agumonkey 14y ago
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.
sadga 14y ago
So, Native Client?
iSnow 14y ago
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 14y ago
  Did silverlight have a history of security holes? It certainly looked like a joy for developers, at least compared to javascript.
acuozzo 14y ago
"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.
makmanalp 14y ago
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 14y ago
  > 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.
gambler 14y ago
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.
- makmanalp 14y ago
  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.
- a1k0n 14y ago
  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 14y ago
    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.
- infinity 14y ago
  The next step in the sequence is to get rid of interactivity. We have then reached television.
- icebraining 14y ago
  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.
sklivvz1971 14y ago
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... :-/
michael_miller 14y ago
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 14y ago
  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 14y ago
    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.
takeda64 14y ago
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 14y ago
  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.
coliveira 14y ago
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 14y ago
  The difference is that Java doesn't let you use WebKit directly, whereas native code lets you use both, if you so please.
drumdance 14y ago
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
wamatt 14y ago
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 14y ago
  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.)
bdunbar 14y ago
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.
zzzeek 14y ago
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 https://www.google.com/search?q=java+sandbox+vulnerabilities).
- ezyang 14y ago
  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 14y ago
    and browser.exe would make none of these mistakes because..... ?
    - ezyang 14y ago
      Because it's untrusted: it runs in the sandbox.
      - snatch_backside 14y ago
        That seems like a pretty elegant solution.
        moe 14y ago
        Sandboxes all the way down. Cf. Chrome.
ramboler 14y ago
I really do not need a browser. 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.
ezyang 14y ago
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.pdf 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.
- Locke1689 14y ago
  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 14y ago
    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.
nico 14y ago
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.
cpeterso 14y ago
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.
mikeash 14y ago
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 14y ago
  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 14y ago
    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.
randallu 14y ago
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 14y ago
  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.
laughinghan 14y ago
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 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 14y ago
  Edward Yang is very much aware of the difference between www and TCP/IP. http://ezyang.com/ezyang-resume.pdf 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?
  - lucian303 14y ago
    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.
    - ezyang 14y ago
      “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.
camus 14y ago
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 14y ago
  > 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.
paulirish 14y ago
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.
maxdeliso 14y ago
>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.
othermaciej 14y ago
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 14y ago
  > 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
ilaksh 14y ago
.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
klrr 14y ago
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.
Aissen 14y ago
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).

139 points by mikexstudios 14y ago

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?

javajosh 14y ago

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).

theevocater 14y ago

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 14y ago
> 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.

tedchs 14y ago

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

Smudge 14y ago
Or, for practical purposes, Flash.

dredmorbius 14y ago

What could possibly go wrong?

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

mSoft 14y ago

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/ http://research.microsoft.com/en-us/people/howell/ > microsoft.com ...oh.

cyrus_ 14y ago
> research.microsoft.com MSR is a different beast from Microsoft itself.
- camus 14y ago
  that's why there is microsoft in the domain name ?

idle_processor 14y ago

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

acuozzo 14y ago

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 14y ago
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 14y ago
  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.
- acuozzo 14y ago
  > 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__.

sp332 14y ago

I like this idea! It reminds me of this page http://mozilla.github.com/pdf.js/web/viewer.html 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-with-alan-kay/240003442?pgno=2 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."

evv 14y ago
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.

agumonkey 14y ago

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.

sadga 14y ago

So, Native Client?

iSnow 14y ago

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 14y ago
Did silverlight have a history of security holes? It certainly looked like a joy for developers, at least compared to javascript.

acuozzo 14y ago

"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.

makmanalp 14y ago

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 14y ago
> 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.

gambler 14y ago

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.

makmanalp 14y ago
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.
a1k0n 14y ago
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 14y ago
  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.
infinity 14y ago
The next step in the sequence is to get rid of interactivity. We have then reached television.
icebraining 14y ago
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.

sklivvz1971 14y ago

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... :-/

michael_miller 14y ago

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 14y ago
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 14y ago
  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.

takeda64 14y ago

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 14y ago
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.

coliveira 14y ago

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 14y ago
The difference is that Java doesn't let you use WebKit directly, whereas native code lets you use both, if you so please.

drumdance 14y ago

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

wamatt 14y ago

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 14y ago
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.)

bdunbar 14y ago

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.

zzzeek 14y ago

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 https://www.google.com/search?q=java+sandbox+vulnerabilities).

ezyang 14y ago
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 14y ago
  and browser.exe would make none of these mistakes because..... ?
  - ezyang 14y ago
    Because it's untrusted: it runs in the sandbox.
    - snatch_backside 14y ago
      That seems like a pretty elegant solution.
      - moe 14y ago
        Sandboxes all the way down. Cf. Chrome.

ramboler 14y ago

I really do not need a browser. 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.

ezyang 14y ago

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.pdf 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.

Locke1689 14y ago
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 14y ago
  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.

nico 14y ago

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.

cpeterso 14y ago

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.

mikeash 14y ago

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 14y ago
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 14y ago
  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.

randallu 14y ago

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 14y ago
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.

laughinghan 14y ago

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 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 14y ago
Edward Yang is very much aware of the difference between www and TCP/IP. http://ezyang.com/ezyang-resume.pdf 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?
- lucian303 14y ago
  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.
  - ezyang 14y ago
    “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.

camus 14y ago

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 14y ago
> 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.

paulirish 14y ago

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.

maxdeliso 14y ago

>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.

othermaciej 14y ago

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 14y ago
> 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

ilaksh 14y ago

.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

klrr 14y ago

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.

Aissen 14y ago

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).