Expert to Expert: Helen Wang and Alex Moshchuk - Inside Gazelle | Going Deep

pdev

Interesting topic and good video. If you liked it, you might want to also check docs on google chrome:

http://dev.chromium.org/developers/design-documents/process-models
http://dev.chromium.org/developers/design-documents/multi-process-architecture
http://dev.chromium.org/developers/design-documents

Charles
Welcome Change

In reply to pdev

#Apr 7th @ 11:48 AM

Helen talks about the Chrome design in this interview and she briefly points out the flaws (or differences) when compared to the more locked down kernel principal management approach... Of course, Chrome's isolated processes is a solid architecture for today's browser, but certainly not the end of browser security innovation...... IE incorporates tabbed processes as well. Gazelle leaps ahead of all current browsers with the principal approach because there is no dependable way to execute code in the Gazelle kernel (so there can be no process hijacking or remote code execution on the host machine - code only runs in the context of a principal and this can include more than one process in context -). At least this is the theory, anyway, and Gazelle is a research project, not a product... Still, when you think of the state of the art in web browser security technology today (I don't care which browser you talk about...), there's a very long way to go until we reach somewhere close to browser security nirvana....

C

pdev

In reply to Charles

#Apr 7th @ 1:03 PM

"Gazelle leaps ahead of all current browsers with the principal approach because there is no dependable way to execute code in the Gazelle kernel (so there can be no process hijacking or remote code execution on the host machine - code only runs in the context of a principal and this can include more than one process in context -)"

Chromium (chromes base) is separated into two protection domains. These are a browser kernel and rendering engine. The rendering engine domain runs in a restricted sand box environment. Web pages and plugins are both executed in the rendering engine domain which means they have restricted access to your system. As with Gazelle, all communication to the kernel is done via a tight API proxied through IPC. From what I can tell, Gazelle offers no specific improvements over chrome in this area.

However Gazelle does shine! Gazelle puts serious priority on DOM and script interaction which is in desperate need of improvement in all current browsers. I definitely look forward to further information on this project in the future.

As for my chrome links, this area really interests me but companies are still fairly hush about what they're doing. Chrome is the exception to this, which is why I posted the links. There is a lot of valuable information there for anyone interested in this sort of thing.

Charles
Welcome Change

In reply to pdev

#Apr 7th @ 5:02 PM

Thanks for the links!
C

LordKain

I agree with Erik - Running C++ code in the web browser is not such a crazy idea and I am very enthusiastic about Google Native Client! I had never heard of Xax before this interview, will have a look into this.

vesuvius
Das Glasperlenspiel

A very intersting discussion. I think you need to get the Vista Security people to argue the case to break the web, yes people had their problems, but I now have a more secure OS thanks to the initial courageous decisions. I am all for breaking it all!

If I need to redesign my website as a consequence, then so be it. With Silverlight and out of browser stuff, Gazelle offers me an extra layer of assurance. If it breaks a 10 year old website, then that is collateral damage.

Charles
Welcome Change

In reply to LordKain

#Apr 7th @ 7:07 PM

It depends on how well you can actually sandbox native code executing in a browser. I'm not against the notion of C++ being compiled by and executing in the browser. I just think it's kind of crazy and potentially dangerous if you don't get the runtime security plumbing right.

C

pdev

@vesuvius

Breaking the web seems like a worse issue than it is. Infact, IE8 already contains the solution for this. If the browser detects insecure scripting it could block the actions and indicate to the user that they may want to reload the site in compatibility mode.

@LordKain

Web browsers run on all kinds of devices today, from pcs to mobiles and fridges. Because of this there is a strong need to abstract the code from the underlying system. This means that even if you were to compile C++ for a special web environment, there would still need to be a layer of abstraction such as virtual machices or JIT. With Silverlight and Flash both having GPU support now, and the progressive increases in speed, the only advantage C++ on the web would have is language preference. Also its worth pointing out the impossibility of creating an accepted standard for how such a language would work across browsers.

LordKain

@Charles

This is exactly what Google Native Client is all about. An attempt to build this kind of sandbox to enable native performance without sacrificing security. I understand there might be some security concerns if the runtime is flawed (and it is clearly more difficult to sandbox native code because of things like dynamically generated code, overlapping instructions, and so forth) but isn't it the same problem with the Silverlight / Flash runtimes?

@pdev

The performance discussion is a never-ending story and I would be curious to see how some of the demos shipped with Native Client (like Xaos for instance, the fractal viewer) would behave in the Silverlight / Flash world.

I am not saying that C++ applications should be used in the browser instead of some higher-level technologies, I am just saying that supporting this technology would clearly bring new opportunities to the developers.

As for the language consideration, the C/C++ pair is still the most popular today (according to http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) and there are hundreds of millions of lines of code already written in these languages...