Technically I hate the glued together, shit-stack that is the organically evolved web. One part of me thinks we have devolved from the Big Iron/VMS days.
"Are we at any point in the near future going to have fully transparent hardware? No we are not."
Open hardware isn't cost effective, and economically and politically probably is repressed. There's darn few viable projects that I can find on the internet and a few underground systems that are borderline crackpot. There might be a better market for these systems today than there was a year ago. There seems to be a growing mistrust in commercial software, but there is no substitute for commercial hardware.
"We're going to have to get over the NSA stuff, at least for the most part."
I have to go to the office tomorrow and pretend that I work on secure systems for sensitive data. :)
I've seen many people express their dislike for the status quo, however I haven't seen any real arguments for how things could be better.
In terms of UI at least I've worked with Delphi, I've worked with Visual Basic, I've worked with Java's Swing and with WxWidgets and with Android - all of the available UI toolkits, except HTML, make it easy to build stuff with standard widgets. However, if you diverge from that path, pain ensues and I haven't encountered something more dynamic or malleable to experimentation than working with HTML/CSS. There's also nothing stopping you from implementing frameworks of standard widgets on top of the browser's DOM and Javascript. And btw, even Android or iOS developers that are quite happy with their native platform, are sometimes embedding WebViews in their app for cases in which they've got something complicated to do.
In terms of Javascript, there are already compilers and frameworks that use Javascript as a target, with things like Google's GWT giving you everything a Java developer dreams about (code reuse, some static type safety, etc...), yet Javascript is still more popular by an order of magnitude than all alternatives combined. And if you haven't seen the Unreal Engine demonstrating asm.js in Firefox, you should.
In terms of security, the biggest attack vectors on the web right now are old browser versions and various browser plugins that are still around, like Java (most PCs have a version of the Java plugin installed with known vulnerabilities) or Adobe Reader or other crappy plugins with a broken update cycle. With Chrome and Firefox auto-updated regularly, Javascript is actually quite secure and there's nothing in it that prevents you from sandboxing its execution.
Many people complain about the state of the web, however given the constraints that the web faces (open standards, multi-platform in every sense, multiple independent implementations from Microsoft, Apple, Google, Mozilla, Opera, etc...) I have a hard time believing on how things could be better. In fact, given the history of the web, especially given Microsoft that has held the web back for a couple of years simply because they could, the web turned out to be awesome.
Adding something like MXML rendering to web browsers, without changing anything else (I'm not going to go into the JavaScript discussion), would already be a huge improvement in developing proper web _application_ UIs.
Imagine if in the 90s MS had written Outlook, Excel etc in VBA and you ran them inside Word as macros. They would have been laughed out of the market, but that is is exactly what modern app developers do, shoehorning everything into a web page inside a browser.
The comparison to Word is completely invalid, because Word is itself one of the applications, while the browser isn't a webapp.
SGX really exists for one reason, and one reason only-- it's another attempt to implement some kind of un-bypassable DRM. Joanna points this out in her writeup. All of the other so-called advantages you can already get simply by running a VM.
Get ready to jailbreak your PC I guess. I can just feel the security oozing from my pores.
How well sandboxed is nginx? Answer: not at all.
Also, you understand that any VM system that grants the security capability you're talking about also grants content software the ability to protect content, right? They're two sides of the exact same coin. You don't see that they are, because the "security" sign of the coin implicitly but subtly presupposes hostile code is running on the machine already, where the "DRM" side of the coin obviously hosts adversarial code, because that adversarial code is the "protagonist" of its story.
How well sandboxed is nginx? Answer: not at all. Actually, that's not the answer. ngnix is sandboxed by using selinux, using a chroot jail, using AppArmor, or any one of a number of different ways.
How many years have gone by without a Java or web-based exploit being announced? 0. Maybe you should not throw stones, when your own house is made of glass.
Security and DRM are not two sides of the same coin. There are lots of insecure systems that aren't DRMed. And there are lots of ultra-secure OSes, like OpenBSD, that don't include DRM.
I'm not a tinfoil-hat type of person, but I have a healthy fear of code written by firmware engineers. That's why things like EFI and now this are terrible. They're basically shovelware that you can't get rid of on your PC. Like the uninstallable android apps, but 100x worse.
Only when you trust the hardware, and hypervisor. There's a huge potential set of advantages here for cloud platforms where people running various VMs do not trust the other tenants, and might not want to have to fully trust the hosting provider.
The possibility of having everything encrypted in memory and encrypted on disk, and with other code running on the same CPU unable to peek at what you're computing might not be foolproof (e.g. you'd have to trust that the provider does not run a CPU that's somehow backdoored), but it would still be a substantial improvement compared to what we have now. It means that a large class of security flaws in the hypervisors would still be unable to expose client VMs, for example.
I do agree with you that un-bypassable DRM is probably part of the motivation, but there are plenty of other uses.
Today, in 2013, a trivial software bug is all it takes to allow the author of a web page to upload and run code in your browser process. That is a consequence of the architecture we run on.
Are we at any point in the near future going to have fully transparent hardware? No we are not.
Do we badly need architectural improvements for hosting trustworthy code on general purpose hardware? Yes we certainly do.
We're going to have to get over the NSA stuff, at least for the most part. Perhaps there are applications that will need some kind of assurance that they aren't generating secrets from RDRAND (I'm not a believer in that problem, but I'm not committed to the argument). But for the most part, we're going to have to trust hardware vendors to design better security architectures and deploy them in new chipsets and processors, because they are badly needed.
If it helps you, think of your resistance to things like SGX as the product of an NSA psy-ops campaign to get you to distrust technologies that will cut off NSA's supply of new software bugs.