Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla’s Rejection of NativeClient Hurts the Open Web

chadaustin.me

Post reply on HN
Print view View original

81–90 of 106 posts

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#81

Post by JoachimSchipper »

chc wrote: post #73
JoachimSchipper wrote: post #18

Considering NaCl in the context of papers like http://eprint.iacr.org/2010/594 (timing the CPU cache to break AES) is... interesting. You'd hope that Google would have considered such issues, but a quick search doesn't yield anything.

Are you saying that AES in JavaScript is more secure?

In the sense that Javascript crypto is horribly broken (see e.g. http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...) but can't really be used to attack other applications running on your computer, yes. NaCl itself is probably fine-ish for implementing crypto protocols - it's just that it looks like a perfect vehicle for attacking other crypto implementations running on the same processor. (Well, except for the noise from running Chrome, but I still wouldn't use an SSH session while running NaCl.)

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#82

Post by chc »

rbanffy wrote: post #80
chc wrote: post #70

Earlier quoted context omitted.

It solves the only problem you brought up in the comment he was responding to, AFAIK. If you meant to point to others, I think you need to be more explicit or people will miss them.

So, you would be happy if a banner served through Facebook could push a obfuscated (good guys may well play by the rules, but bad guys will figure out in no time how to circumvent anything LLVM-BC brings to the table) binary blob to be executed in your browser? How much would you trust the LLVM-based sandbox? Well... I wouldn't. In fact, I can't understand why taking more or less the same shortcut to a dead-end Java…

How much would you trust the JavaScript-based sandbox?

I don't see why you'd be more afraid of the blob because it's binary rather than obfuscated plaintext. I mean, heck, they could compile the LLVM bytecode to the exact same JavaScript bytecode they're currently using. If you're not afraid of JavaScript, I don't understand the objection you're raising here.

That's what I'm getting at here. Executing remotely downloaded code is scary, but we already do that.

And the problem with Java was that it had terrible performance. The idea of NaCL is that it will actually perform better than what we have now.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#83

Post by papertiger »

ant57 wrote: post #55
papertiger wrote: post #53

Earlier quoted context omitted.

HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty. Cappuccino http://cappuccino.org/ SproutCore http://www.sproutcore.com/ Ext JS http://www.sencha.com/products/js/

I don't want to dismiss these out-of-hand, but they're really not a replacement for a modern application development framework. Beyond functionality (of which these can and do provide considerably less), part of what makes a platform like Cocoa/UIKit so valuable -- it is used by every application on the device . The applications will interoperate both with each other and with the OS (background services/tasks, quickl…

I have seen many apps (on all platforms -- iPhone, Android, OS X, Windows, etc.) that deviate from user expectations. Ultimately, meeting user expectations is the responsibility of the developer not the framework.

HTML has its own set of visual cues that you and millions of others easily interact with every single day. I would argue that the interaction model of HTML/JS apps may be as familiar or more familiar to users.

I don't disagree that HTML/JS apps can be difficult to develop, but I do not think they are going to "lose". (I don't think they are going to win either. It's not a win/lose situation.)

Since it seems that your background is in native applications, I just wanted to provide you with some references to frameworks that provide something a little more advanced than jQuery and interactive documents.

Obviously, each team needs to look at its project and goals and choose whether a native app, an HTML/JS app, or both is appropriate.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#84

Post by rbanffy »

chc wrote: post #82
rbanffy wrote: post #80

Earlier quoted context omitted.

So, you would be happy if a banner served through Facebook could push a obfuscated (good guys may well play by the rules, but bad guys will figure out in no time how to circumvent anything LLVM-BC brings to the table) binary blob to be executed in your browser? How much would you trust the LLVM-based sandbox? Well... I wouldn't. In fact, I can't understand why taking more or less the same shortcut to a dead-end Java…

How much would you trust the JavaScript-based sandbox? I don't see why you'd be more afraid of the blob because it's binary rather than obfuscated plaintext. I mean, heck, they could compile the LLVM bytecode to the exact same JavaScript bytecode they're currently using . If you're not afraid of JavaScript, I don't understand the objection you're raising here. That's what I'm getting at here. Executing remotely downl…

> And the problem with Java was that it had terrible performance.

It had, indeed, terrible performance in 1996.

> The idea of NaCL is that it will actually perform better than what we have now.

Again, I see no reason why an improved JavaScript language/runtime would not perform as well as this LLVM-based solution, with the added benefit of building upon 15 years of knowledge on how to secure (and not to secure) a JavaScript-based sandbox. This is a whole new can of worms we don't have to open. We have something that mostly works, that has been battle-tested for more than a decade, and instead of improving on it, some (very clever) people are pushing a whole new stack. Convince me this is the sane solution.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#85

Post by pornel »

chc wrote: post #67
trotsky wrote: post #59

Let's ignore the philosophical or design issues surrounding native client and look at a practical one. Why does the article take issue with Mozilla alone? Surely they aren't the only browser vendor that won't be implementing native client. Mozilla is being singled out here precisely because other major platforms are considered to be lost causes. Safari and Internet Explorer are unlikely to support NaCl for obvious co…

Once Mozilla and Google support it, that puts a lot of pressure on the others. It might still not have happened, but Mozilla was the swing vote.

That doesn't guarantee success. Google's + Mozilla's pressure in video codecs hasn't changed Microsoft's and Apple's mind.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#86

Post by Dn_Ab »

chc wrote: post #69
Dn_Ab wrote: post #45

And so the pendulum has swung back. I believe Mozilla's action is rational assuming my logic is not flawed. See if you can unravel it. Premise: The more indistinguishable a browser gets from its underlying operating system the more of the properties of said system it must share. Thus stretching the nature of the abstraction, making it shallower (till the machine) hence also increasing the probability of leaks in said…

It's not clear from your comment that you have a good understanding of what Native Client is. You're making vague, barely technical objections to the browser getting "more indistinguishable … from its underlying operating system" and losing the minuscule amount of cross-platform capability it has now without explaining how a more open and potentially efficient platform for code execution than "Whatever text-based Jav…

My comment was an argument as to why Mozilla's choice not to introduce this dependency was not a bad one - there is no technical reason why the fast execution multiple language advantages of NaCl cannot be architected into a javascript vm. and why mozilla's path does more to keep things open longer by using an already widely adopted, more understood technology. The enemy you know is better than the enemy you don't know type thing. Who knows what can of warms the concepts sandboxing relies on will contain. It must contains flaws as all creations of humans do.

And then my opinion that browsers will evolve into the platform and not be separable from the OS. Stuff like NaCl simply accelerates that by introducing a dependency on one company or creating a technology that invites splintering on implementation due to its complexity and uniqueness.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#87

Post by Dn_Ab »

chc wrote: post #72
EGreg wrote: post #63

Earlier quoted context omitted.

Because ECMAScript turned out to be pretty awesome, and is now the de facto standard on the web. If you don't like Javascript, your best alternative right now is to make a language that compiles into it. Take whatever "nice" features you want. Here was my crack at it: http://news.ycombinator.com/item?id=2044752

Creating a language that compiles to JavaScript without essentially being an alternative syntax for JavaScript or being agonizingly slow is surprisingly difficult. I'm not aware of a single one. Do you know of any? Your "language that compiles into it" falls into the former category.

Off the top of my head I know of haXe, York Haskell Compiler. And WebSharper on F# allows you to do some cool stuff.

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#88

Post by salmonsnide »

EGreg wrote: post #68

Think of it this way: Flash, Java, Javacript, et al are great for the web because they are "write once, run anywhere". The same source code runs everywhere. That is what the web is all about. HTML and CSS are not scripting languages and they are also "write once, run anywhere". That is how the web delivers your programs. Now, what will your Native Client do? It will have COMPILED code for ONE platform. Like in C++ wh…

Did you miss the PNaCl part? Check it out here: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#89

Post by dchest »

1337p337 wrote: post #79
dchest wrote: post #77

Earlier quoted context omitted.

Lua VM is not faster than JVM or V8; you might be thinking about LuaJIT, which is not as portable as the standard Lua implementation and uses different bytecode format.

I don't know which Lua you're used to, but as of 5.1, it's incredibly fast; I may be benchmarking the wrong things (the big one I tried was finding the first 2,000,000 primes by trial division, which should lend itself well to hotspot optimizations). Either way, though, I'd still argue that a VM (JVM and Lua were just a couple of examples of VMs that are fast, used in real applications, and are readily jailable) is t…

I'm referring to these benchmarks: http://shootout.alioth.debian.org/u32/which-programming-lang...

Re: Mozilla’s Rejection of NativeClient Hurts the Open Web

#90

Post by azakai »

stcredzero wrote: post #74
mahmud wrote: post #16

Completely disagree. I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android. NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't ha…

NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS. There's no reason why NaCl should be inherently limited to x86. x86 is currently the biggest platform, but there's no reason why NaCL couldn't switch to a "Universal" payload like OS X has, combining the 2 largest ISA. (x86 and arm?) EDIT: I've since read that NaCl is working on LLVM, which would be even better.

1. LLVM is not portable. PNaCl is trying to make it so, but it's a work in progress.

2. A 'universal' payload with ARM and x86, would just work on them. What if in 5 years we have new architectures? Only supporting ARM and x86 would hold back innovation there.

Post reply on HN